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 : M
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
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 na
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 n
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
n patent 6141420,
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
res
documented on http://factorable.net. 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
doesn't imply that NaCl is what developers want, but
high-profile applications such as DNSCrypt are in fact using NaCl in
ways that seem easily generalizable to other applications.
---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
o_box() for every packet does
_not_ imply public-key cryptography for every packet.
---D. J. Bernstein
Research Professor, Computer Science, University of Illinois at Chicago
___
cryptography mailing list
cryptography@randombit.net
http://lists.random
//cr.yp.to/talks/2009.10.06/slides2.pdf for a more detailed
cost-benefit analysis.
---D. J. Bernstein
Research Professor, Computer Science, University of Illinois at Chicago
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/
- SipHash: 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
forgeries (Minematsu et al.).
* Many breaks in "encrypt only; 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
m is to centralize these details and get them right rather
than having everybody reimplement them badly. It would 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 culpri
ng various
cryptographic disasters addressed by this library)
---D. J. Bernstein
Research Professor, Computer Science, University of Illinois at Chicago
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailma
14 matches
Mail list logo
