forked from snabbco/snabb
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request snabbco#5 from eugeneia/vita-ske1-impl-g
New key negotation protocol and implementation Resolves snabbco#1 (KexExchange is generally broken and needs replacement) Includes snabbco#4 (Route inbound packets via SPI)
- Loading branch information
Showing
17 changed files
with
1,383 additions
and
305 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,89 @@ | ||
VITA: SIMPLE KEY EXCHANGE (vita-ske, version 1g) | ||
|
||
A simple key negotiation protocol based on pre-shared symmetric keys that | ||
provides authentication, perfect forward secrecy, and is immune to replay | ||
attacks. | ||
|
||
Primitives (from libsodium 1.0.15): | ||
|
||
• HMAC: crypto_auth_hmacsha512256 (key is 256‑bits, output is 256‑bits) | ||
• DH: crypto_scalarmult_curve25519 (keys are 256‑bits, output is 256‑bits) | ||
• HASH: crypto_generichash_blake2b (output is choosen to be 160‑bits) | ||
|
||
Notational Conventions: | ||
|
||
→ m | ||
Denotes that we receive the message m. | ||
|
||
← m | ||
Denotes that we send the message m. | ||
|
||
a ‖ b | ||
Denotes a concatenated with b. | ||
|
||
Description: | ||
|
||
Let k be a pre-shared symmetric key. Let spi be a “Security Parameter Index” | ||
(SPI). Let n1 and n2 be random 256‑bit nonces, where n1 is chosen by us. | ||
|
||
← n1 | ||
→ n2 | ||
|
||
Let (p1, s1) and (p2, s2) be random, ephemeral, asymmetric key pairs, where | ||
(p1, s1) is choosen by us. Let h1 = HMAC(k, spi ‖ n1 ‖ n2 ‖ p1). | ||
|
||
← p1 ‖ h1 | ||
→ p2 ‖ h2 | ||
|
||
Ensure that h2 = HMAC(k, spi ‖ n2 ‖ n1 ‖ p2). Let q = DH(s1, p2), and ensure | ||
that p2 is a valid argument. Let rx = HASH(q ‖ p1 ‖ p2) and | ||
tx = HASH(q ‖ p2 ‖ p1) be key material. Assign (spi, rx) to the incoming | ||
“Security Association” (SA), and (spi, tx) to the outgoing SA. | ||
|
||
The description above illustrates the perspective of an active party adhering | ||
to the protocol, i.e. the exchange is initiated by us. An opposite, passive | ||
party adhering to the protocol, i.e. one that is merely responding to a key | ||
exchange initiated by an active party, must ensure that the tuple | ||
(spi, p2, h2) was received and authenticated before computing and sending its | ||
response tuple (spi, p1, h1). For a passive party the order of messages during | ||
the exchange is reversed: | ||
|
||
→ n2 | ||
← n1 | ||
→ p2 ‖ h2 (ensure h2 is verified before we reply) | ||
← p1 ‖ h1 | ||
|
||
Note that there might be no passive party in an exchange if both parties have | ||
initiated the exchange before receiving an initial nonce message. | ||
|
||
Security Proof: | ||
|
||
Assuming an attacker can not guess k, and n1 has enough entropy so that the | ||
probability that the tuple (n1, p2) has occurred before is negligible, they | ||
are unable to produce the value h2 = HMAC(k, spi ‖ n2 ‖ n1 ‖ p2), and thus are | ||
unable to complete a key exchange. | ||
|
||
Assuming an attacker can not guess s1 or s2, they are unable to produce | ||
q = DH(s1, p2) or q = DH(s2, p1), and subsequently derive rx or tx, and thus | ||
perfect forward secrecy is provided. | ||
|
||
A party passively adhering to the protocol will not produce a tuple | ||
(spi, p1, h1) unless it has previously authenticated its counterpart tuple | ||
(spi, p2, h2), and thus can not be used as an oracle. | ||
|
||
Notes: | ||
|
||
• Future versions of this protocol may introduce the use of a key derivation | ||
function (KDF), such as libsodium’s crypto_kdf_blake2b_derive_from_key, to | ||
derive additional key material from rx or tx. | ||
|
||
References: | ||
|
||
• The spiped protocol: | ||
https://github.com/Tarsnap/spiped/blob/d1e62a8/DESIGN.md#spiped-design | ||
• Additional discussion of the spiped protocol: | ||
https://github.com/Tarsnap/spiped/issues/151 | ||
• The Sodium crypto library (libsodium): | ||
https://download.libsodium.org/doc/ | ||
• Security Architecture for the Internet Protocol: | ||
https://tools.ietf.org/html/rfc4301 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.