Beyond EAP-Keccak, EAP-KeccakV1 For Encrypted Communications
This article builds on some of the ideas presented in the article, EAP-Keccak, A Proposed Authentication Protocol for Enterprise Environments. You might want to read that before this…
The initial submission for the EAP-Keccak protocol will focus on authentication. However this is just the beginning. Aside from authentication, EAP protocols also exist for encryption. And it turns out that the Ethereum Wildfire Project also has something to contribute in the field of encryption. And doing so will further benefit the cause of disseminating Ethereum-based tools. But before we delve into our vision for an encrypted Keccak-based protocol, we need to review some basic encryption concepts.
Basic Encryption Concepts
In an encrypted communication a plain-text message is encoded, using an encryption-key, into a cipher-text message that can only be decoded using a decryption-key. There are many different encoding/decoding algorithms, called ciphers. But broadly speaking ciphers can be classified as either symmetrical, meaning that the encryption-key is the same as the decryption-key, or asymmetrical, meaning that the two keys are different. In the case of asymmetrical encryption each side of the communication actually has a key-pair; that is, two keys that work together, one public and one private. A message that is encrypted with the public-key can only be decrypted with the private-key, and vice-versa. Each side of the encrypted channel shares its public key, which is used by the other side to encrypt messages before sending them. Upon receiving an encrypted message each side uses its private key, which is never shared, to decrypt the message.
The Key Distribution Problem
It’s not enough for an encryption cipher to make a conversation opaque to a nefarious eavesdropper who does not posses the appropriate decryption keys. When using symmetrical keys there’s a very real problem of getting the endpoints to agree on what key to use in such a way that a nefarious eavesdropper, who might be listening in on the key negotiations cannot learn the key. This problem is analogous to me wanting to send you a treasure, but not trusting the mailman. I can send the treasure locked in a box; but how can I send you the key to the lock in such a way that the mailman can’t make a copy of it?
In some cases the protocols skirt the issue, and simply specify that both sides of the communications must already have a “pre-shared-key”, or that the symmetrical key is derived from a pre-shared password. Despite being conceptually straightforward, in many cases this is either not practical, or it is insecure.
The SSL Solution
Of course there is a solution to the Key Distribution Problem, and it’s used by the SSL/TLS protocol which is familiar to us all through https websites. The solution is to use asymetrical encryption to negotiate a shared symetrical encryption key. That is, each side of the communication can freely share it’s public-key, and the other side can encrypt every message. Since the public keys are only used to encrypt, a third party cannot decrypt the messages, even if he collects the public keys. In the un-trustworthy mailman analogy, this would be like me sending you a lock, instead of a key. Then you can put a new (symetrical) key inside a box, and lock the box with the lock that I sent you. When I open the box then I get the key to the shared lock.
By the way, in case you’re wondering, theoretically the entire communication could take place using asymmetrical encryption. The reason that we are so keen to use symmetrical encryption is that it’s much more efficient. That’s the reason that asymmetrical cryptography is only used to negotiate shared symmetrical keys.
Public Key Certificates
You might have noticed that the SSL solution, as I stated it above, doesn’t protect the endpoints from what is known as a man-in-the-middle attack. In this sort of attack a nefarious third party inserts himself between the endpoints and impersonates each endpoint to the other. In this way the man in the middle would negotiate a shared symmetrical key with each endpoint. In SSL/TLS this problem is solved by using signed certificates and certificate authorities. A signed certificate is essentially a message stating who I am. But the message is encrypted with my private key. If you can decrypt the message with my public key, and you check my public key against a trusted database of public-keys (so that you know the public key really belongs to me), then you know that the message originated from me, and it was not tampered-with. A critical part of this solution is that there exist central authorities, called certificate authorities, who maintain trusted registries of public keys.
The Keccak Opportunity
Although there already exist EAP algorithms that provide TLS encryption, more or less as described above, there is an opportunity to improve on what is out there. For one, every crypto-currency enthusiast should have gotten a chill when I mentioned that public certificate authentication relies on central authorities. Wouldn’t it be great if there was a de-centralized solution to the man-in-the-middle problem? Aside from this, practically it’s often too difficult to get a signed certificate from one of the “recognized” certificate authorities, so many people either use self-signed certificates (which really don’t protect against man-in-the-middle attacks), or they use other encrypted EAP algorithms, which takes us back to the hassles and insecurities of shared passwords and pre-shared keys. In the coming paragraphs we will present a solution that uses Ethereum’s Keccak hash and circumvents these objections. But first we need to take a short detour to discuss another key distribution technique…
Diffie-Hellman-Merkle key Exchange
Diffie-Hellman-Merkle key exchange does not use public key cryptography during the key exchange. It is a clever system of exchanging private information, such that even if a nefarious third party eavesdrops on the communication, they cannot acquire the negotiated symmetrical keys. The Diffie-Hellman-Merkle protocol relies on a mathematical one-way function,
f(b,s,p) = (b^s) % p
^ is the exponent operator, and
% is the modulus (remainder) operator, and
p is a prime number, and
b is a number chosen from a special group of numbers, related to
the prime number p, for which a particular relation holds true
In this context we call the function one-way because, even if you know g and p, and also know the result,
(b^s)%p, it is still not possible to derive s. (By the way, to keep these variables straight in your mind, b stands for base; s stands
for secret; and p stands for prime-number). In the Diffie-Hellman-Merkle key exchange the values b and p are negotiated in the open, but each endpoint chooses their own secret (s). Then each endpoint announces the result of the one-way function, based on b, p, and their own secret s. Lastly, each endpoint computes the one way function again (using their own secret), but replaces b with the result that was announced from the other endpoint. The result for both sides will be the same, even though neither side (nor any observer) knows the other sides’s secret.
sP be a secret number chosen by the Peer, and
sA be a secret number chosen by the Authenticator, and
oP = f(b,sA,p); that is, oP is the Peer's secret number,
obfuscated by the one-way function, and
oA = f(b,sA,p); that is, oA is the Authenticator's secret number,
obfuscated by the one-way, and
Key(P) be the shared key computed by the Peer, and
Key(A) be the shared key computed by the Peer, then
1. The Authenticator selects a random sA
2. The Peer selects a random value sP
3. The Authenticator computes and announces oA
4. The Peer computes and announces oP
5. The Authenticator and Peer each compute the Key(A)
key(P) = f(b,oA,p)
= f( f(b,sA,p), sP, p)
= (b^sA % p)^sP % p
key(A) = f(b,oP,p)
= f( f(b,sP,p), sA, p)
= (b^sP % p)^sA % p
Recall that the number b was specially chosen for the number p.
It was chosen as a "primitive root, modulo p" which really just
means that it was chosen such that:
(b^sA % p)^sP % p = (b^sP % p)^sA % p
holds true for all values of sA and sP
key(P) = key(A)
We will provide an example exchange in a moment. But first note that the Diffie-Hellman-Merkle key exchange protocol does not in itself provide authentication of the identity of the endpoints, nor does it prevent a man-in-the-middle attack. For this reason the technique is usually combined with passwords, pre-shared keys, or signed public-key certificates.
The proposed EAP-KeccakV1 protocol identifies each endpoint by their Ethereum address. (A mnemonic may be used and validated via the Ethereum Name Service). But beyond each side authenticating its identity by signing the challenge message, it is possible to conduct an entire Diffie-Hellman-Merkle key exchange, and Keccak-hash/ECSDA-sign each message so that it cannot be tampered-with by a man-in-the-middle. Here is a simplified example of how the exchange would proceed (in practice p is a very large prime number):
includes Ethereum address
<--- EAP-KeccakV1 Setup message:
use parameters b=5, p=23
signed with Ether private key
using secret sP=7 compute:
oP = b^sP % p = 5^7 % 23 = 17
Peer one-way obfuscated --->
secret, oP is 17
keccak signed with
Ether private key
using secret sA=3 compute:
oA = b^sA % p = 5^3 % 23 = 10
<--- Authenticator one-way obfuscated
secret, oA, is 10
keccak signed with Ether
compute shared secret compute shared-secret
key = oA^sP % p key = oP^sA % p
= 10^7 % 23 = 14 = 17^3 % 23 = 14
The reason that this works is that a third party eavesdropper only hears the setup parameters
b=5,p=23, and the two one-way obfuscated, secrets
oA=10. The eavesdropper never hears the actual secrets,
sA=3. And because the obfuscating functions are one-way, there is no way to derive the secrets from the obfuscated secrets.
Note that in the EAP-KeccakV1 version of the Diffie-Hellman-Merkle key exchange no public key cryptography is used at all. It is also not necessary to authenticate using a secret password or pre-shared keys. All of the authentication is accomplished by virtue of the fact that each message in the key exchange is signed and can be validated using ecrecover.
Ethereum Wildfire Project
With sufficient funding the Ethereum Wildfire Project will develop and submit an Internet Draft to the IETF in order formalize the EAP-KeccakV1 protocol. At the same time we plan to submit a module supporting EAP-KeccakV1 to the FreeRadius project (which supplies a very popular, free, open-source RADIUS server). We believe that the most effective way to popularize the Ethereum-based login technique is via enterprise adoption; that is, workplaces that adopt this protocol will require their employees to use it. Check out the Token-Sale section of our website to see how you can contribute to help us evangelize this technique.
Yaniv Shapiro and Radhika Anand for the
Ethereum Wildfire Project