Re: [cryptography] Implementing constant-time string comparison

John Gilmore writes, on a semi-moderated mailing list: A bugfree C compiler Bwahahaha. That's funny. A large part of the game here is to envision the screwups that people will make and build systems that survive those screwups. For example, it's common to have C code such as x ? MACRO_A :

Re: [cryptography] ECC curves that are safe safecurves.cr.yp.to

Peter Gutmann writes (on one of the harder-to-use mailing lists): Some of their objections seem pretty subjective though, I mean they don't like the Brainpool curves Actually, the Brainpool curves _meet_ the rigidity requirement that you're alluding to. The SafeCurves site displays this in the

[cryptography] another Certicom patent

Dan Brown writes, on the semi-moderated c...@irtf.org list: I agree with your multiple PK algs suggestion, for parties who can afford it. What about sym key algs? Maybe too costly for now? By the way, this kind of idea goes back at least as far as 1999 from Johnson and Vanstone under the name

[cryptography] ECC patent FUD revisited

NSA's Kevin Igoe writes, on the semi-moderated c...@irtf.org list: Certicom has granted permission to the IETF to use the NIST curves, and at least two of these, P256 and P384, have p = 3 mod 4. Not being a patent lawyer, I have no idea what impact the Certicom patents have on the use of

Re: [cryptography] [Cryptography] RSA is dead.

Peter Gutmann writes (on the moderated cryptogra...@metzdowd.com list): Any sufficiently capable developer of crypto software should be competent enought to backdoor their own source code in such a way that it can't be detected by an audit. Some of us have been working on an auditable crypto

Re: [cryptography] What is the state of patents on elliptic curve cryptography?

, but there's very solid prior art for that one, and in any case it'll expire in July 2014. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http

Re: [cryptography] urandom vs random

. But fixing this configuration bug has nothing to do with the /dev/random superstitions. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Last call: DIAC: Directions in Authenticated Ciphers

: a fast short-input PRF (Aumasson, Bernstein) - Stronger security guarantees for authenticated encryption (Boldyreva, Paterson, Stam) - Suggestions for hardware evaluation of cryptographic algorithms (Gurkaynak) See you in Stockholm! ---D. J. Bernstein Research

[cryptography] DIAC: Directions in Authenticated Ciphers

; authentication is too slow IPsec. * Keeloq door/car/garage RFID completely broken (Eisenbarth et al.). * More broken AES is too big RFID proposals: HB, HB+, etc. To summarize: Yes, non-cryptographic security is a disaster, but cryptography is a disaster too. :-) ---D. J. Bernstein Research

Re: [cryptography] Duplicate primes in lots of RSA moduli

be interesting to understand how /dev/urandom failed for the repeated RSA primes---I'm presuming here that /dev/urandom was in fact the main culprit. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago