I know this is touched at the beginning. But the odd shift at the end to "quantum will break all crypto" seems out of nowhere and makes this sound like a hypothetical tool.
The reason Green talks about quantum computers is because hash-based signatures are one of five or so primary research areas for developing quantum-resistant public-key cryptography. They cannot accommodate public-key encryption, but they are one of the oldest forms of digital signatures. In fact, blockchains and post-quantum resistance are the two major reasons for the renewed research interest in hash-based signatures.
I take it you mean that there are no known hash-based public key encryption systems. I assume you don't intend to say they are provably impossible to construct?
I remember when I first learned about hash-based cryptography I was amazed how hashing was the only cryptographic primitive used. Ever since I regularly (once or twice a year) try to google "hash-based public key" and other combinations in the hope that someday someone will have worked out how to found public key encryption on cryptographic hashing...
It feels impossible but so felt hash-based signatures before learning how to sign a single bit and then generalize to more...
https://www.researchgate.net/profile/Russell_Impagliazzo/pub...
Keep in mind Monte Carlo algorithms versus Las Vegas algorithmms.
Keep also in mind that since cryptographic one way permutations are available, both Alice and Bob can sign their messages on the public channel, and Eve can only read them (for injecting a message would require forging a signature).
Consider the following (absurd) Las Vegas algorithm: both Alice and Bob seperately generate a random secret key. Then they sign the hash of the secret key and inform each other with this <Hash(secret),Signature(Hash(secret))> message.
The Las Vegas secret key exchange protocol succesfully finishes if they read the same hash as they generated, and returns the bottom element or failure if they don't match.
So provably with a (very) low probability they can establish a common secret in a Las Vegas protocol, which begs the question if a dual (necessarily interactive) Monte Carlo protocol can slowly grow an n-bit common secret.
I suspect you can confirm that this is just a brainfart indeed?
For this to work, they'd have to start off with the same secret key already, which makes the key exchange pointless.
You mention using this approach to slowly grow a secret key, by performing many iterations of this protocol, but if you do it bit-by-bit, the adversary can easily brute force invert the OWP over {0, 1}, and thereby learn the secret key
I should have said I do like the article. The explanations were well done and appreciated.
It turns out that using keys for unrelated things can make them into a footgun, so actually even for RSA where we know in principle how to safely use it for lots of purposes, the direction of modern cryptography is to pick one and just do that a lot.
For example, a typical web server "SSL certificate" has an RSA public key baked into it, and the server knows the corresponding private key. You want to exchange encrypted messages with this server, so you use RSA encryption right?
Nope. In the almost-published TLS 1.3 you proceed as follows: 1. Use ephemeral Diffie-Hellman to agree random new symmetric encryption keys, and immediately use those to do AEAD encryption for everything further 2. Send (encrypted) your Certificate. 3. Take a transcript of everything that happened so far, and _sign_ that transcript using RSA, send (encrypted) the signature.
This setup means an attacker can't make even a dumb server do any operations with their RSA private key except signing transcripts of sessions in which that server got to make random key choices. This is useless for any conceivable shenanigans so long as RSA is no more insecure that we think it is, and even if RSA is insecure, you need to actively penetrate specific sessions, the DHE protects any other sessions, even if you subsequently get all the private keys.
Well but its still for "just signing things" in TLS when DH is used no?
>"Nope. In the almost-published TLS 1.3 you proceed as follows: 1. Use ephemeral Diffie-Hellman to agree random new symmetric encryption keys, and immediately use those to do AEAD encryption for everything further 2. Send (encrypted) your Certificate. 3. Take a transcript of everything that happened so far, and _sign_ that transcript using RSA, send (encrypted) the signature."
I haven't read the draf but in TLS 1.2 with DH and RSA, RSH is used to sign the DH parameters. Is this different in TLS 1.3? I guess I don't understand what you mean by "transcript" though. Is that word in the spec?
Yes the specification says, and means, transcript. Signing the entire communications transcript means a MitM can't touch anything.
Example, if a client optimistically wants to use VeryVerySecure feature and we are a MitM who wants to prevent that, we might think to fake a message from the server saying "No, I don't understand VeryVerySecure - do WeakAntique instead". In TLS 1.3 this extra message will be in the client's transcript, so a transcript signature from the server without any mention of VeryVerySecure fails and our MitM attack with it.
Indeed, although straight RSA encryption fell out of favor some time ago. I see your original point now. Cheers.