Opened 2 years ago

Last modified 11 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 2 years ago by teor

Keywords: security-low 027-backport-maybe removed

comment:2 Changed 2 years 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 2 years 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 22 months ago by nickm

Sponsor: SponsorQ

comment:5 Changed 22 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 21 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 20 months ago by teor

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

comment:8 Changed 20 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 19 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 19 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 19 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 19 months ago by teor

Parent ID: #23061#25263

comment:13 Changed 17 months ago by nickm

Keywords: 034-triage-20180328 added

comment:14 Changed 17 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 17 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 14 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 11 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.