On Fri, 6 May 2011 23:16:14 -0700
Chris Palmer wrote:
> On May 6, 2011, at 10:25 PM, Robert Ransom wrote:
>
> > I would expect GCC (and most other C compilers) to use a
> > non-constant-time implementation of (v1 == v2).
>
> Are there machines that implement uint8_t comparison in a data-depende
On May 6, 2011, at 10:25 PM, Robert Ransom wrote:
> I would expect GCC (and most other C compilers) to use a
> non-constant-time implementation of (v1 == v2).
Are there machines that implement uint8_t comparison in a data-dependent way?
What's an example?
--
Chris Palmer
Technology Director,
On May 6, 2011, at 10:35 PM, Marsh Ray wrote:
> Of course, we could always just compute SHA-256 hashes of each side and then
> compare those, right? :-)
Yes, Brad Hill suggested that (in a Java/C# context). Nate Lawson didn't like
it on performance grounds, but I don't recall hearing any correc
On 05/06/2011 09:40 PM, Marsh Ray wrote:
On 05/06/2011 08:00 PM, Nick Mathewson wrote:
int mem_neq(const void *m1, const void *m2, size_t n)
{
const uint8_t *b1 = m1, *b2 = m2;
uint8_t diff = 0;
while (n--)
diff |= *b1++ ^ *b2++;
return diff != 0;
}
#define mem_eq(m1, m2, n) (!mem_neq((m1), (m2
On Fri, 6 May 2011 22:11:06 -0700
Chris Palmer wrote:
> On May 6, 2011, at 8:53 PM, Robert Ransom wrote:
> > GCC is likely to turn (v1 == v2) into a backdoor.
>
> Can you explain what you mean?
I would expect GCC (and most other C compilers) to use a
non-constant-time implementation of (v1 ==
On May 6, 2011, at 8:53 PM, Robert Ransom wrote:
>> int memcmp(const void *m1, const void *m2, size_t n)
>> {
>> /*XXX I don't know if this is even right; I haven't tested it at all */
>> const uint8_t *b1 = m1, *b2 = m2;
>> int retval = 0;
>>
>> while (n--) {
>>const uint8_t v1 = b1[n], v
On Sat, May 7, 2011 at 12:47 AM, Robert Ransom wrote:
> On Fri, 6 May 2011 23:14:58 -0400
> Nick Mathewson wrote:
>
>> Also, as I said on the bug, doing a memcmp in constant time is harder
>> than doing eq/neq. I *think* that all of the cases where we care
>> about memcmp returning a tristate -1
On Fri, 6 May 2011 23:14:58 -0400
Nick Mathewson wrote:
> Also, as I said on the bug, doing a memcmp in constant time is harder
> than doing eq/neq. I *think* that all of the cases where we care
> about memcmp returning a tristate -1/0/1 result, we don't need
> data-independence... but in case w
On Fri, 6 May 2011 23:14:58 -0400
Nick Mathewson wrote:
> On Fri, May 6, 2011 at 10:40 PM, Marsh Ray wrote:
> [...]
> >> but the problem in general is worrisome and we
> >> should indeed replace (nearly) all of our memcmps with
> >> data-independent variants.
> >
> > Maybe some of the str*cmps t
On Fri, May 6, 2011 at 10:40 PM, Marsh Ray wrote:
[...]
>> but the problem in general is worrisome and we
>> should indeed replace (nearly) all of our memcmps with
>> data-independent variants.
>
> Maybe some of the str*cmps too? I grep 681 of them.
Yeah; most of these are not parsing anything se
On 05/06/2011 08:00 PM, Nick Mathewson wrote:
. The particular case that you mention is (I think) safe (see
discussion there),
I figured it probably was, but illustrated some red flags.
but the problem in general is worrisome and we
should indeed replace (nearly) all of our memcmps with
data
On Fri, May 6, 2011 at 7:13 PM, Marsh Ray wrote:
>
> Greetings all,
>
Hi, Marsh!
I replied on https://trac.torproject.org/projects/tor/ticket/3122#comment:4
. The particular case that you mention is (I think) safe (see
discussion there), but the problem in general is worrisome and we
should inde
On May 6, 2011, at 5:08 PM, Jacob Appelbaum wrote:
> We can
> #define over memcmp but I fear that it's better to specifically
> eradicate each one by hand and really think things over on a case by
> case basis.
FWIW, I agree.
Nice work, Marsh!
--
Chris Palmer
Technology Director, Electronic F
Hi Marsh,
Thanks for writing to or-dev, welcome to the list!
On 05/06/2011 04:13 PM, Marsh Ray wrote:
>
> Greetings all,
>
> I happened to download the tor-0.2.2.25-alpha.tar.gz source yesterday
> and I noticed something. Apologies in advance if this has already been
> discussed and resolved, I
Greetings all,
I happened to download the tor-0.2.2.25-alpha.tar.gz source yesterday
and I noticed something. Apologies in advance if this has already been
discussed and resolved, I did a cursory web search and didn't see anything.
There are a lot of places in the code where memcmp() is call
Hi all,
my group and I have recently been working on the question whether
multiple circuits in Tor share the available bandwidth fairly and
reasonably. What we found is: they don't. Not at all.
First, we developed an analytical model for the fairness between
circuits in an anonymity overlay, and
[+ Douglas, Berkant]
On Fri, May 06, 2011 at 10:50:05AM -0400, Nick Mathewson wrote:
> Crypto people who have been following threads about the
> circuit-establishment handshake will be interested in the new paper,
> "Anonymity and one-way authentication in key-exchange protocols", by
> Goldberg, S
Crypto people who have been following threads about the
circuit-establishment handshake will be interested in the new paper,
"Anonymity and one-way authentication in key-exchange protocols", by
Goldberg, Stebila, and Ostaoglu. Here's the version they updated
today:
http://www.cacr.math.uwaterloo.c
18 matches
Mail list logo
