Opened 22 months ago

Last modified 9 months ago

#23323 assigned defect

sample_laplace_distribution should produce a valid result on 0.0

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.6.3-alpha
Severity: Normal Keywords: security-low, tor-relay, 029-backport, 026-backport-maybe, 034-triage-20180328, 034-removed-20180328, 031-unreached-backport
Cc: Actual Points:
Parent ID: #25263 Points: 0.5
Reviewer: Sponsor: SponsorQ

Description

Destroying the signal with probability 1 in 2-53 isn't a great idea.
Let's pick a sensible double value, and pass it through the function instead.

I suggest 2-54, but it really doesn't matter exactly what value we use, as long as it produces valid results, because the probability is so low.

Introduced in 45bc5a0

Child Tickets

Change History (17)

comment:1 Changed 22 months ago by teor

Keywords: security-low 027-backport-maybe removed

comment:2 Changed 21 months ago by teor

Owner: set to teor
Status: newassigned

I'll do these in 0.3.2, some of them are security-low.

comment:3 Changed 21 months ago by teor

Keywords: security-low added

Turns out that the exact value of the signal is revealed, because it's added to INT64_MIN. That's a security issue.

comment:4 Changed 20 months ago by nickm

Sponsor: SponsorQ

comment:5 Changed 19 months ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

We're still working out the best way to do this in the PrivCount in Tor spec. Let's revisit this issue when that's been reviewed on tor-dev@.

comment:6 Changed 19 months ago by teor

We should revise or close these tickets based on Appendix C in the latest privcount-shamir spec:

https://github.com/teor2345/privcount_shamir/blob/noise-limits/doc/xxx-privcount-with-shamir.txt

The good news is that we probably don't need to care about extreme values or binning, because properly implemented noise has known limits, and doesn't need binning.

comment:7 Changed 18 months ago by teor

0.2.8 is EOL, so we won't be backporting to it.

comment:8 Changed 18 months ago by teor

Keywords: 028-backport-maybe removed

0.2.8 is EOL, so we won't be backporting to it.

comment:9 Changed 17 months ago by teor

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Moving most of my assigned tickets to 0.3.4

comment:10 Changed 17 months ago by nickm

Keywords: 030-backport removed

Remove 030-backport from all open tickets that have it: 0.3.0 is now deprecated.

comment:11 Changed 17 months ago by nickm

Remove 026-backport from all open tickets that have it: 0.2.6 has been deprecated for some while.

comment:12 Changed 16 months ago by teor

Parent ID: #23061#25263

comment:13 Changed 15 months ago by nickm

Keywords: 034-triage-20180328 added

comment:14 Changed 15 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:15 Changed 15 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:16 Changed 12 months ago by teor

Keywords: 031-unreached-backport added; 031-backport removed

0.3.1 is end of life, there are no more backports.
Tagging with 031-unreached-backport instead.

comment:17 Changed 9 months ago by teor

Owner: teor deleted

We should fix these issues by migrating these statistics to PrivCount in Tor.
See #25263 and its parents for details.

Note: See TracTickets for help on using tickets.