Re: [cryptography] Key escrow 2012
Il giorno sab, 31/03/2012 alle 13.03 +1000, James A. Donald ha scritto: 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. PGP web of trust doesn't address it? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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
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
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] 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
Re: [cryptography] Key escrow 2012
-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. If you were of a mind where you thought that the only way to get cryptographic software was from the US, then you'd think this might be something like effective. In reality, the idea was absurd from the get-go because encrypted data was never restricted. The people who wanted to push key escrow never had a good way to explain to anyone why they'd want it. They never had a good carrot, either, for it. At one point, they tried to sugar-coat it by offering fast-tracks on export for it, but Commerce granted export easily. Furthermore, Commerce's own rules progressed so fast with so many exemptions that it was all obviated before it could be developed. 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. 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. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFPdOR+sTedWZOD3gYRAtc6AKD/GlvCO3/cs+xuaPTz5I0sqjfUzwCdGcw2 4PlzXeIu0dK9EqfgDQBfpLI= =GfnU -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
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] Key escrow 2012
(Nod to the rest of what you said) On 03/25/2012 11:45 AM, Benjamin Kreuter wrote: The US government still wants a system where encrypted communications can be arbitrarily decrypted, they just dress up the argument and avoid using dirty words like key escrow. Aside from the deep moral and constitutional problems it poses, does anyone think the US Govt could have that even from a practical perspective? * Some of the largest supercomputers in the world are botnets or are held by strategic competitor countries. This precludes the old key shortening trick. * The Sony PS3 and HDMI cases show just how hard it can be to keep a master key secure sometimes. Master keys could be quite well protected, but from a policy perspective it's still a gamble that something won't go wrong which compromises everyone's real security (cause a public scandal, expose industrial secrets, etc.). * Am I correct in thinking that computing additional trapdoor functions to enable USG/TLA/LEA decryption is not free? Mobile devices are becoming the primary computing devices for many. People may be willing to pay XX% in taxes, but nobody wants to pay a decrease in performance and battery life to enable such a misfeature. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
On Sun, Mar 25, 2012 at 10:55 PM, Marsh Ray ma...@extendedsubset.com wrote: On 03/25/2012 11:45 AM, Benjamin Kreuter wrote: The US government still wants a No, probably parts of it: the ones that don't have to think of the big picture. The U.S. government is not monolythic. The NSA has shown a number of times that they are interested in strong civilian cryptography for reasons of... national security. In a battle between law enforcement and national security the latter has to win. system where encrypted communications can be arbitrarily decrypted, they just dress up the argument and avoid using dirty words like key escrow. Aside from the deep moral and constitutional problems it poses, does anyone think the US Govt could have that even from a practical perspective? * Some of the largest supercomputers in the world are botnets or are held by strategic competitor countries. This precludes the old key shortening trick. * The Sony PS3 and HDMI cases show just how hard it can be to keep a master key secure sometimes. Master keys could be quite well protected, but from a policy perspective it's still a gamble that something won't go wrong which compromises everyone's real security (cause a public scandal, expose industrial secrets, etc.). Key escrow == gigantic SPOF. Even if you split the escrow across several agencies and don't use a single master key, it's still concentrating systemic failure potential into too few points. To build a single point of catastrophic failure into one's economic infrastructure is one of the biggest strategic blunders I can imagine (obviously there's worse, such as simply surrendering when one clearly has the upper hand, say). Back in the early 90s this probably wasn't as clear as it is today. * Am I correct in thinking that computing additional trapdoor functions to enable USG/TLA/LEA decryption is not free? Mobile devices are becoming the primary computing devices for many. People may be willing to pay XX% in taxes, but nobody wants to pay a decrease in performance and battery life to enable such a misfeature. Most users already pay heavy battery/performance taxes in the form of uninstallable adware built into their devices. The vendors might be the ones to object then since they might have to stop shipping such software. But ultimately this argument depends on how heavy a burden the users end up feeling. For my money the winning argument is the strategic idiocy/insanity of unnecessary SPOFs. Who wants to ever even think of saying to the POTUS Mr. President, we have a mole, they've stolen the codes for our civilian networks and they've shut them down from the people's shear fear of financial and other losses. It will take months to re-key everything and in the meantime we'll lose X% of GDP. The stock and bond markets have crashed. As time passes X will tend to increase in the event of such a catastrophe. The higher that percentage the more crippling the attack, with derivatives losses becoming overwhelming at small values of X. It could get worse: Mr. President, we can't even re-key without changing all these hardware dongles that are manufactured by the enemy, who's now not selling them to us. If the point of key escrow is to make law enforcement easier then there are much simpler non-cryptographic solutions -- not ones to your taste or mine perhaps, but certainly ones that don't involve strategic SPOFs. I'm with you: key escrow is necessarily dead letter, at least for the time being and the foreseeable future. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
