Re: Attacking networks using DHCP, DNS - probably kills DNSSEC

2003-06-30 Thread William Allen Simpson
both the user and administrator configure a per host secret was apparently out of the question. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List

Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread William Allen Simpson
! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Feds admit error in hacking conviction

2003-10-17 Thread William Allen Simpson
for a reversal. It's pretty damn rare, he said. I have never seen it happen. ... -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending

US Court says no privacy in wiretap law

2004-07-01 Thread William Allen Simpson
phone conversations that are temporarily stored in electronic routers during transmission. [page 51-52] As this is a US Court of Appeals, it sets precedent that other courts will use, and directly applies to all ISPs in the NE US. -- William Allen Simpson Key fingerprint = 17 40 5E 67

Re: entropy depletion

2005-01-09 Thread William Allen Simpson
and magic numbers, generally transmitted verbatum. However, since we have a ready source of non-blocking keying material in /dev/urandom, it seems to be better to use that instead of the blocking critical resource -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9

Re: entropy depletion

2005-01-26 Thread William Allen Simpson
Ben Laurie wrote: William Allen Simpson wrote: Why then restrict it to non-communications usages? Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy generator(s). Surely observation

Re: entropy depletion

2005-01-26 Thread William Allen Simpson
on the chin, and stick in the random(5) page the description of how reliable the device meets the requirement. (This might be a resend, my net was dropping all sorts of stuff today and I lost the original.) That's OK, the writing was clearer the second time around. -- William Allen Simpson Key

European country forbids its citizens from smiling for passport photos

2005-09-17 Thread William Allen Simpson
for prime time. (seen at http://isthatlegal.org) -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL

Re: ISAKMP flaws?

2005-11-17 Thread William Allen Simpson
considerations. Compare with Photuris [RFC-2522], where undergraduate (Keromytis) and graduate (Spatscheck, Provos) students independently were able to complete interoperable implementations (in their spare time) in a month or so So, no, some security folks didn't ignore this ;-) -- William Allen

Re: ISAKMP flaws?

2005-11-18 Thread William Allen Simpson
. Again, the ISAKMP flaws were foreseeable and avoidable. And Photuris was written before the existence of ISAKMP. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography

Re: ISAKMP flaws?

2005-11-19 Thread William Allen Simpson
is the community to replace ISAKMP with something more robust? Provos' Photuris code could be running on all the BSDs in a few months. Maybe sooner, were payment involved. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

Re: Linux RNG paper

2006-04-10 Thread William Allen Simpson
]): Date: Sun, 15 Aug 1999 10:00:01 -0400 From: William Allen Simpson [EMAIL PROTECTED] Catching up, and after talking with John Kelsey and Sandy Harris at SAC'99, it seems clear that there is some consensus on these lists that the semantics of /dev/urandom need improvement

Internet Identity Workshop (IIW) May 1-3, 2006

2006-04-17 Thread William Allen Simpson
? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: what's wrong with HMAC?

2006-05-02 Thread William Allen Simpson
. Of course, AFAICT, the trailing key makes the various recent attacks on MD5 and SHA1 entirely inapplicable. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing

Re: NSA knows who you've called.

2006-05-12 Thread William Allen Simpson
Perry E. Metzger wrote: http://www.usatoday.com/news/washington/2006-05-10-nsa_x.htm Legal analysis from Center for Democracy and Technology at: http://www.cdt.org/publications/policyposts/2006/8 -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

IKE resource exhaustion at 2 to 10 packets per second

2006-07-27 Thread William Allen Simpson
http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html The vulnerability allows an attacker to exhaust the IKE resources on a remote VPN concentrator by starting new IKE sessions faster than the concentrator expires them from its queue. By doing this, the attacker fills up the

Re: Security Implications of Using the Data Encryption Standard (DES)

2006-12-28 Thread William Allen Simpson
Leichter, Jerry wrote: | note that there have been (at least) two countermeasures to DES brute-force | attacks ... one is 3DES ... and the other ... mandated for some ATM networks, | has been DUKPT. while DUKPT doesn't change the difficulty of brute-force | attack on single key ... it creates a

Re: Linus: Security is people wanking around with their opinions

2007-10-02 Thread William Allen Simpson
I often say, Rub a pair of cryptographers together, and you'll get three opinions. Ask three, you'll get six opinions. :-) However, he's talking about security, which often isn't quantifiable! And don't get me ranting about provable security Had a small disagreement with somebody at

Re: PlayStation 3 predicts next US president

2007-12-02 Thread William Allen Simpson
James A. Donald wrote: This attack does not require the certifier to be compromised. You are referring to a different page (that I did not reference). Never-the-less, both attacks require the certifier to be compromised! The attack was to generate a multitude of predictions for the US

Re: PlayStation 3 predicts next US president

2007-12-02 Thread William Allen Simpson
Weger, B.M.M. de wrote: The parlor trick demonstrates a weakness of the pdf format, not MD5. I disagree. We could just as easy have put the collision blocks in visible images. Parlor trick. ... We could just as easy have used MS Word documents, or any document format in which there is some

Re: PlayStation 3 predicts next US president

2007-12-03 Thread William Allen Simpson
James A. Donald wrote: Not true. Because they are notarizing a signature, not a document, they check my supporting identification, but never read the document being signed. This will be my last posting. You have refused several requests to stick to the original topic at hand. Apparently,

Re: PlayStation 3 predicts next US president

2007-12-03 Thread William Allen Simpson
Weger, B.M.M. de wrote: See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/ ... Our first chosen-prefix collision attack has complexity of about 2^50, as described in our EuroCrypt 2007 paper. This has been considerably improved since then. In the full paper that is in preparation

Re: PlayStation 3 predicts next US president

2007-12-03 Thread William Allen Simpson
Dirk-Willem van Gulik wrote: Keep in mind that the notary is still 'careful' -- effectively they sign the hash -- rather than the document; and state either such (e.g. in the case of some software/code where you do not hand over the actual code) or state that _a_ document was presented with

Re: PlayStation 3 predicts next US president

2007-12-06 Thread William Allen Simpson
I had intended to stop posting, but with the request for history and a few misguided postings later, please indulge me. I'll try not to be too long. We've been talking about collision and preimage resistance at least since 1989. We didn't use those terms (I'm not fond of preimage). We merely

Re: PlayStation 3 predicts next US president

2007-12-09 Thread William Allen Simpson
Personally, I thought this horse was well drubbed, but the moderator let this message through, so he must think it important to continue James A. Donald wrote: William Allen Simpson wrote: The notary would never sign a hash generated by somebody else. Instead, the notary generates its

Re: PlayStation 3 predicts next US president

2007-12-10 Thread William Allen Simpson
Francois Grieu wrote: That's because if Tn is known (including chosen) to some person, then (due to the weakness in MD5 we are talking about), she can generate Dp and Dp' such that S( MD5(Tn || Dp || Cp || Cn) ) = S( MD5(Tn || Dp' || Cp || Cn) ) whatever Cp, Cn and S() are. First of all, the

Re: RNG for Padding

2008-03-16 Thread William Allen Simpson
We had many discussions about this 15 years ago You usually have predictable plaintext. A cipher that isn't strong enough against a chosen/known plaintext attack has too many other protocol problems to worry about mere padding! For IPsec, we originally specified random padding with 1

Re: On the unpredictability of DNS

2008-07-31 Thread William Allen Simpson
I've changed the subject. Some of my own rants are about mathematical cryptographers that are looking for the perfect solution, instead of practical security solution. Always think about the threat first! In this threat environment, the attacker is unlikely to have perfect knowledge of the

Re: On the unpredictability of DNS

2008-08-09 Thread William Allen Simpson
It seems like enough time has passed to post publicly, as some of these are now common knowledge: Ben Laurie wrote: William Allen Simpson wrote: Keep in mind that the likely unpredictability is about 2**24. In many or most cases, that will be implementation limited to 2**18 or less. Why

Re: once more, with feeling.

2008-09-10 Thread William Allen Simpson
James A. Donald wrote: Peter Gutmann wrote: Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements I agree. I'm sure this is a

Re: AES HDD encryption was XOR

2008-12-08 Thread William Allen Simpson
Jerry Leichter wrote: ... accurately states that AES-128 is thought to be secure within the state of current and expected cryptographic knowledge, it propagates the meme of the short key length of only 128 bits. A key length of 128 bits is beyond any conceivable brute force attack - in and

Re: CPRNGs are still an issue.

2008-12-16 Thread William Allen Simpson
Perry E. Metzger wrote: [Snip admirably straightforward threat and requirements analysis] Yes, you can attempt to gather randomness at run time, but there are endless ways to screw that up -- can you *really* tell if your random numbers are random enough? -- and in a cheap device with low

Re: Possibly questionable security decisions in DNS root management

2009-10-20 Thread William Allen Simpson
Nicolas Williams wrote: Getting DNSSEC deployed with sufficiently large KSKs should be priority #1. I agree. Let's get something deployed, as that will lead to testing. If 90 days for the 1024-bit ZSKs is too long, that can always be reduced, or the ZSK keylength be increased -- we too can

Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305

2013-09-10 Thread William Allen Simpson
It bugs me that so many of the input words are mostly zero. Using the TLS Sequence Number for the nonce is certainly going to be mostly zero bits. And the block counter is almost all zero bits, as you note, (In the case of the TLS, limits on the plaintext size mean that the first counter

Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305

2013-09-11 Thread William Allen Simpson
On 9/11/13 6:00 AM, Alexandre Anzala-Yamajako wrote: Chacha20 being a stream cipher, the only requirement we have on the ICV is that it doesn't repeat isn't ? You mean IV, the Initialization Vector. ICV is the Integrity Check Value, usually 32-64 bits appended to the packet. Each is

Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305

2013-09-11 Thread William Allen Simpson
On 9/11/13 10:27 AM, Adam Langley wrote: [attempt two, because I bounced off the mailing list the first time.] On Tue, Sep 10, 2013 at 9:35 PM, William Allen Simpson william.allen.simp...@gmail.com wrote: Why generate the ICV key this way, instead of using a longer key blob from TLS

Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305

2013-09-11 Thread William Allen Simpson
On 9/11/13 10:37 AM, Adam Langley wrote: On Tue, Sep 10, 2013 at 10:59 PM, William Allen Simpson william.allen.simp...@gmail.com wrote: Or you could use 16 bytes, and cover all the input fields There's no reason the counter part has to start at 1. It is the case that most of the bottom

Re: [Cryptography] Key stretching

2013-10-12 Thread William Allen Simpson
On 10/11/13 7:34 PM, Peter Gutmann wrote: Phillip Hallam-Baker hal...@gmail.com writes: Quick question, anyone got a good scheme for key stretching? http://lmgtfy.com/?q=hkdfl=1 Yeah, that's a weaker simplification of the method I've always advocated, stopping the hash function before the