Opened 3 years ago

Last modified 8 months ago

#23323 new 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, 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 (19)

comment:1 Changed 3 years ago by teor

Keywords: security-low 027-backport-maybe removed

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

Sponsor: SponsorQ

comment:5 Changed 3 years 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 3 years 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 3 years ago by teor

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

comment:8 Changed 3 years ago by teor

Keywords: 028-backport-maybe removed

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

comment:9 Changed 3 years 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 3 years 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 3 years 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 3 years ago by teor

Parent ID: #23061#25263

comment:13 Changed 3 years ago by nickm

Keywords: 034-triage-20180328 added

comment:14 Changed 3 years ago by nickm

Keywords: 034-removed-20180328 added

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

comment:15 Changed 3 years 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 2 years 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 2 years 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.

comment:18 Changed 10 months ago by teor

Keywords: 029-backport removed

0.2.9 is no longer maintained as of 1 January 2020. Therefore, we won't be backporting anything to it.

(None of these tickets are merge_ready, so we can just delete the backport tag.)

comment:19 Changed 8 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.