RE: Intel plans crypto-walled-garden for x86
I'd call this news announcement about Intel creating a run known good code facility about as credible as the joke that Otellini told his minions to go buy a copy of McAfee, and they didn't hear the copy of part. Noone will tolerate an Intel-moderated walled garden. Only Apple has customers with a bad enough case of stockholm syndrome to tolerate that sort of nonsense. Ian. -Original Message- From: owner-cryptogra...@metzdowd.com on behalf of Peter Gutmann Sent: Wed 15-Sep-10 2:03 AM To: cryptography@metzdowd.com; g...@toad.com Subject: Re: Intel plans crypto-walled-garden for x86 John Gilmore g...@toad.com writes: Let me guess -- to run anything but Windows, you'll soon have to jailbreak even laptops and desktop PC's? Naah, we're perfectly safe, like every other similar attempt after 5-10 years of effort and several hundred million dollars down the drain it'll come to nothing. I guess that's one silver lining of the corollary to We can't secure PCs against the bad guys, which is We can't 'secure' them against their owners either (with the rider ... although we can cause a lot of cost and inconvenience in trying). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
Tom Ritter t...@ritter.vg writes: What's weird is I find confusing literature about what *is* the default for protecting the viewstate. I still haven't seen the paper/slides from the talk so it's a bit hard to comment on the specifics, but if you're using .NET's FormsAuthenticationTicket (for cookie-based auth, not viewstate protection) then you get MAC protection built-in, along with other nice features like sliding cookie expiration (the cookie expires relative to the last active use of the site rather than an absolute time after it was set). I've used it in the past as an example of how to do cookie-based auth right Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Debian encouraging use of 4096 bit RSA keys
On Tue, 14 Sep 2010 17:01, h...@debian.org said: I'd appreciate some input from this list about the Debian bias towards 4096 RSA main keys, instead of DSA2 (3072-bit) keys. Is it justified? We have made RSA the default in GnuPG for three reasons: First, DSA 1024 is only supported by more recent versions of OpenPGP implementations whereas RSA is supported for 10 years now with any sane key size. Second, we want to support SHA2 et al as soon as possible; this is not possible with DSA-1024. Third, DSA signing is fast (DSA-3072 is about 7 times faster than RSA-4096) however verification is much slower (~15 times). Given that for most use cases verification is the most prominent operation (think only of checking hundreds of key signatures per key), this is for what we want to optimize. OTOH, DSA vs. RSA is not the real question. I have not seen a threat model for DD keys. I would claim that the best way to attack Debian's code signing is to take over a developer's box and make use of his/her key [1]. With ~ 1000 developers and thus at least this number of boxes and keys this is a by far an easier way for malice actions than even to think about how to break RSA-2048. I doubt that this situation will change in the next 10 years. These keys are used as KSK, as gpg will happily attach subkeys to them for the grunt work... Right, but than you should take the primary key offline or put it on a smart card - this removes the option to attack the primary key on the developer's box. And if one of the subkeys has been compromised it is very easy to replace that subkey. Salam-Shalom, Werner [1] An even easier way is to subvert the upstream source. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 15/09/2010 00:26, Nicolas Williams wrote: On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote: How do you deliver Javascript to the browser securely in the first place? HTTP? I'll note that Ben's proposal is in the same category as mine (which was, to remind you, implement SCRAM in JavaScript and use that, with channel binding using tls-server-end-point CB type). It's in the same category because it has the same flaw, which I'd pointed out earlier: if the JS is delivered by normal means (i.e., by the server), then the script can't be used to authenticate the server. That's one of the reasons I said it was only good for experimenation. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 14/09/2010 21:16, Marsh Ray wrote: On 09/14/2010 09:13 AM, Ben Laurie wrote: Demo here: https://webid.digitalbazaar.com/manage/ This Connection is Untrusted So? It's a demo. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Haystack redux
On 09/14/2010 09:57 AM, Steve Weis wrote: There have been significant developments around Haystack since the last message on this thread. Jacob Applebaum obtained a copy and found serious vulnerabilities that could put its users at risk. He convinced Haystack to immediately suspend operations. The developer of Haystack, Daniel Colascione, has subsequently resigned from the project. Many claims made about Haystack's security and usage made by its creators now appear to be inaccurate. These claims were repeated without verification by the New York Times, Newsweek, the BBC, and the Guardian UK. Evegeny Morozov wrote several blog posts covering this. His latest post is here: http://neteffect.foreignpolicy.com/posts/2010/09/13/on_the_irresponsibility_of_internet_intellectuals Hi, What Steve has written is mostly true - though I was not working alone, we did it in an afternoon. It took quite a bit of effort to get Haystack to take this seriously. Eventually, there was an internal mutiny because of a serious technical disconnect between the author Daniel Colascione and the supposed author, Austin Heap. Daniel has been a stand up guy about the issues discovered and he really the problem space that the tool created. Sadly, most of the issues discovered do not have easy fixes - this includes even discussing some of the very simple but serious design flaws discovered. This has to be the worst disclosure issue that I've ever had to ponder - generally, I'm worried about being sued by some mega corp for speaking some factual information to their users. In this case, I guess the failure mode for being open about details is ... much worse for those affected. :-( An interesting unintended consequence of the original media storm is that no one in the media enjoys being played; it seems that now most of the original players are lining up to ask hard questions. It may be too little and too late, frankly. I suppose it's better than nothing but it sure is a great lesson in popular media journalism failures. All the best, Jacob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Haystack redux
On Sep 15, 2010, at 6:16 AM, Jacob Appelbaum wrote: An interesting unintended consequence of the original media storm is that no one in the media enjoys being played; it seems that now most of the original players are lining up to ask hard questions. It may be too little and too late, frankly. I suppose it's better than nothing but it sure is a great lesson in popular media journalism failures. On the contrary, because life is not a series of disconnected events, this is a great success for the safety of civilians, and for media coverage, going forward: - people who care about the lives of others, and who worry about technologies based in trust now are more aware of one another than ever before - the business of taking well-intentioned but defective things apart is out of the shadows and in a very favorable spotlight - The media have a whole new dimension of drama to add to their coverage of high tech wonders: ... but does it really work? Journalism is self-correcting, as you note... provided a feedback channel exists and can be maintained long enough for the corrections to hold... as happened here. - jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
A mighty fortress is our PKI, Part III
Some more amusing anecdotes from the world of PKI:
- A standard type of fraud that's been around for awhile is for scammers to
set up an online presence for a legit offline business, which appears to
check out when someone tries to verify it. A more recent variation on this
is to buy certs for legit businesses. One of these certs was traced back by
a security researcher who found that the scammers had obtained it through
the incredibly devious trick of shopping round commercial CAs until they
found one that was prepared to sell them a certificate.
- In a repeat of the original race to the bottom with non-EV certs, CA's have
issued EV certs for RFC 1918 addresses (!!!). What makes this particularly
entertaining is that in combination with a router warkitting attack and
Moxie Marlinspike's OCSP faking it allows an attacker to spoof any EV-cert
site.
- The list of people who have bought certificates for Apple from commercial
CAs keeps on growing (I guess Microsoft is just so five minutes ago :-).
For example one SMTP admin needed a cert for his server and wondered what
would happen if he asked for one for *.apple.com instead of his actual
domain name. $100 and a cursory check later he had a wildcard cert for
Apple. At least two more users have reported buying certificates for Apple,
and there are probably even more lurking out there - if you too have a
certificate from a certificate vending machine saying that you're Apple, do
get in touch
- There's malware out there that pokes fake Verisign certificates into the
Windows trusted cert store, allowing the malware authors to be their own
Verisign.
- CAs have issued certs to cybercrime web sites like
https://www.pay-per-install.com (an affiliate program for malware
installers), because hey, the Russian mafia's money is as good as anyone
else's.
- One of the most important things a CA needs to manage is certificate serial
numbers, because the combination { CA name, cert serial number } is a unique
identifier used in lots of security protocols to identify certs. Without
this uniqueness, you can't tell who signed something, you can't revoke a
cert, you can't... well, you get the idea. Not only have commercial CAs
issued certs with duplicate serial numbers, they've issued *CA certs* with
duplicate serial numbers. Ouch!
(When this was pointed out to the CA who did this - oops, my bad, we'll get
those re-issued for you - someone else pointed out that their OCSP
responder certs had expired, which none of the CA's clients appeared to have
noticed until then. Yeah, we'll look into fixing those too. Anything else
while we're at it?).
If anyone has any further amusing PKI stories, please get in touch, I'd love
to add a Part IV to this series.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Haystack redux
On Wed, Sep 15, 2010 at 03:16:34AM -0700, Jacob Appelbaum wrote: [...] What Steve has written is mostly true - though I was not working alone, we did it in an afternoon. It took quite a bit of effort to get Haystack to take this seriously. Eventually, there was an internal mutiny because of a serious technical disconnect between the author Daniel Colascione and the supposed author, Austin Heap. Daniel has been a stand up guy about the issues discovered and he really the problem space that the tool created. Sadly, most of the issues discovered do not have easy fixes - this includes even discussing some of the very simple but serious design flaws discovered. This has to be the worst disclosure issue that I've ever had to ponder - generally, I'm worried about being sued by some mega corp for speaking some factual information to their users. In this case, I guess the failure mode for being open about details is ... much worse for those affected. :-( An interesting unintended consequence of the original media storm is that no one in the media enjoys being played; it seems that now most of the original players are lining up to ask hard questions. It may be too little and too late, frankly. I suppose it's better than nothing but it sure is a great lesson in popular media journalism failures. I'm wondering if someone could shed a little light on how this service acquired any real users in the first place, and whether anyone thinks that anyone in danger of death-should-the-service-be-compromised is actually (still) using it. I find it hard to believe that even the most uninformed dissidents would be using an untested, unaudited, _beta_, __foreign__ new service for anything. Is there any reason to believe otherwise? My first guess would have been that it was a government-sponsored honeypot, and I bet they're far more suspicious than I am. -- - Adam -- If you liked this email, you might also like: Here's a little bookmarklet for turning github into rdoc -- http://workstuff.tumblr.com/post/1036575859 Making Sous Vide Custard -- http://www.aquick.org/blog/2010/09/02/making-sous-vide-custard/ Sous Vide Custard -- http://www.flickr.com/photos/fields/4951823152/ fields: Storm Troopers and Red Shirts: http://www.shoeboxblog.com/?p=18747; -- http://twitter.com/fields/statuses/24586133537 -- ** I design intricate-yet-elegant processes for user and machine problems. ** Custom development project broken? Contact me, I can help. ** Some of what I do: http://workstuff.tumblr.com/post/70505118/aboutworkstuff [ http://www.adamfields.com/resume.html ].. Experience [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] Founder - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part III
On Wed, Sep 15, 2010 at 8:39 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Some more amusing anecdotes from the world of PKI: Peter, Not to be too contrary (though at least a little) - not all of these are really PKI failures are they? - There's malware out there that pokes fake Verisign certificates into the Windows trusted cert store, allowing the malware authors to be their own Verisign. The malware could just as easily fake the whole UI. Is it really PKI's fault that it doesn't defend against malware? Did even the grandest supporters ever claim it could/did? - CAs have issued certs to cybercrime web sites like https://www.pay-per-install.com (an affiliate program for malware installers), because hey, the Russian mafia's money is as good as anyone else's. Similarly here - non-EV CAs bind DNS names to a field in a certificate. No more. They don't vouch for the business being run, and in any case any such audit would be point in time anyway. I suppose way back when people promised that certs would do this, but does anyone believe that anymore and have it as an expectation? Perhaps you're setting the bar a bit high? BTW - do you have pointers to most of the things you've reported? I'd love to get the full sordid details :) - Andy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
