Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
Without doing any key management or requiring some kind of reliable identity or memory of previous sessions, the best we can do in the inner protocol is an ephemeral Diffie-Hellman, so suppose we do this: a. Generate random a and send aG on curve P256 b. Generate random b and send bG on curve P256 c. Both sides derive the shared key abG, and then use SHAKE512(abG) to generate an AES key for messages in each direction. d. Each side keeps a sequence number to use as a nonce. Both sides use AES-CCM with their sequence number and their sending key, and keep track of the sequence number of the most recent message received from the other side. ... Thoughts? We should get Stev Knowles explain the skeeter and bubba TCP options. From private conversations I understand that the options where doing pretty much what you describe: use Diffie Hellman in the TCP exchange to negotiate an encryption key for the TCP session. That would actually be a very neat thing. I don't believe using TCP options would be practical today, too many firewalls would filter them. But the same results would be achieved with a zero-knowledge version of TLS. That would make session encrypted by default. Of course, any zero-knowledge protocol can be vulnerable to man-in-the-middle attacks. But the applications can protect against that with an end to end exchange. For example, if there is a shared secret, even a lowly password, the application protocol can embed verification of the zero-knowledge session key in the password verification, by combining the session key with either the challenge or the response in a basic challenge-response protocol. That would be pretty neat, zero-knowledge TLS, then use the password exchange to mutually authenticate server and client while protecting against MITM. Pretty much any site could deploy that. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
Given that many real organizations have hundreds of front end machines sharing RSA private keys, theft of RSA keys may very well be much easier in many cases than broader forms of sabotage. Or we could make it easy to have one separate RSA key per front end, signed using the main RSA key of the organization. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am certainly not going to advocate Internet-scale KDC. But what if the application does not need to scale more than a network of friends? A thousand times yes. There is however a little fly in that particular ointment. Sure, we can develop system that manage pairwise keys, store them safely, share them between several user devices. But what about PFS? Someday, the pairwise key will be compromised, and the NSA will go back to the archives to decrypt everything. We could certainly devise a variant of DH that use the pairwise key to verify the integrity of the session keys, but that brings the public key technology back in the picture. Maybe I am just ignorant, but I don't know how to get PFS using just symmetric key algorithms. Does someone know better? - -- Christian Huitema -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSLU6uAAoJELba05IUOHVQ32QH/jVt7j/FpZXc7G07fvfu8/ij 4h53Vn0dfNZmX+XLNX3yILizSz712bGEGWVnq7nPh1IB9JEbYu0lFJxzXbZB6Cv1 Owu+QKnJ1NgctggwKkaCwOELFPNEZ1amzu3f+Haxrq9knv/H2/mykpLPyRR0IU8T 8KFoud1rg7nffIW+flkEGVGgcExibjXOd8H7+/q6Mu6u4/aVJ4O3m2c1sv0kLhl3 gPIeoD8LlRBERUslkqF/jEv6PVgByLD8D94/f7wJ34e9RZQNILPH2dGdck02G/vK IimsR7K/9cB0KhNnIIqCnmxYSvm7KU97h6ejm5lyyZPTtnoDPjfEU+0w7vl5uMs= =ze/o -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
Pairwise shared secrets are just about the only thing that scales worse than public key distribution by way of PGP key fingerprints on business cards. The equivalent of CAs in an all-symmetric world is KDCs. Instead of having the power to enable an active attack on you today, KDCs have the power to enable a passive attack on you forever. If we want secure crypto that can be used by everyone, with minimal trust, public key is the only way to do it. I am certainly not going to advocate Internet-scale KDC. But what if the application does not need to scale more than a network of friends? -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Der Spiegel: NSA Can Spy on Smart Phone Data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apparently this was just a teaser article. The following is apparently the full story: http://cryptome.org/2013/09/nsa-smartphones.pdf I can't tell for sure - it's the German original, and my German is non-existent. The high level summary is that phones contain a great deal of interesting information, that they can target IPhone and Android phone, and that after some pretty long efforts they can hack the Blackberry too. Bottom line, get a Windows Phone... - -- Christian Huitema -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSLUz0AAoJELba05IUOHVQTvUH/2XXo92DcMKpWUQ/8q4dg8BY 4B+/ytLy8tpBH33lT+u1yTpnLH/OV0h6mQdIusMun94JugGlJiePe0yC6zcsEE+s OgU1SNdvqRoc5whTiV6ZIMfoOakyzeLPonS+gZ6hOWBLjQf52JNVHE4ERWTOK5un iymLK36wTFqHceF6+iVrJEwaYEvLURpUB2U3dghC5OJyQzf5yqCvdYP18iStz2WT woSJikGps2dS7eV6vPtkqhar5EWXHpPPAYwZbDskuMx10Y8Z8ET+HTFAw5rV3d3L 925adBWQLjR73wpANRyH85LtsK6nJlJzW0D1IMBmFyOqKZsOxjZQ75dAyi4oE+o= =/S/b -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. But of course, sufficiently paranoid people might contend that perhaps the Microsoft people who complained might not have been briefed by the ones who cooperated. I would be very surprised if they had gotten any assistance from Microsoft. It goes against the grain. Microsoft engineers are really indoctrinated with the trustworthy computing agenda, with mandatory security training every year, specialized design reviews, code reviews, tests and all that. Not saying there are no bugs or oversights in Microsoft's code, but a deliberate action like that is very unlikely. Also, It would be very difficult to keep something like that secret for long, and the leak would have dire effects on the company's reputation. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is exactly the problem that Kim Cameron and I tried to solve by developing what we called call signs. The idea is to compress the hash of the public by solving a puzzle: find the arbitrary salt so that the hash of the salt and the public key ends with a large enough number of zeroes. (Or 1, or any arbitrary patterns.) Publish then the call sign as a fraction of the hash, say the leading bits, that is short enough to be memorized, or at least written on a napkin. Of course, you have to verify that N bits of call signs + M zeroes is long enough to provide a strong hash. The birthday paradox tells us that collisions will happen after 2^(N/2) users in the same space. We assumed that the practical length was at most 10 characters, 50 bits, which means collisions would happen after a few million users. We mitigated that by adding a human identifier in the mix, making the call sign something like Perry.A32-H45Z-ZE0. Now the collisions only happen in the space of all people named Perry, which is much smaller than everybody. Of course, this was a Microsoft project, which Microsoft did not choose to develop. And it was patented... - -Original Message- From: cryptography-bounces+huitema=huitema@metzdowd.com [mailto:cryptography-bounces+huitema=huitema@metzdowd.com] On Behalf Of Perry E. Metzger Sent: Wednesday, August 28, 2013 5:53 AM To: Jerry Leichter Cc: Wendy M. Grossman; cryptography@metzdowd.com Subject: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks) On Tue, 27 Aug 2013 23:52:23 -0400 Jerry Leichter leich...@lrw.com wrote: But none of that matters much any more. Publication is usually on-line, so contact addresses can be arbitrary links. When we meet in person, we can exchange large numbers of bits between our smartphones. Hell, even a business card can easily have a QR code on the back. Just as an FYI, this describes exactly zero of the times that I've gotten people's email or jabber addresses in recent years. Very typically people have written them down for me, told them to me over the phone, or the equivalent. I've had to read mine over the phone a fair bit, too. I wouldn't know how to trust publication online in the first place. Perry Metzger's email is big string How do I know that's true? Because it is encrypted in big string What if that's a lie? I've never heard Perry utter big string What, you don't trust me? No dishonest person has a web server! If someone tells me they're f...@example.com, and I have a trustworthy way of mapping f...@example.com into a long lived key (see my first message in this sequence of three that triggered this discussion), life is a lot better. I think this alone is a lot of why X.500 died so fast compared to SMTP -- the addresses were simply untenable, and they were at least in theory human readable. Anyway, I've already started implementing my proposed solution to that part of the problem. There is still a need for a distributed database to handle the lookup load, though, and one that is not the DNS. Perry - -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSHgr0AAoJELba05IUOHVQdwgH/2bhJZYagObK1yzl27r9w+BP ests/CMmUOVxnAnICY0MeoH5/GLbyNX2u5ZKGh32DikoTCFEHpMItgxpT8hQpEtD 81j5NV4X2qRaYc183C0HGxpJe2Cq2vQNAVGTJbJAV08dDZuu2W/IxuPsBjF0U3p+ yxham0qSnbngYSNBi31WXg4X08EV/Z3H5NoTsWkiHfSs+LLcyT9uNXwi7IxP4tmU filmYGKBIdw16A9wGuqAy/V7edFG4tqgNtVdKH+yAYDGwY7NW+NYzOQCn8HOMQ4w sxXMDuUEg+KQ1PvtfIgk3tfTSEb45Rsiu9VH2Vir9PKOzzCzQIneJvG2V8nCDdI= =AtVw -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The DHT model says that millions of Raspberry Pi's and thumb drives together implement this immense database. But since a DHT, by design, scatters the data around the network at random, *my* thumb drive is full of information that I will never need - all the information *I* need is out there, somewhere - where, based on the research we've been discussing, I have no secure way to get at it. Why would I buy into such a design? Doesn't it make much more sense for me to store the information relevant to me? When we designed PNRP, I was pretty adamant to avoid this business of storing other people's data. We assumed that your data would be stored locally. The cost is a bit of added synchronization cost, effectively scaling as the number of records that have to be published. But if you are looking at a P2P name server type application, there are very few such records. Basically, the less nodes rely on strangers, the better. - -- Christian Huitema -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSHYReAAoJELba05IUOHVQuJsH/2W+6CLtc+IRjH/7ufNhlIx8 F8H30+vt3D1QxikluwKkzBB3HVxSiZL1N1z5z63Vvi9a+nIzuJPX8xNJf27tvvp7 gcHQqTz3J/Ffa2pX0fjtr83bpfBg+x27b7T4gBdbuN1KZ3sesQaHXWurCV2bz3Nb 9IDn2PYBOna+FXM/fMA8cpvElb+C6rEDvO0hcW1CVIxutt3yLICR3rAnyzhFQSUP 7MbnOZ7iSXRrmgvY3ukmI+OsAf9iOEavxdmgMYJJj1istyg1PMHcFH3MPoxggrfl 9ESTc1wiiZYsVF3r0SXf0DI08J8z7RXzJ/0WY9PUGgxQ49CEYgsq9ZSpUUfEm7Y= =4LGc -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Suppose, as in Bitcoin, my email address *is* my public key You can even use some hash compression tricks so you only need 9 or 10 characters to express the address as hash of the public key. That works very well, until you have to change the public key. - -- Christian Huitema -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSHYUrAAoJELba05IUOHVQkb0H/ixGQK+kLx+SYp1FRJB5UF/Y lEfP8UGt+FVUweq3N0OWG7JB4HJzg14+tLbYjpkq6tJdJJPdoyDUVX9NgNvHRwl0 ELB3xhpXtXUg1YbM+IPrGVHDJUp6oBMnM4LEjnT5UP9kSW3yrkm9tu7k3bo9Xq/i gShIWOZcWVCxsY4WI/RetfXvLI/xZQwczxBzmTcSfB8w7khvpyr98VW5PMeX6Uu1 VBEN4dZiUIjKvhN0HMGMZtDrfbWeXIvGYkA5OjTeAGDExt5C+nvB3BCb87pGf8NJ nTrRgLNJjU6hpD7giPD0SgLOe9uye5DXrUyOwSmHGCgqZjj/P07+i/nyJczwZ48= =iZk1 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
I think we can agree that the first step is to deploy home servers, and that the first application there would to host communication applications. Just doing that without much other change would already provide protection against the silent spying that goes on in big cloud servers. Initial deployment of anything must provide an immediate reward to the early adopters. You cannot rely on a network effect, and that means you can certainly not request third parties to adopt a new protocol. So better pinch our noses and say that, of course, we will accept SMTP mail. Probably SIP as well, and XMPP. We just need at first to make sure that the home server is easy to deploy and maintain. Then the adopters get the immediate reward, nobody can go through my mail archives without asking me. The various P2P enhancements come next, once there already is a network of home servers. The obvious one is a communication application that beats traffic analysis by embedding its own shuffling or onion routing. I don't think we can run anything like that directly on a phone, it would drain the battery way too quickly. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
My knowledge of the field is pretty spotty in general as I've never paid much attention up until now -- mostly I know about how people have built DHTs in non-hostile environments. I'm close enough to starting from scratch that I don't know yet what I don't know. I studied such systems intensely, and designed some (http://en.wikipedia.org/wiki/Peer_Name_Resolution_Protocol). Using a distributed hash table securely is really hard. The basic idea of DHT is that information is spread on the network based on matches between the hash of a resource identifier and the hash of a node identifier. All nodes are effectively relying on every other node. In an open network, that is pretty much equivalent to relying on the goodness of strangers. You can be sure that if our buddies at the NSA set up to watch the content of a DHT, they will succeed. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
That is not my worry. Signing the data posted to the DHT can prevent spoofing, querying it over a mix network or using a PIR protocol can prevent eavesdropping. I'm more worried about various sorts of denial of service attacks, or service being shut down by inadvertent behavior. Of course the data can be signed, encrypted, etc. But the rule of the game is that the adversary can manufacture as many peers as they want -- something known as the Sybil attack. They can then perform various forms of denial. For example, the connectivity of the DHT generally relies on connectivity between nodes of similar indices. The attackers can research hashes that fall very near the hash of the target node, add the corresponding nodes in the DHT, and effectively place themselves in the path of DHT traffic meant for the target node. This enables passive traffic analysis, and active denial of service. Another potential attack is to get node indices close to that of a popular resource, effectively becoming the repository of record for that resource. Again, that enables passive traffic analysis, e.g. finding who accesses a specific resource, and also active denial of service attacks. If the attackers can manufacture enough virtual nodes, they obtain control of the network. They can use that passively for global traffic analysis. They can also engineer selective disruption, inject traffic to DOS specific nodes, and other fun games. Bottom line, anonymous DHT are fragile. If we want something robust, we have to forgo the mathematical elegance of the DHT, and adopt a network structure in which nodes only connect to peers that they trust. You could call that networks of friends. That removes the nice O(log N) properties of the DHT, and it becomes hard to guarantee that all queries will converge. But the network becomes much harder to penetrate. The old Freenet had a structure like that. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
