Re: [cryptography] Interesting note on how MS assign vulnerability classifications
On 2012 Sep 7, at 15:54 , Peter Gutmann wrote: Even if the likelihood of transforming the heap corruption into remote code execution is exceedingly low, you still have to classify it as RCE until you can rule out all possibility of code execution. ... and solve the halting problem. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Crypto Fiddling?
On 2012 Mar 31, at 11:14 , Jeffrey Walton wrote: I'm aware of two standards where folks fiddled with a scheme and destroyed its security properties: * A5/3 based on Kasumi used in GSM networks * EAX' (EAX Prime) based on EAX mode Are there any other spectacular failures that come to mind? I agree that EAX' is broken (badly) in the way it is meant to be used. I agree that the modification done to MISTY to create Kasumi (basically, throwing away the key schedule) opened it up to related-key attacks. But I can't agree that A5/3 is broken in practice, because the key derivation and chaining mode can't be manipulated to expose it to these attacks. In fact, knowing that an attacker couldn't go there was part of the justification for weakening the key schedule to make it faster. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Some random chiming in... On 2011 Dec 2, at 5:00 , Adam Back wrote: On Sat, Dec 03, 2011 at 01:00:14AM +1300, Peter Gutmann wrote: I was asked not to reveal details and I won't, Of course, I would do the same if so asked. But there are lots of people on the list who have not obtained information indirectly, with confidentiality assurances offered, and for them remailers exist. but in any case I don't know whether it would achieve much. For the case of a public CA doing it, you'd see that CA X is involved, ... personally I'd like to know who is doing this and at what scale. As Peter said, this has been happening for some years. The reason I mentioned CDG airport is because it's the only such incident where I remembered exactly where I was (Sheraton hotel, never staying there again... not that this is the reason why). To me it was just the usual speed bump to be worked around. I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. I do not think its what you'd expect. A CA should issue certificates only to the holders of certificates. It should NOT issue sub-CA certifactes to third parties who will then issue certs to domains they dont own. Not even on the fly inside a packet inspection box. For how many years have Thawte and Verisign and others been prepared to issue certificates based only on the fact that the cheque cleared? If someone wants to inspect packets on a corporate lan they can issue their own self-signed cert, and install that in their users browsers in their OS install image. Then if I go on their LAN with my own equipment, I'll get a warning. I think its unacceptable to have CAs issuing such certs. I agree. But like a lot of unacceptable things, it happens because it makes money for someone. It breaks a clear expectation of security and privacy the user, even very sophisitcated user, has about privacy of their communications. Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want. No. Also IANAL but there were several cases where employees did have an expectation of privacy upheld even in the US. Certainly you cant do that in the EU legally either. So now the company uses a login banner that says You have no expectation of privacy when using this system. And of course the employee has no choice but to click through. [rest snipped.] Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011 Nov 30, at 22:28 , Jon Callas wrote: On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote: I run a wonderful Firefox extension called Certificate Patrol. It keeps a local cache of certificates, and warns you if a certificate, CA, or public key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my stockbroker's web site, the warnings started to appear. Then it was just checking IP addresses and stuff. And I presume you didn't save the cert. Of course, we just need to have people look for these and then save them. Yes. I regret that I had much bigger issues at the time than saving the cert. But, honestly, this is just the most recent time I've seen it... usually when traveling. I'm sure it won't be long before someone with more time and inclination than me will see another one. sorry about that, Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On 2011 Nov 2, at 12:25 , Leandro Meiners wrote: Hi List! I was wondering if anybody could give me some pointers as to papers or books that discuss the advantages/disadvantages of computing an HMAC of a message versus previously computing a hash of the message and then calculating the HMAC of the hash. My initial thoughts are that there isn't any additional security provided by either method. What about calculating the HMAC of the message concatenated to the hash? This seems more secure but I have no idea how to prove either statement. Any helps is greatly appreciated. Cheers, Leandro.- If I have two documents that collide under the hash function, calculating the MAC over the hash of the documents would allow me to substitute one for the other without the MAC changing, even though I don't know the MAC's key. But calculating the MAC directly on the document almost certainly wouldn't collide, nor would an attacker (who doesn't know the key) be able to calculate collisions offline. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Favourite signature scheme?
Some people have been referring to the Rabin signature algorithm as either Rabin-Miller or R-W (I assume meaning Rabin-Williams). Credit where credit is due: the scheme is entirely due to Michael Rabin according to my understanding. His name gets tied to the others in other contexts such as checking primality. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)
On 2010 Dec 17, at 9:46 , Steven Bellovin wrote: preposterous. Inconceivable. And I'm not quoting The Princess Bride. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On 2010 Dec 2, at 13:30 , coderman wrote: On Wed, Dec 1, 2010 at 7:26 PM, Steven Bellovin s...@cs.columbia.edu wrote: http://www.cellular-news.com/story/46690.php 521-bit key and other odd claims? think i'll stick with RedPhone ... 521 is one of the standard sizes for characteristic-2 ECC with optimal normal basis. It isn't snake oil. (Well, it might be, but that isn't evidence.) Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
