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
; 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
: 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
.
---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
. 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
,
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
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
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
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
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
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 :
11 matches
Mail list logo