Re: [cryptography] Key escrow 2012
As I recall people were calling the PGP ADK feature corporate access to keys, which the worry was, was only policy + config away from government access to keys. I guess the sentiment still stands, and with some justification, people are still worried about law enforcement access mechanisms for internet telecoms equipment and protocols being used in places like Syria, Iran etc, which is a quite similar scenario. And as we all know adding key recovery and TTPs etc is a risk, cf The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption by Abelson, Anderson, Bellovin, Benaloh, Blaze, Diffie, Gilmore, Neumann, Rivest, Schiller Schneier. http://www.crypto.com/papers/key_study.pdf Not sure that we lost the crypto wars. US companies export full strength crypto these days, and neither the US nor most other western counties have mandatory GAK. Seems like a win to me :) Adam On Fri, Mar 30, 2012 at 12:24:47PM +1100, ianG wrote: On 30/03/12 09:38 AM, Jon Callas wrote: Also, there wasn't a PGP system. The PGP additional decryption key is really what we'd call a data leak prevention hook today, but that term didn't exist then. Certainly, lots of cypherpunks called it that at the time, but the government types who were talking up the concept blasted it as merely a way to mock (using that very word) the concept. And therein lies another story! Which always seems to end: and then we lost the crypto wars. I treat it as a great learning experience. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Back a...@cypherspace.org writes: Not sure that we lost the crypto wars. US companies export full strength crypto these days, and neither the US nor most other western counties have mandatory GAK. Seems like a win to me :) Nope. If we had won, crypto would be in widespread use today for email. As it is, enough FUD and confusion was sown to avert that outcome. Even on geek mailing lists such as this, signatures are rare. - -- -- StealthMonger stealthmon...@nym.mixmin.net Long, random latency is part of the price of Internet anonymity. anonget: Is this anonymous browsing, or what? http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain stealthmail: Hide whether you're doing email, or when, or with whom. mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAk91kPoACgkQDkU5rhlDCl58ZgCffAItxMY6oq0R0Nv7X3B0cLuU qe8An3wm0CxzN2FAe/8oMDWmSFW1wTfd =sLzT -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
On Fri, Mar 30, 2012 at 7:10 AM, StealthMonger stealthmon...@nym.mixmin.net wrote: Adam Back a...@cypherspace.org writes: Not sure that we lost the crypto wars. US companies export full strength crypto these days, and neither the US nor most other western counties have mandatory GAK. Seems like a win to me :) Nope. If we had won, crypto would be in widespread use today for email. As it is, enough FUD and confusion was sown to avert that outcome. Even on geek mailing lists such as this, signatures are rare. We don't encrypt e-mail for other reasons, namely because key management for e-mail is hard. It's taken a long time for us to reach consensus (have we?) on that and then work on things like DKIM (though that still doesn't support encryption). OTOH many people use OTR all the time, and many more might if it was always implemented and enabled by default in all IM clients. Also, we all use TLS, and this has very widespread application. And we regularly read about people stopped at the border and asked to produce their passphrases for disk/filesystem encryption. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nope. If we had won, crypto would be in widespread use today for email. As it is, enough FUD and confusion was sown to avert that outcome. Even on geek mailing lists such as this, signatures are rare. Sorry, I beg to differ. The average folks in the world today never heard of the crypto war and certainly were not influenced by it. Just about every mail client (accept the one I happen to be using :-) ) has some form of crypto (usually S/MIME) built in. Yet it isn't being used. I have heard a lot of speculation as to why crypto isn't being used by Joe Average, ranging from its too hard, lack of understanding of key management (aka Certificates) [its too hard], and just lack of caring. See http://www.simson.net/ref/2004/chi2005_smime_submitted.pdf But the crypto wars just isn't a factor. There is still time to figure out how to get people to use crypto, all is not yet lost! -Jeff ___ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room E17-110A Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu, j...@qyv.net, jeffrey.schil...@gmail.com http://jis.qyv.name ___ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFPddgm8CBzV/QUlSsRAl2PAKCD9oErp2HhAJrpFCYMaIM2mUASLwCaAssS NNATc1a1SyOJpTlf2P4Tnqs= =26GV -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Key escrow 2012
On Thu, Mar 29, 2012 at 6:38 PM, Jon Callas j...@callas.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 29, 2012, at 2:48 PM, mhey...@gmail.com wrote: On Tue, Mar 27, 2012 at 1:17 PM, Nico Williams n...@cryptonector.com wrote: On Tue, Mar 27, 2012 at 5:18 AM, Darren J Moffat For example an escrow system for ensuring you can decrypt data written by one of your employees on your companies devices when the employee forgets or looses their key material. Well, the context was specifically the U.S. government wanting key escrow. Hmm - these are not mutually exclusive. Back in the mid to late 90s, the last time the U.S. government required key escrow for international commerce with larger key sizes, they allowed key escrow systems that were controlled completely by the company. Specifically, they allowed Trusted Information System's RecoverKey product (I worked on this one, still have the shirt, and am not aware of any other similar products available at the time - PGP's came later and was more onerous to use). RecoverKey simply wrapped a session key in a corporate public key appended to the same session key wrapped with the user's public key. If the U.S. Government wanted access to the data, the only thing they got was the session key after supplying the key blob and a warrant to the corporation in question. The U.S. government even allowed us to sell RecoverKey internationally to corporations that kept their RecoverKey data recovery centers offshore but agreed to keep them in a friendly country. I'd have to disagree with you on much of that. The US Government never required key escrow for international commerce. Encrypted data was never restricted, what was restricted was the export of software etc So, your second sentence disagrees with your first? In the real but rapidly changing world that existed back then, if you wanted to export cryptographic software that used strong keys from the U.S., you needed key escrow. Or, of course, you could publish a book of your source code ;-) (although that wasn't proven legal until 1999). Amusingly, I ended up having TIS's RecoverKey under my bailiwick because Network Associates bought PGPi and then TIS. The revenues from it were so small that I don't think they even covered marketing material like that shirt you had. In a very real sense, it didn't exist as anything more than a proof-of- concept that proved the concept was silly. What do you mean 'had', I still have the shirt! No argument on the silliness but if the government hadn't relaxed the rules and you had a pile of non-U.S. installations of Microsoft applications (Outlook, IE, and other code using the Microsoft CryptoAPI) and you wanted strong crypto, then RecoverKey was the _only_ option. Now, back then, most internationals were happy with the Microsoft's base cryptographic service provider (512-bit RSA key exchange, 40-bit RC2, 40-bit RC4, DES(-40?)). Deep Crack was changing that but then, probably because of Deep Crack, impending rule changes made RecoverKey almost irrelevant. Also, there wasn't a PGP system. The PGP additional decryption key is really what we'd call a data leak prevention hook today, but that term didn't exist then. I was just using the PGP additional decryption key design as an example of something that used a similar technique of encrypting the session key under more than one public key. As for data leak prevention, that isn't what we other Network Associates employees heard back then. We were told and used the PGP ADK thing as if it would help us when we lost our private keys (along with protecting the company from employees that try to hold data hostage). I remember trying to get company officers to get their key shares together to please please please recover my backup encrypted volume. Alas, I had no success and had to do a few weeks of scrambling to recover the old fashioned way. I admit I was young, naive, and tainted by having worked on RecoverKey where the data recovery center sat in a room with a modem happily waiting for me to recover my own keys. Yes, RecoverKey was never much more than a commercial grade proof-of-concept. But, it was well thought out, satisfied a real, albeit an artificially-created-by-stupid-policy need, and it did work as advertised. -Michael Heyman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Crypto Fiddling?
Hi Guys, 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? Jeff ___ 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] Key escrow 2012
On 31/03/12 03:00 AM, Jeffrey I. Schiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nope. If we had won, crypto would be in widespread use today for email. As it is, enough FUD and confusion was sown to avert that outcome. Even on geek mailing lists such as this, signatures are rare. Sorry, I beg to differ. The average folks in the world today never heard of the crypto war and certainly were not influenced by it. A bit like saying that the average iPhone user never heard of GSM and was certainly not influenced in it :) Just about every mail client (accept the one I happen to be using :-) ) has some form of crypto (usually S/MIME) built in. Yet it isn't being used. I have heard a lot of speculation as to why crypto isn't being used by Joe Average, ranging from its too hard, lack of understanding of key management (aka Certificates) [its too hard], and just lack of caring. See http://www.simson.net/ref/2004/chi2005_smime_submitted.pdf But the crypto wars just isn't a factor. It's probably more about correlation and hidden causalities. One of the weapons of the anti-crypto side was over-complexity, desire for single points of failure, serialisation of steps. Things like S/MIME exhibit all of those properties, indeed it was so loaded up with bad engineering, it failed to get off the ground even when geeks try and run it. But against the opponents of crypto, it still fulfills a purpose. Its benefit is to block any further action in this direction. There are enough people who believe in S/MIME, and these people control enough of the vendors such that there is no counter-momentum to replace it with something that works [0]. The crypto wars were about opening up that battlefield so that open source could start to experiment with lots and lots of alternatives. The reason we lost the war was because we thought we'd won it. We were tricked. What actually happened was a high profile weapon - the export control - was loosened up enough just enough to make many think we'd won. All the low-profile weapons were left in place. There is a Foreign Affairs article that describes the same or similar techniques carried out against South Africa. (I think Ross Anderson dug this out at some stage and posted about it ... it's probably worth finding it and re-reading it.) There is still time to figure out how to get people to use crypto, all is not yet lost! Yeah. New applications is the opportunity. We saw this in Skype, when a new field was not subject to the old domination. We didn't so much see it with social networks, but there is something of it in there. iang [0] fixing s/mime to work is pretty easy - just have the app create share self-signed certs when the account is added/created. Add in some detail, and let it rip. The point is, you will never ever get the past the vendors. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
From: ianG i...@iang.org Sorry, I beg to differ. The average folks in the world today never heard of the crypto war and certainly were not influenced by it. A bit like saying that the average iPhone user never heard of GSM and was certainly not influenced in it :) I have an iPhone. I don't discuss plans to invade Nazi Germany over it, nor do I arrange drug deals or plot the overthrow the US Government. I think I'm pretty safe. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Detecting Crypto Compromises
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Does anyone have any knowledge of academic papers focused on methods of detecting whether a crypto scheme has been compromised in situ or on how to utilize intelligence gleaned from compromised cipher texts without giving away that compromise to the enemy? I'm thinking in terms of scenarios like how could the Nazis have methodologically shown Enigma's compromise in a systematic manner; the converse as well though: has there been research into scenarios similar to the Allies and Enigma (i.e. how to not give the game away), or has it all just been highly intuitive guesswork? It doesn't have to be period sensitive, anything from Caesar to the recent would be helpful. Regards, Landon Hurley - -- Violence is the last refuge of the incompetent. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPdmqgAAoJEDeph/0fVJWsfJIP/R91ImnBAngFTY/GuGZczPf+ oEktqqjhgH8CjCALj2rexzlQO9+B61tTt9PZwpwVihpKtWBwpz9VnIIhoNfDsVYO XXLPF/o+w5TOmCB+gSVufn7Ui6B6WGlkeLLCudRG48S5/bHvJW/qGjuchJnMoWz7 JiFJBvleIzUYn0lEwlx88ZvmuKSLrUOYos5wV+eIj8fL/Ff1g2xjhOJXytFVastk X8tQWvSOA7tOxfF+1qLh7289rGfML/0ybdcxfAl7jLylMKqN4VGydrZeDUWJhuIc fflEpMHSZNvlQYRpxRFLCdLqMO/r5wiX4+hpFKI1KXYhA3doQYcuVDwK1VpZ5Vxg wG9x64qIWtY0wtf4nY1JNBJMMLHyWIyfPHfaoG+w402P3UuPX2wTV3tcpztg+20W Ob8i4Sgym9HML5NgOG5YFWVWFnRdi/eSfImURGL7rCCmt51OJRf42sBfPHez3MOe 3SwG8xffAOolG/MYI7zpuIPOuHV/gQUuC9tb+zpVejESt1NbnK4l3MrNo0ykF2cg tO5uZttEN/8fN4xYyibRPw+USYQlxq2QfRxbeAVWx4mRT9SBqcDRwnkbP9tN1agN psMDPG8LYeDIvPf+T0nrDVBownqKKmZkdoJwGwuwohn+eClWr5cvfWSFhaGgXuaM B4McgutpVvqhYgNP+dQ3 =268b -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Crypto Fiddling?
On 31/03/12 11:14 AM, Jeffrey Walton wrote: Hi Guys, 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? Debian optimisation of input to TLS code? Possibly XOR related adventures, or RNGs. Sound like a good enquiry for an article. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Detecting Crypto Compromises
On 31/03/12 13:23 PM, Landon Hurley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Does anyone have any knowledge of academic papers focused on methods of detecting whether a crypto scheme has been compromised in situ or on how to utilize intelligence gleaned from compromised cipher texts without giving away that compromise to the enemy? I'm thinking in terms of scenarios like how could the Nazis have methodologically shown Enigma's compromise in a systematic manner; the converse as well though: has there been research into scenarios similar to the Allies and Enigma (i.e. how to not give the game away), or has it all just been highly intuitive guesswork? It doesn't have to be period sensitive, anything from Caesar to the recent would be helpful. This is all heavily studied inside the intelligence agencies. But I never heard of it being published in an academic sense, because any academic writings would immediately be classified. It was in a sense the biggest meta-secret of the war(s). There are lots and lots of spy/war novels about this sort of deception planning, and plenty of WWII documentaries that reveal the deception planning that went on. An awful lot of it was to hide the use of Enigma decrypts. Some also for the location dates of D-Day. Huge resources were spent on these exercises, like Patton's mythical 3rd Army and the bombers used to invade Pas de Calais. (Deception Plan is a formal term of art in military planning, might make a good search term.) (Probably the place to look is declassified documents that are after their 50 year timespan.) Oh, one historical reference (might appeal to Americans): the reason the Battle of the Bulge was a surprise attack was that Hitler was pissed off at his prior failures, and personally suspected the communications channels were leaking his secrets, so all the orders were sent by motor-cycle couriers. E.g., Hitler was right. His generals were wrong. (This seemed to happen often enough to keep Hitler in power...) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
On 2012-03-31 1:51 AM, Nico Williams wrote: We don't encrypt e-mail for other reasons, namely because key management for e-mail is hard. Key management is hard because it involves a third party, which third party is also the major security hole. We have been doing key management the wrong way. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
On 2012-03-30 10:10 PM, StealthMonger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Backa...@cypherspace.org writes: Not sure that we lost the crypto wars. US companies export full strength crypto these days, and neither the US nor most other western counties have mandatory GAK. Seems like a win to me Nope. If we had won, crypto would be in widespread use today for email. We did not understand what software was needed, and have not supplied it. Widespread use of encryption requires end to end encryption. Mapping names to keys is too much work for the end user if it is additional task on top of doing what needs doing, so people do not bother. Need a zooko triangle like system in which your key is your ID. If key is your ID, need a system that substitutes for DNS which maps keys to network addresses. (Does bitcoin map keys to network addresses?. I don't think it could work unless it does.) If encryption is end to end, needs to replace tcp with something built on top of udp which supports NAT penetration. So need a DNS and tcp replacement. And, since committees are always a security hole (the committee always comes under hostile state influence) the tcp/DNS replacement needs to have an arbitrary and potentially large number of bits identifying the protocol, instead of being limited to eight or sixteen bits of protocol identification as tcp is, and a potentially multi step protocol negotiation allowing client and server to search for a shared protocol of a class, so that we can avoid the need for an ICANN ICANN, and the states it represents, was implicit in thirty two bit network addresses and in the eight to sixteen bit protocol identifiers of tcp. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Detecting Crypto Compromises
I'm thinking in terms of scenarios like how could the Nazis have methodologically shown Enigma's compromise in a systematic manner; the converse as well though: has there been research into scenarios similar to the Allies and Enigma (i.e. how to not give the game away), or has it all just been highly intuitive guesswork? It doesn't have to be period sensitive, anything from Caesar to the recent would be helpful. Possibly orthogonal, but Churchill's treatment of Blechley Park offers (offered) many examples of how not to tip one's hand. http://www.bletchleypark.org.uk/news/docview.rhtm/497230/article.html His purposeful avoidance of tipping of his hand included erasing Blechley's history and achievments after the war so as to avoid having the Soviets realize that the UK was reading their cables, a story which is detailed in the recent book The Theory That Would Not Die, Sharon Bertsch McGrayne http://yalepress.yale.edu/book.asp?isbn=9780300169690 --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James A. Donald jam...@echeque.com writes: On 2012-03-31 1:51 AM, Nico Williams wrote: We don't encrypt e-mail for other reasons, namely because key management for e-mail is hard. Key management is hard because it involves a third party, which third party is also the major security hole. We have been doing key management the wrong way. Yep. It should be no harder than maintaining a personal telephone directory. Would-be telephone correspondents somehow manage to get each other's phone numbers into their personal directories. Similarly, would-be email correspondents can get each other's public keys. - -- -- StealthMonger stealthmon...@nym.mixmin.net Long, random latency is part of the price of Internet anonymity. anonget: Is this anonymous browsing, or what? http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=sourceoutput=gplain stealthmail: Hide whether you're doing email, or when, or with whom. mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAk92hscACgkQDkU5rhlDCl7P3ACgzIrjdR7q+a/66ce5t3KncUR2 No4AnR4mpx0UhsvbKepzbPYJDlD82w+0 =Im6I -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
