« first day (2386 days earlier)      last day (2285 days later) » 

jww
jww
3:20 AM
Hi Everyone. My apologies for this question... Bernstein's NaCl is a download with a tarball dated of 2011; see [NaCl | Installation](https://nacl.cr.yp.to/install.html). There were some attacks published in November 2017 against curve25519 using low order elements. I can't help but feel the library should have been updated.

My question is, what gives? Is there a newer download of the library somewhere? If there is I cannot find it on the cr.yp.to site. Or should users apply patches to the original tarball? If so, where are the patches or updates? Or maybe something else?
 
Squeamish Ossifrage
Squeamish Ossifrage
@jww What attacks do you mean? What update are you expecting?
 
jww
jww
3:55 AM
@SqueamishOssifrage The key recovery attack is detailed in May the Fourth Be With You: A Microarchitectural Side Channel Attack on Several Real-World Applications of Curve25519‌​. I found libsodium's patches at Commit afabd7e7386e1194‌​. libsodium is a fork of NaCl, so I want to see how NaCl is doing things. Is libsodium the same as NaCl, or is NaCl doing something different?
 
 
6 hours later…
Biv
Biv
9:30 AM
@jww unless I'm wrong, the paper you mentioned concerns only libgcrypt not NaCl.
it does not means that because NaCl uses Curve25519, it is wrongly implemented.
> We have disclosed our findings to the GnuPG team and are
> working with them to implement countermeasures against our
> attack. The vulnerability has been assigned CVE-2017-0379
NaCl is not concerned at all in that vuln. Idem for TweetNaCl. :)
and in their conclusion
> In this work, we demonstrate a side-channel attack against Libgcrypt’s
> implementation of ECDH encryption with Curve25519, which uses
> the Montgomery ladder and branchless formulas for point addition
> and doubling. Instead of relying on easily observable behavior such
> as high-level key-dependent branches or memory accesses, our
> attack exploits a low-level side channel vulnerability deep inside
> Libgcrypt’s basic finite field arithmetic operations.
 
 
6 hours later…
Squeamish Ossifrage
Squeamish Ossifrage
3:30 PM
@jww The problem reported in the paper is an (unfortunately unsurprisingly) daft implementation error in libgcrypt's X25519 code. It reflects more on the dangers of overengineering in libgcrypt than on the design of the curve Curve25519, the DH function X25519, or the implementation of X25519 in NaCl or libsodium.
@jww The patch you cited in libsodium is a layer of paranoia on top of an implementation that was, as far as I can tell, not broken to begin with
 
CodesInChaos
CodesInChaos
The whole point validation stuff in libsodium is paranoia, that only applies to very few applications.
 
Squeamish Ossifrage
Squeamish Ossifrage
Frankly I'm not convinced that the always-on point validation business does more good than harm. Maybe it papers over certain limited mistakes in the design of novel protocols by novices who don't understand the low-level parts they're building things out of—but in so doing likely covers up deeper problems of protocol design (and introduces gratuitous incompatibility between implementations).
 
CodesInChaos
CodesInChaos
3:52 PM
I might add a helper function for checking for low order points to my C# impl, but I don't intend to add it to the basic key-exchange function.
 
Squeamish Ossifrage
Squeamish Ossifrage
Right—there are protocols where it may be relevant, but those protocols require extremely careful design anyway. If you rely on the generic X25519 function to do any kind of point validation, you've probably just cocked the gun in your holster pointed at your foot.
 
CodesInChaos
CodesInChaos
At that point you might also need to reject points on the twist
 
 
2 hours later…
jww
jww
5:36 PM
@SqueamishOssifrage What happens if the library is used in, say, SC4 HSM where the attacker gets unlimited guesses? That is, it is not single use DH used in TLS kx.
 

« first day (2386 days earlier)      last day (2285 days later) »