diff --git a/Cargo.lock b/Cargo.lock index 408d357..caa73f8 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -2568,9 +2568,9 @@ checksum = "a8f112729512f8e442d81f95a8a7ddf2b7c6b8a1a6f509a95864142b30cab2d3" [[package]] name = "stacker" -version = "0.1.19" +version = "0.1.21" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d9156ebd5870ef293bfb43f91c7a74528d363ec0d424afe24160ed5a4343d08a" +checksum = "cddb07e32ddb770749da91081d8d0ac3a16f1a569a18b20348cd371f5dead06b" dependencies = [ "cc", "cfg-if", diff --git a/Cargo.toml b/Cargo.toml index ae45898..c8fd636 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -88,7 +88,7 @@ assert_tv = { version = "0.6.4" } base64 = { version = "0.22.1" } serial_test = "3.2.0" tempfile = "3" -stacker = "0.1.17" +stacker = "0.1.21" libfuzzer-sys = "0.4" test_bin = "0.4.0" criterion = "0.5.1" diff --git a/analysis/03_identity_hiding_initiator.entry.mpv b/analysis/03_identity_hiding_initiator.entry.mpv deleted file mode 100644 index 2d63043..0000000 --- a/analysis/03_identity_hiding_initiator.entry.mpv +++ /dev/null @@ -1,25 +0,0 @@ -#define INITIATOR_TEST 1 - -#include "rosenpass/03_identity_hiding.mpv" - -// nounif a:Atom, s:seed, a2:Atom; -// ConsumeSeed(a, s, a2) / 6300[conclusion]. - -nounif v:seed_prec; attacker(prepare_seed(trusted_seed( v )))/6217[hypothesis]. -nounif v:seed; attacker(prepare_seed( v ))/6216[hypothesis]. -nounif v:seed; attacker(rng_kem_sk( v ))/6215[hypothesis]. -nounif v:seed; attacker(rng_key( v ))/6214[hypothesis]. -nounif v:key_prec; attacker(prepare_key(trusted_key( v )))/6213[hypothesis]. -nounif v:kem_sk_prec; attacker(prepare_kem_sk(trusted_kem_sk( v )))/6212[hypothesis]. -nounif v:key; attacker(prepare_key( v ))/6211[hypothesis]. -nounif v:kem_sk; attacker(prepare_kem_sk( v ))/6210[hypothesis]. -nounif Spk:kem_sk_tmpl; - attacker(Creveal_kem_pk(Spk))/6110[conclusion]. -nounif sid:SessionId, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Seski:seed_tmpl, Ssptr:seed_tmpl; - attacker(Cinitiator( *sid, *Ssskm, *Spsk, *Sspkt, *Seski, *Ssptr ))/6109[conclusion]. -nounif sid:SessionId, biscuit_no:Atom, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Septi:seed_tmpl, Sspti:seed_tmpl, ih:InitHello_t; - attacker(Cinit_hello( *sid, *biscuit_no, *Ssskm, *Spsk, *Sspkt, *Septi, *Sspti, *ih ))/6108[conclusion]. -nounif rh:RespHello_t; - attacker(Cresp_hello( *rh ))/6107[conclusion]. -nounif Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, ic:InitConf_t; - attacker(Cinit_conf( *Ssskm, *Spsk, *Sspkt, *ic ))/6106[conclusion]. diff --git a/analysis/03_identity_hiding_responder.entry.mpv b/analysis/03_identity_hiding_responder.entry.mpv deleted file mode 100644 index 5908a72..0000000 --- a/analysis/03_identity_hiding_responder.entry.mpv +++ /dev/null @@ -1,96 +0,0 @@ -#define RESPONDER_TEST 1 - -#include "rosenpass/03_identity_hiding.mpv" - -// select k:kem_pk,ih: InitHello_t; attacker(prf(prf(prf(prf(key0, PROTOCOL), MAC), kem_pk2b(k) ), IH2b(ih))) phase 1/6300[hypothesis]. - -// select epki:kem_pk, sctr:bits, pidiC:bits, auth:bits, epki2:kem_pk, sctr2:bits, pidiC2:bits, auth2:bits; -// mess(D, prf(prf(prf(prf(key0,PROTOCOL),MAC),kem_pk2b(kem_pub(trusted_kem_sk(responder1)))), -// IH2b(InitHello(secure_sidi, *epki, *sctr, *pidiC, *auth))) -// ) [hypothesis, conclusion]. - -// select epki:kem_pk, sctr:bits, pidiC:bits, auth:bits, epki2:kem_pk, sctr2:bits, pidiC2:bits, auth2:bits; -// attacker(choice[prf(prf(prf(prf(key0,PROTOCOL),MAC),kem_pk2b(kem_pub(trusted_kem_sk(responder1)))), -// IH2b(InitHello(secure_sidi, *epki, *sctr, *pidiC, *auth))), - -// prf(prf(prf(prf(key0,PROTOCOL),MAC),kem_pk2b(kem_pub(trusted_kem_sk(responder2)))), -// IH2b(InitHello(secure_sidi, *epki2, *sctr2, *pidiC2, *auth2)))] -// ) [hypothesis, conclusion]. - -// select -// attacker(prf(prf(key0,PROTOCOL),MAC)) [hypothesis, conclusion]. - -// select -// attacker(prf(key0,PROTOCOL)) [conclusion]. - -// select -// attacker(key0) [conclusion]. - -// select -// attacker(PROTOCOL) [conclusion]. - -// select -// attacker(kem_pub(trusted_kem_sk(responder1))) /9999 [hypothesis, conclusion]. - -// select -// attacker(kem_pub(trusted_kem_sk(responder2))) /9999 [hypothesis, conclusion]. - -// nounif ih:InitHello_t; -// attacker(ih) / 9999 [hypothesis]. - -// nounif rh:RespHello_t; -// attacker(rh) / 9999 [hypothesis]. - -// nounif ic:InitConf_t; -// attacker(ic) / 9999 [hypothesis]. - -// nounif k:key; -// attacker(ck_hs_enc( *k )) [hypothesis, conclusion]. - -// nounif k:key; -// attacker(ck_hs_enc( *k )) phase 1 [hypothesis, conclusion]. - -// nounif k:key, b:bits; -// attacker(ck_mix( *k , *b )) [hypothesis, conclusion]. - -// nounif k:key, b:bits; -// attacker(ck_mix( *k , *b ))phase 1 [hypothesis, conclusion]. - -// // select k:kem_pk, epki2:kem_pk, sctr2:bits, pidiC2:bits, auth2:bits, epki:kem_pk, sctr:bits, pidiC:bits, auth:bits; -// // attacker(choice[Envelope(prf(prf(prf(prf(key0,PROTOCOL),MAC),kem_pub(trusted_kem_sk(responder1))), -// // InitHello(secure_sidi, *epki2, *sctr2, *pidiC2, *auth2) -// // ), InitHello(secure_sidi, *epki2, *sctr2, *pidiC2, *auth2)) -// // Envelope(prf(prf(prf(prf(key0,PROTOCOL),MAC),kem_pub(trusted_kem_sk(responder2))), -// // InitHello(secure_sidi, *epki, *sctr, *pidiC, *auth)), -// // InitHello(secure_sidi, *epki, *sctr, *pidiC, *auth)) -// // ]) / 9999[hypothesis, conclusion]. - -// nounif k:key, b1:bits, b2:bits; -// attacker(xaead_enc( *k, *b1, *b2)) / 9999[hypothesis,conclusion]. - -// nounif pk:kem_pk, k:key; -// attacker(kem_enc( *pk , *k )) / 9999[hypothesis,conclusion]. - -// nounif sid:SessionId, biscuit_no:Atom, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Septi:seed_tmpl, Sspti:seed_tmpl, ih:InitHello_t; -// attacker(Cinit_hello( *sid, *biscuit_no, *Ssskm, *Spsk, *Sspkt, *Septi, *Sspti, *ih ))/9999[hypothesis, conclusion]. -// nounif Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, ic:InitConf_t; -// attacker(Cinit_conf( *Ssskm, *Spsk, *Sspkt, *ic ))/9999[hypothesis, conclusion]. -// nounif sid:SessionId, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Seski:seed_tmpl, Ssptr:seed_tmpl; -// attacker(Cinitiator( *sid, *Ssskm, *Spsk, *Sspkt, *Seski, *Ssptr )) /9999 [hypothesis, conclusion]. - -// nounif sid:SessionId, biscuit_no:Atom, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Septi:seed_tmpl, Sspti:seed_tmpl, ih:InitHello_t; -// mess(C, Cinit_hello( *sid, *biscuit_no, *Ssskm, *Spsk, *Sspkt, *Septi, *Sspti, *ih ))/9999[hypothesis, conclusion]. -// nounif Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, ic:InitConf_t; -// mess(C, Cinit_conf( *Ssskm, *Spsk, *Sspkt, *ic ))/9999[hypothesis, conclusion]. -// nounif sid:SessionId, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Seski:seed_tmpl, Ssptr:seed_tmpl; -// mess(C, Cinitiator( *sid, *Ssskm, *Spsk, *Sspkt, *Seski, *Ssptr )) /9999 [hypothesis, conclusion]. -// nounif rh:RespHello_t; -// attacker(Cresp_hello( *rh ))[conclusion]. -// nounif v:seed_prec; attacker(prepare_seed(trusted_seed( v )))/6217[hypothesis]. -// nounif v:seed; attacker(prepare_seed( v ))/6216[hypothesis]. -// nounif v:seed; attacker(rng_kem_sk( v ))/6215[hypothesis]. -// nounif v:seed; attacker(rng_key( v ))/6214[hypothesis]. -// nounif v:key_prec; attacker(prepare_key(trusted_key( v )))/6213[hypothesis]. -// nounif v:kem_sk_prec; attacker(prepare_kem_sk(trusted_kem_sk( v )))/6212[hypothesis]. -// nounif v:key; attacker(prepare_key( v ))/6211[hypothesis]. -// nounif v:kem_sk; attacker(prepare_kem_sk( v ))/6210[hypothesis]. diff --git a/analysis/03_identity_hiding_test.entry.mpv b/analysis/03_identity_hiding_test.entry.mpv deleted file mode 100644 index 1c7afc5..0000000 --- a/analysis/03_identity_hiding_test.entry.mpv +++ /dev/null @@ -1,29 +0,0 @@ -#define INITIATOR_TEST 1 -#define CUSTOM_MAIN 1 - -#include "rosenpass/03_identity_hiding.mpv" - -let Oinitiator_bad_actor_inner(sk_tmp:kem_sk_prec) = - - in(C, Cinitiator(sidi, Ssskm, Spsk, Sspkt, Seski, Ssptr)); - - #if RANDOMIZED_CALL_IDS - new call:Atom; - #else - call <- Cinitiator(sidi, Ssskm, Spsk, Sspkt, Seski, Ssptr); - #endif - - in(C, last_cookie:key); - tmpl <- make_trusted_kem_sk(sk_tmp); - out(C, setup_kem_sk(tmpl)); - Oinitiator_inner(sidi, Ssskm, Spsk, tmpl, Seski, Ssptr, last_cookie, C, call). - -let Oinitiator_bad_actor() = - Oinitiator_bad_actor_inner(responder1) | Oinitiator_bad_actor_inner(responder2) | Oinitiator_bad_actor_inner(initiator1) | Oinitiator_bad_actor_inner(initiator2). - - -let identity_hiding_main2() = - 0 | Oinitiator_bad_actor() | rosenpass_main2() | participants_communication() | phase 1; secretCommunication(). - - -let main = identity_hiding_main2. diff --git a/analysis/04_dos_protection.entry.mpv b/analysis/04_dos_protection.entry.mpv deleted file mode 100644 index e436577..0000000 --- a/analysis/04_dos_protection.entry.mpv +++ /dev/null @@ -1,136 +0,0 @@ -#define CHAINING_KEY_EVENTS 1 -#define MESSAGE_TRANSMISSION_EVENTS 0 -#define SESSION_START_EVENTS 0 -#define RANDOMIZED_CALL_IDS 0 -#define COOKIE_EVENTS 1 -#define KEM_EVENTS 1 - -#include "config.mpv" -#include "prelude/basic.mpv" -#include "crypto/key.mpv" -#include "crypto/kem.mpv" -#include "rosenpass/handshake_state.mpv" - -/* The cookie data structure is implemented based on the WireGuard protocol. - * The ip and port is based purely on the public key and the implementation of the private cookie key is intended to mirror the biscuit key. - * The code tests the response to a possible DOS attack by setting up alternative branches for the protocol - * processes: Oinit_conf, Oinit_hello and resp_hello to simulate what happens when the responder or initiator is overloaded. - * When under heavy load a valid cookie is required. When such a cookie is not present a cookie message is sent as a response. - * Queries then test to make sure that expensive KEM operations are only conducted after a cookie has been successfully validated. - */ - -type CookieMsg_t. -fun CookieMsg( - SessionId, // sender - bits, // nonce - bits // cookie -) : CookieMsg_t [data]. - -#define COOKIE_EVENTS(eventLbl) \ - COOKIE_EV(event MCAT(eventLbl, _UnderLoadEV) (SessionId, SessionId, Atom).) \ - COOKIE_EV(event MCAT(eventLbl, _CookieValidated) (SessionId, SessionId, Atom).) \ - COOKIE_EV(event MCAT(eventLbl, _CookieSent) (SessionId, SessionId, Atom, CookieMsg_t).) - -fun cookie_key(kem_sk) : key [private]. -fun ip_and_port(kem_pk):bits. -letfun create_mac2_key(sskm:kem_sk, spkt:kem_pk) = prf(cookie_key(sskm), ip_and_port(spkt)). -letfun create_cookie(sskm:kem_sk, spkm:kem_pk, spkt:kem_pk, nonce:bits, msg:bits) = xaead_enc(lprf2(COOKIE, kem_pk2b(spkm), nonce), - k2b(create_mac2_key(sskm, spkm)), msg). - -#define COOKIE_PROCESS(eventLbl, innerFunc) \ - new nonce:bits; \ - in(C, Ccookie(mac1, mac2)); \ - COOKIE_EV(event MCAT(eventLbl, _UnderLoadEV) (sidi, sidr, call);) \ - msgB <- Envelope(mac1, msg); \ - mac2_key <- create_mac2_key(sskm, spkt); \ - if k2b(create_mac2(mac2_key, msgB)) = mac2 then \ - COOKIE_EV(event MCAT(eventLbl, _CookieValidated) (sidi, sidr, call);) \ - innerFunc \ - else \ - cookie <- create_cookie(sskm, spkm, spkt, nonce, msg); \ - cookie_msg <- CookieMsg(sidi, nonce, cookie); \ - COOKIE_EV(event MCAT(eventLbl, _CookieSent) (sidi, sidr, call, cookie_msg);) \ - out(C, cookie_msg). \ - -#include "rosenpass/oracles.mpv" - -#include "rosenpass/responder.macro" -COOKIE_EVENTS(Oinit_conf) -let Oinit_conf_underLoad() = - in(C, Cinit_conf(Ssskm, Spsk, Sspkt, ic)); - in(C, last_cookie:bits); - - msg <- IC2b(ic); - let InitConf(sidi, sidr, biscuit, auth) = ic in - - new call:Atom; - - SETUP_HANDSHAKE_STATE() - - COOKIE_PROCESS(Oinit_conf, Oinit_conf_inner(Ssskm, Spsk, Sspkt, ic, call)) - -#include "rosenpass/responder.macro" -COOKIE_EVENTS(Oinit_hello) -let Oinit_hello_underLoad() = - - in(C, Cinit_hello(sidr, biscuit_no, Ssskm, Spsk, Sspkt, Septi, Sspti, ih)); - in(C, Oinit_hello_last_cookie:key); - new call:Atom; - - msg <- IH2b(ih); - let InitHello(sidi, epki, sctr, pidic, auth) = ih in - SETUP_HANDSHAKE_STATE() - - COOKIE_PROCESS(Oinit_hello, Oinit_hello_inner(sidr, biscuit_no, Ssskm, Spsk, Sspkt, Septi, Sspti, ih, Oinit_hello_last_cookie, C, call)) - -let rosenpass_dos_main() = 0 - | !Oreveal_kem_pk - | REP(INITIATOR_BOUND, Oinitiator) - | REP(RESPONDER_BOUND, Oinit_hello) - | REP(RESPONDER_BOUND, Oinit_conf) - | REP(RESPONDER_BOUND, Oinit_hello_underLoad) - | REP(RESPONDER_BOUND, Oinit_conf_underLoad). - -let main = rosenpass_dos_main. - -select cookie:CookieMsg_t; attacker(cookie)/6220[hypothesis]. -nounif v:key; attacker(prepare_key( v ))/6217[hypothesis]. -nounif v:seed; attacker(prepare_seed( v ))/6216[hypothesis]. -nounif v:seed; attacker(prepare_seed( v ))/6216[hypothesis]. -nounif v:seed; attacker(rng_kem_sk( v ))/6215[hypothesis]. -nounif v:seed; attacker(rng_key( v ))/6214[hypothesis]. -nounif v:kem_sk; attacker(prepare_kem_sk( v ))/6210[hypothesis]. - -// nounif Spk:kem_sk_tmpl; -// attacker(Creveal_kem_pk(Spk))/6110[conclusion]. -// nounif sid:SessionId, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Seski:seed_tmpl, Ssptr:seed_tmpl; -// attacker(Cinitiator( *sid, *Ssskm, *Spsk, *Sspkt, *Seski, *Ssptr ))/6109[conclusion]. -// nounif sid:SessionId, biscuit_no:Atom, Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, Septi:seed_tmpl, Sspti:seed_tmpl, ih:InitHello_t; -// attacker(Cinit_hello( *sid, *biscuit_no, *Ssskm, *Spsk, *Sspkt, *Septi, *Sspti, *ih ))/6108[conclusion]. -nounif rh:RespHello_t; - attacker(Cresp_hello( *rh ))/6107[conclusion]. -nounif Ssskm:kem_sk_tmpl, Spsk:key_tmpl, Sspkt:kem_sk_tmpl, ic:InitConf_t; - attacker(Cinit_conf( *Ssskm, *Spsk, *Sspkt, *ic ))/6106[conclusion]. - -@reachable "DOS protection: cookie sent" -query sidi:SessionId, sidr:SessionId, call:Atom, cookieMsg:CookieMsg_t; - event (Oinit_hello_CookieSent(sidi, sidr, call, cookieMsg)). - -@lemma "DOS protection: Oinit_hello kem use when under load implies validated cookie" -lemma sidi:SessionId, sidr:SessionId, call:Atom; -event(Oinit_hello_UnderLoadEV(sidi, sidr, call)) - && event(Oinit_hello_KemUse(sidi, sidr, call)) - ==> event(Oinit_hello_CookieValidated(sidi, sidr, call)). - -@lemma "DOS protection: Oinit_conf kem use when under load implies validated cookie" -lemma sidi:SessionId, sidr:SessionId, call:Atom; -event(Oinit_conf_UnderLoadEV(sidi, sidr, call)) - && event(Oinit_conf_KemUse(sidi, sidr, call)) - ==> event(Oinit_conf_CookieValidated(sidi, sidr, call)). - -@lemma "DOS protection: Oresp_hello kem use when under load implies validated cookie" -lemma sidi:SessionId, sidr:SessionId, call:Atom; -event(Oresp_hello_UnderLoadEV(sidi, sidr, call)) - && event(Oresp_hello_KemUse(sidi, sidr, call)) - ==> event(Oresp_hello_CookieValidated(sidi, sidr, call)). - diff --git a/analysis/rosenpass/03_identity_hiding.mpv b/analysis/rosenpass/03_identity_hiding.mpv index 112ed6c..dc4901c 100644 --- a/analysis/rosenpass/03_identity_hiding.mpv +++ b/analysis/rosenpass/03_identity_hiding.mpv @@ -58,7 +58,7 @@ let secure_init_hello(initiator: kem_sk_tmpl, sidi : SessionId, psk: key_tmpl, r new epkit:kem_pk; // epki new sctrt:bits; // sctr - new pidiCt:bits; // pidiC + new pidi_ct:bits; // pidi_ct new autht:bits; // auth NEW_TRUSTED_SEED(seski_trusted_seed) @@ -70,9 +70,9 @@ let secure_init_hello(initiator: kem_sk_tmpl, sidi : SessionId, psk: key_tmpl, r let secure_resp_hello(initiator: kem_sk_tmpl, responder: kem_sk_tmpl, sidi:SessionId, sidr:SessionId, biscuit_no:Atom, psk:key_tmpl) = - in(D, InitHello(=secure_sidi, epki, sctr, pidiC, auth)); + in(D, InitHello(=secure_sidi, epki, sctr, pidi_ct, auth)); - ih <- InitHello(sidi, epki, sctr, pidiC, auth); + ih <- InitHello(sidi, epki, sctr, pidi_ct, auth); NEW_TRUSTED_SEED(septi_trusted_seed) NEW_TRUSTED_SEED(sspti_trusted_seed) new last_cookie:key; diff --git a/analysis/rosenpass/cookie.mpv b/analysis/rosenpass/cookie.mpv index d28fdef..94cce02 100644 --- a/analysis/rosenpass/cookie.mpv +++ b/analysis/rosenpass/cookie.mpv @@ -19,7 +19,7 @@ fun CookieMsg( COOKIE_EV(event MCAT(eventLbl, _UnderLoadEV) (spkm, spkt, last_cookie);) \ msgB <- Envelope(mac1, RH2b(rh)); \ mac2_key <- create_mac2_key(sskm, spkt) \ - let RespHello(sidi, sidr, ecti, scti, biscuit, auth) = rh in \ + let RespHello(sidi, sidr, ecti, scti, biscuit_ct, auth) = rh in \ if Envelope(mac2_key, msgB) = mac2 then \ COOKIE_EV(event MCAT(eventLbl, _CookieValidated) (spkm, last_cookie);) \ innerFunc \ diff --git a/analysis/rosenpass/handshake_state.mpv b/analysis/rosenpass/handshake_state.mpv index c114d8b..6a6bb29 100644 --- a/analysis/rosenpass/handshake_state.mpv +++ b/analysis/rosenpass/handshake_state.mpv @@ -143,10 +143,10 @@ letfun ENCRYPT_AND_MIX(ct, pt) \ // TODO: Migrate kems to use binary ciphertexts directly #define ENCAPS_AND_MIX(ct, pk, shk) \ ct <- kem_enc(pk, shk); \ - MIX3(kem_pk2b(pk), ct, k2b(shk)) + MIX3(kem_pk2b(pk), k2b(shk), ct) #define DECAPS_AND_MIX(sk, pk, ct) \ DUMMY(shk) <- kem_dec(sk, ct); \ - MIX3(kem_pk2b(pk), ct, k2b(DUMMY(shk))) + MIX3(kem_pk2b(pk), k2b(DUMMY(shk)), ct) // biscuits diff --git a/analysis/rosenpass/oracles.mpv b/analysis/rosenpass/oracles.mpv index d21e6b2..0d8a32d 100644 --- a/analysis/rosenpass/oracles.mpv +++ b/analysis/rosenpass/oracles.mpv @@ -86,8 +86,8 @@ MTX_EV( event RHRjct(RespHello_t, key, kem_sk, kem_pk). ) MTX_EV( event ICSent(RespHello_t, InitConf_t, key, kem_sk, kem_pk). ) SES_EV( event InitiatorSession(RespHello_t, key). ) let Oresp_hello(HS_DECL_ARGS) = - in(C, Cresp_hello(RespHello(sidr, =sidi, ecti, scti, biscuit, auth))); - rh <- RespHello(sidr, sidi, ecti, scti, biscuit, auth); + in(C, Cresp_hello(RespHello(sidr, =sidi, ecti, scti, biscuit_ct, auth))); + rh <- RespHello(sidr, sidi, ecti, scti, biscuit_ct, auth); /* try */ let ic = ( ck_ini <- ck; RESPHELLO_CONSUME() @@ -124,7 +124,7 @@ let Oinit_hello() = call <- Cinit_hello(sidr, biscuit_no, Ssskm, Spsk, Sspkt, Septi, Sspti, ih); #endif // TODO: This is ugly - let InitHello(sidi, epki, sctr, pidiC, auth) = ih in + let InitHello(sidi, epki, sctr, pidi_ct, auth) = ih in SETUP_HANDSHAKE_STATE() eski <- kem_sk0; epti <- rng_key(setup_seed(Septi)); // RHR4 diff --git a/analysis/rosenpass/protocol.mpv b/analysis/rosenpass/protocol.mpv index 658b05f..bb82055 100644 --- a/analysis/rosenpass/protocol.mpv +++ b/analysis/rosenpass/protocol.mpv @@ -7,7 +7,7 @@ fun InitHello( SessionId, // sidi kem_pk, // epki bits, // sctr - bits, // pidiC + bits, // pidi_ct bits // auth ) : InitHello_t [data]. @@ -17,16 +17,16 @@ fun InitHello( /* not handled here */ /* IHI3 */ \ MIX2(sid2b(sidi), kem_pk2b(epki)) /* IHI4 */ \ ENCAPS_AND_MIX(sctr, spkr, sptr) /* IHI5 */ \ - ENCRYPT_AND_MIX(pidiC, pidi) /* IHI6 */ \ + ENCRYPT_AND_MIX(pidi_ct, pidi) /* IHI6 */ \ MIX2(kem_pk2b(spki), k2b(psk)) /* IHI7 */ \ ENCRYPT_AND_MIX(auth, empty) /* IHI8 */ \ - ih <- InitHello(sidi, epki, sctr, pidiC, auth); + ih <- InitHello(sidi, epki, sctr, pidi_ct, auth); #define INITHELLO_CONSUME() \ ck <- lprf1(CK_INIT, kem_pk2b(spkr)); /* IHR1 */ \ MIX2(sid2b(sidi), kem_pk2b(epki)) /* IHR4 */ \ DECAPS_AND_MIX(sskr, spkr, sctr) /* IHR5 */ \ - DECRYPT_AND_MIX(pid, pidiC) /* IHR6 */ \ + DECRYPT_AND_MIX(pid, pidi_ct) /* IHR6 */ \ LOOKUP_SENDER(pid) /* IHR6 */ \ MIX2(kem_pk2b(spki), k2b(psk)) /* IHR7 */ \ DECRYPT_AND_MIX(DUMMY(empty), auth) @@ -46,17 +46,17 @@ fun RespHello( MIX2(sid2b(sidr), sid2b(sidi)) /* RHR3 */ \ ENCAPS_AND_MIX(ecti, epki, epti) /* RHR4 */ \ ENCAPS_AND_MIX(scti, spki, spti) /* RHR5 */ \ - STORE_BISCUIT(biscuit) /* RHR6 */ \ + STORE_BISCUIT(biscuit_ct) /* RHR6 */ \ ENCRYPT_AND_MIX(auth, empty) /* RHR7 */ \ - rh <- RespHello(sidr, sidi, ecti, scti, biscuit, auth); + rh <- RespHello(sidr, sidi, ecti, scti, biscuit_ct, auth); #define RESPHELLO_CONSUME() \ - let RespHello(sidr, sidi, ecti, scti, biscuit, auth) = rh in \ + let RespHello(sidr, sidi, ecti, scti, biscuit_ct, auth) = rh in \ /* not handled here */ /* RHI2 */ \ MIX2(sid2b(sidr), sid2b(sidi)) /* RHI3 */ \ DECAPS_AND_MIX(eski, epki, ecti) /* RHI4 */ \ DECAPS_AND_MIX(sski, spki, scti) /* RHI5 */ \ - MIX(biscuit) /* RHI6 */ \ + MIX(biscuit_ct) /* RHI6 */ \ DECRYPT_AND_MIX(DUMMY(empty), auth) /* RHI7 */ type InitConf_t. @@ -70,11 +70,11 @@ fun InitConf( #define INITCONF_PRODUCE() \ MIX2(sid2b(sidi), sid2b(sidr)) /* ICI3 */ \ ENCRYPT_AND_MIX(auth, empty) /* ICI4 */ \ - ic <- InitConf(sidi, sidr, biscuit, auth); + ic <- InitConf(sidi, sidr, biscuit_ct, auth); #define INITCONF_CONSUME() \ - let InitConf(sidi, sidr, biscuit, auth) = ic in \ - LOAD_BISCUIT(biscuit_no, biscuit) /* ICR1 */ \ + let InitConf(sidi, sidr, biscuit_ct, auth) = ic in \ + LOAD_BISCUIT(biscuit_no, biscuit_ct)/* ICR1 */ \ ENCRYPT_AND_MIX(rh_auth, empty) /* ICIR */ \ ck_rh <- ck; /* ---- */ /* TODO: Move into oracles.mpv */ \ MIX2(sid2b(sidi), sid2b(sidr)) /* ICR3 */ \ diff --git a/papers/graphics/rosenpass-wp-hashing-tree-rgb.pdf b/papers/graphics/rosenpass-wp-hashing-tree-rgb.pdf deleted file mode 100644 index 4d5708c..0000000 Binary files a/papers/graphics/rosenpass-wp-hashing-tree-rgb.pdf and /dev/null differ diff --git a/papers/graphics/rosenpass-wp-hashing-tree-rgb.svg b/papers/graphics/rosenpass-wp-hashing-tree-rgb.svg deleted file mode 100644 index 7228f23..0000000 --- a/papers/graphics/rosenpass-wp-hashing-tree-rgb.svg +++ /dev/null @@ -1,2341 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - hash function - - - application - - - - - chaining key - - - - - - - - - "string constant" - - - - - - - - - - output - - - - - - - - - - - - - - - - - - - pseudo-random label - - - - - - - - - - - - - - - - input variable - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0 - - - - - - - - - - - RespHello - - - - - - - - - - - state from InitHello - - - - - encaps spki - - - - - encaps epki - - - - - encrypt auth - - - - - - - - sidr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - epki - - - - - - - - - - - - - - - - - epti - - - - - - - - - - - - - - - - - - - - - - - - - - scti - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sidi - - - - - - - - - - - - - - - - - - - - - - - - - - ecti - - - - - - - - - - - - - - - - - - - - - - - - - - spki - - - - - - - - - - - - - - - - - - - - - - - - - - spti - - - - - - - - - - - - - - - - - - - - - - - - - - - - - InitHello - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sidi - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - epki - - - - - - - - - - spkr - - - - - - - - - - spki - - - - - - - - - sctr - - - - - - - - - psk - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sptr - - - - - - - - - - - spkr - - - - - - - - - - PROTOCOL - - - - - - - - - - - - Global Domains - - - - - - - - - - - - - - - - - - "user" - - - - - - - - - - "mix" - - - - - - - - - - "rosenpass.eu" - - - - - - - - - - "wireguard psk" - - - - - - - - - - "key chaining init" - - - - - - - - - - - - mix - - - - - - - - - - - - - - - - "handshake encryption" - - - - - - - - "initiator session encryption" - - - - - - - - "responder session encryption" - - - - - - - - - - - - - - "mac" - - - - - "cookie" - - - - - "peer_id" - - - - - "key chaining extract" - - - - - MAC_WIRE_DATA - - - - - COOKIE_WIRE_DATA - - - spki - - - spkr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - encrypt auth - - - - - - - - - - - - - - - - - - - - - - - encaps spkr - - - - - encrypt ltk - - - - - encrypt auth - - - - - AEAD::enc(pidi) - - - - - store_biscuit() - - - - - AEAD::enc(empty()) - - - - - AEAD::enc(empty()) - - - - - AEAD::enc(empty()) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - data - - - - - pidi - - - - - key - - - - - ck - - - - - key - - - - - key - - - - - key - - - - - pidiC - - - - - biscuit - - - - - auth - - - - - auth - - - - - ct - - - - - - - - - - - InitConf - - - - - - - - - - - - - - - - - state from RespHello - - - - - osk - - - - - ini_enc - - - - - res_enc - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mac - - - - - - - - - - - - - - - - - - - - - cookie - - - - - - - - - - - - - - - - - - - - pidi   pidr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - pidi - - - - - pidi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mix - - - - - - - - - - - - - - - - - - - osk - - - - - osk - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - hs_enc - - - - - - - - - - - - - - - - - - hs_enc - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - hs_enc - - - - - hs_enc - - - - - hs_enc - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ini_enc - - - - - ini_enc - - - - - - - - - - - - - - - - res_enc - - - - - res_enc - - - - - - - - - - sidi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sidr - - - - - - - - - - - - - - - diff --git a/papers/graphics/rosenpass-wp-hashing-tree.afdesign b/papers/graphics/rosenpass-wp-hashing-tree.afdesign index e520ce1..d8482fe 100644 Binary files a/papers/graphics/rosenpass-wp-hashing-tree.afdesign and b/papers/graphics/rosenpass-wp-hashing-tree.afdesign differ diff --git a/papers/graphics/rosenpass-wp-hashing-tree.pdf b/papers/graphics/rosenpass-wp-hashing-tree.pdf index bc1f09a..3a1fa3a 100644 Binary files a/papers/graphics/rosenpass-wp-hashing-tree.pdf and b/papers/graphics/rosenpass-wp-hashing-tree.pdf differ diff --git a/papers/graphics/rosenpass-wp-hashing-tree.png b/papers/graphics/rosenpass-wp-hashing-tree.png index f57bde5..eeed426 100644 Binary files a/papers/graphics/rosenpass-wp-hashing-tree.png and b/papers/graphics/rosenpass-wp-hashing-tree.png differ diff --git a/papers/graphics/rosenpass-wp-hashing-tree.svg b/papers/graphics/rosenpass-wp-hashing-tree.svg index b6dafc5..55180c8 100644 --- a/papers/graphics/rosenpass-wp-hashing-tree.svg +++ b/papers/graphics/rosenpass-wp-hashing-tree.svg @@ -1,17 +1,17 @@ - - + + - + - - + + @@ -25,38 +25,24 @@ - - - - - hash function - + + + - application - - - - - chaining key - - - - - - - + + - "string constant" + "string constant" - - - + + + - - + + - output + output @@ -68,42 +54,42 @@ - - - + + + - + pseudo-random label - + - + - - - + + + - - + + - input variable + input variable - + - + - + - + @@ -115,25 +101,25 @@ - + - + - + - + - + - + - + 0 @@ -240,9 +226,9 @@ - + - epti + ecti @@ -266,9 +252,9 @@ - + - scti + spti @@ -330,9 +316,9 @@ - + - ecti + epti @@ -382,9 +368,9 @@ - + - spti + scti @@ -451,7 +437,7 @@ - + @@ -1190,9 +1176,9 @@ - + - sctr + sptr @@ -1246,9 +1232,9 @@ - + - sptr + sctr @@ -1262,7 +1248,7 @@ spkr - + @@ -1272,43 +1258,45 @@ PROTOCOL - - + + - + - + Global Domains - + - + - + - + - + - + - + - - + + + + + "user" - "user" - + @@ -1318,24 +1306,28 @@ "mix" - + - + - - + + + + + "rosenpass.eu" - "rosenpass.eu" - + - + - - + + + + + "wireguard psk" - "wireguard psk" @@ -1348,7 +1340,7 @@ "chaining key init" - + @@ -1367,104 +1359,104 @@ - + - + "handshake encryption" - - + + - - + + - "initiator session encryption" + "initiator handshake encryption" - - + + - - + + - "responder session encryption" + "responder handshake encryption" - + - + - + - + - + - + - + "mac" - + spkt - + "cookie" - + "biscuit additional data" - + "peer id" - + "chaining key extract" - + MAC_WIRE_DATA - + COOKIE_WIRE_DATA - + spkr - + sidi - + sidr - + spki @@ -1629,9 +1621,9 @@ key - + - pidiC + pidi_ct @@ -1687,14 +1679,14 @@ osk - + - ini_enc + txki - + - res_enc + txkr @@ -1729,14 +1721,11 @@ - + - - - - - + + @@ -1759,10 +1748,10 @@ - - - - + + + + @@ -1843,31 +1832,28 @@ - - - - + + + + - - - - + + + + - + - - - - + - + - + @@ -1969,70 +1955,70 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - - - + + + + - - - - + + + + - - - - + + + + @@ -2053,91 +2039,91 @@ - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - + @@ -2158,7 +2144,7 @@ - + @@ -2179,15 +2165,36 @@ - + + + + + + + + osk + + + + + + + + + + + + + + - + biscuit_ad - + @@ -2198,21 +2205,21 @@ - + - + pidi    pidr - + - + - + @@ -2223,16 +2230,16 @@ - + - + - + - + @@ -2273,15 +2280,15 @@ - + - + mix - + @@ -2289,30 +2296,14 @@ - - - - - - - osk - osk - - - - - - - - @@ -2321,7 +2312,7 @@ - + @@ -2366,7 +2357,7 @@ hs_enc - + @@ -2390,7 +2381,7 @@ - + hs_enc @@ -2427,10 +2418,10 @@ - + - + @@ -2438,20 +2429,20 @@ - - + + - ini_enc + txki - + - ini_enc + txki - + - + @@ -2459,15 +2450,15 @@ - - + + - res_enc + txkr - + - res_enc + txkr @@ -2529,6 +2520,45 @@ + + hash function + + + application + + + chaining + + + key + + + + + + + + + + + + + + + "protocol extention" + + + + + + + + + + + + protocol extention + diff --git a/papers/graphics/rosenpass-wp-key-exchange-protocol-rgb.pdf b/papers/graphics/rosenpass-wp-key-exchange-protocol-rgb.pdf deleted file mode 100644 index 2caa9e4..0000000 Binary files a/papers/graphics/rosenpass-wp-key-exchange-protocol-rgb.pdf and /dev/null differ diff --git a/papers/graphics/rosenpass-wp-key-exchange-protocol-rgb.svg b/papers/graphics/rosenpass-wp-key-exchange-protocol-rgb.svg deleted file mode 100644 index 4e3ed23..0000000 --- a/papers/graphics/rosenpass-wp-key-exchange-protocol-rgb.svg +++ /dev/null @@ -1,191 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - InitHello - - - - - - - - - - - - - - - - - - InitConf - - - - - Biscuit - - - - - - - - - - - - - - - - - - - - - - - - - - - RespHello - - - - - Biscuit - - - - - - - - - - - - - - - EmptyData - - - - - - - - - - - - responder - - - authentication - - - initiator - authentication, - - - forward secrecy - - - acknowledges - - - InitConf - - - OSK handed - - - to WireGuard - - - - - Initiator State - - - - - Responder State - - - - - Initiator - - - - - Responder - - - - - - - - - - - - - - - - - handshake - - - - - live phase - - - - - - - - - - - - - - - - diff --git a/papers/graphics/rosenpass-wp-key-exchange-protocol.afdesign b/papers/graphics/rosenpass-wp-key-exchange-protocol.afdesign new file mode 100644 index 0000000..db70ca8 Binary files /dev/null and b/papers/graphics/rosenpass-wp-key-exchange-protocol.afdesign differ diff --git a/papers/graphics/rosenpass-wp-key-exchange-protocol.pdf b/papers/graphics/rosenpass-wp-key-exchange-protocol.pdf index f087c31..49d0642 100644 Binary files a/papers/graphics/rosenpass-wp-key-exchange-protocol.pdf and b/papers/graphics/rosenpass-wp-key-exchange-protocol.pdf differ diff --git a/papers/graphics/rosenpass-wp-key-exchange-protocol.png b/papers/graphics/rosenpass-wp-key-exchange-protocol.png index 6c5b3af..0c79732 100644 Binary files a/papers/graphics/rosenpass-wp-key-exchange-protocol.png and b/papers/graphics/rosenpass-wp-key-exchange-protocol.png differ diff --git a/papers/graphics/rosenpass-wp-key-exchange-protocol.svg b/papers/graphics/rosenpass-wp-key-exchange-protocol.svg index 3a3d271..1ec21d6 100644 --- a/papers/graphics/rosenpass-wp-key-exchange-protocol.svg +++ b/papers/graphics/rosenpass-wp-key-exchange-protocol.svg @@ -1,15 +1,12 @@ - - + + - + - - - diff --git a/papers/graphics/rosenpass-wp-message-handling-code-rgb.pdf b/papers/graphics/rosenpass-wp-message-handling-code-rgb.pdf deleted file mode 100644 index 43ecdb5..0000000 Binary files a/papers/graphics/rosenpass-wp-message-handling-code-rgb.pdf and /dev/null differ diff --git a/papers/graphics/rosenpass-wp-message-handling-code-rgb.svg b/papers/graphics/rosenpass-wp-message-handling-code-rgb.svg deleted file mode 100644 index 101ff23..0000000 --- a/papers/graphics/rosenpass-wp-message-handling-code-rgb.svg +++ /dev/null @@ -1,1009 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - Responder Code - - - - - Comments - - - - - Initiator Code - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ← - - - Action - - - ← - - - Action - - - ← - - - Action - - - ← - - - Action - - - ← - - - Action - - - ← - - - Action - - - - - Variables - - - - - Variables - - - - - Variables - - - - - Variables - - - - - Variables - - - - - Variables - - - - - Comment - - - - - Comment - - - - - Comment - - - - - Line - - - - - Line - - - - - Line - - - - - Line - - - - - Line - - - - - Line - - - - - ck - - - - - ck - - - ← - - - lhash("chaining key init", spkr) - - - - - sidi - - - ← - - - random_session_id(); - - - - - eski, epki - - - ← - - - EKEM::keygen(); - - - - - mix(sidi, epki); - - - - - sctr - - - - - sctr - - - ← - - - encaps_and_mix<SKEM>(spkr); - - - - - pidiC - - - - - pidiC - - - ← - - - encrypt_and_mix(pidi); - - - - - mix(spki, psk); - - - - - auth - - - ← - - - encrypt_and_mix(empty()) - - - - - ck - - - ← - - - lhash("chaining key init", spkr) - - - - - mix(sidi, epki) - - - - - decaps_and_mix<SKEM>(sskr, spkr, ct1) - - - - - spki, psk - - - ← - - - lookup_peer(decrypt_and_mix(pidi_crypt)) - - - - - mix(spki, psk); - - - - - decrypt_and_mix(auth) - - - - - Initialize the chaining key, for domain separation. - - - - - The session id is used to associate packets with the handshake state. - - - - - Generate new ephemeral keys for forward secrecy. - - - Sidi and epki are included in InitHello, so we mix them into the chaining key to - - - prevent tampering. - - - Key encapsulation using the responder public key. Mixes the public key, shared - - - key and ciphertext into the chaining key and authenticates the responder. - - - - - Tell the responder who the initiator is by transmitting the peer id. - - - Ensure the responder has the correct peer information. Mixing PSK also - - - provides a static, symmetric key exchange with epki & sptr serving as nonces. - - - - - Add a message authentication code ensuring both participants share the state. - - - - - Responder generates a session id. - - - - - Initiator needs to look up their session state using the session id they generated. - - - - - Protect both session ids against tampering. - - - - - Key encapsulation using the ephemeral key; provides forward secrecy. - - - Key encapsulation using the initiator static key; authenticates the initiator - - - (and provides redundant secrecy if kyber where broken). - - - The responder transmits their state to the initiator in an encrypted container - - - to avoid having to store state. - - - - - Authentication code. - - - - - IHI1 - - - - - RHI1 - - - - - ICI1 - - - - - IHR1 - - - - - RHR1 - - - - - ICR1 - - - - - IHI4 - - - - - RHI4 - - - - - ICI4 - - - - - IHR4 - - - - - RHR4 - - - - - ICR4 - - - - - IHI5 - - - - - RHI5 - - - - - ICI5 - - - - - IHR5 - - - - - RHR5 - - - - - ICR5 - - - - - IHI2 - - - - - RHI2 - - - - - ICI2 - - - - - RHR2 - - - - - ICR2 - - - - - IHI6 - - - - - RHI6 - - - - - ICI6 - - - - - IHR6 - - - - - RHR6 - - - - - ICR6 - - - - - IHI3 - - - - - RHI3 - - - - - ICI3 - - - - - RHR3 - - - - - ICR3 - - - - - IHI7 - - - - - RHI7 - - - - - ICI7 - - - - - IHR7 - - - - - RHR7 - - - - - ICR7 - - - - - IHI8 - - - - - IHR8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ← - - - lookup_session(sidi); - - - - - mix(sidr, sidi); - - - - - decaps_and_mix<EKEM>(eski, epki, ecti); - - - - - decaps_and_mix<SKEM>(sski, spki, scti); - - - - - mix(biscuit) - - - - - decrypt_and_mix(auth) - - - ← - - - random_session_id() - - - - - sidr - - - - - mix(sidr, sidi); - - - ← - - - encaps_and_mix<EKEM>(epki); - - - - - ecti - - - ← - - - encaps_and_mix<SKEM>(spki); - - - - - scti - - - ← - - - store_biscuit(); - - - - - biscuit - - - ← - - - encrypt_and_mix(empty()); - - - - - auth - - - - - mix(sidi, sidr); - - - - - auth - - - ← - - - encrypt_and_mix(empty); - - - - - enter_live(); - - - - - biscu it_no - - - ← - - - load_biscuit(biscuit); - - - - - encrypt_and_mix(empty()); - - - - - mix(sidi, sidr); - - - - - decrypt_and_mix(auth); - - - - - assert(biscuit_no > biscuit_used); - - - - - biscuit_used - - - ← - - - biscuit_no; - - - - - enter_live(); - - - - - Responder loads their biscuit. This restores the state from after RHR6. - - - - - Responder recalculates RHR7, since this step was performed after biscuit encoding. - - - - - Protect session ids against tampering. - - - - - - - - - - - - - Authentication code certifies that both participants have the same final chaining key. - - - - - Biscuit replay attack detection. - - - - - Biscuit replay attack detection. - - - - - Generate the transmission keys, classic wireguard key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - InitHello { sidi, epki, sctr, pidiC, auth } - - - - - RespHello { sidr, sidi, ecti, scti, biscuit, auth } - - - - - InitConf { sidi, sidr, biscuit, auth } - - - - - - - - - - - - - - - - - - - - - - - 1 - - - - - 4 - - - - - 5 - - - - - 2 - - - - - 3 - - - - - 6 - - - - diff --git a/papers/graphics/rosenpass-wp-message-handling-code.afdesign b/papers/graphics/rosenpass-wp-message-handling-code.afdesign new file mode 100644 index 0000000..1387262 Binary files /dev/null and b/papers/graphics/rosenpass-wp-message-handling-code.afdesign differ diff --git a/papers/graphics/rosenpass-wp-message-handling-code.pdf b/papers/graphics/rosenpass-wp-message-handling-code.pdf index e9d93fc..3d4e6e7 100644 Binary files a/papers/graphics/rosenpass-wp-message-handling-code.pdf and b/papers/graphics/rosenpass-wp-message-handling-code.pdf differ diff --git a/papers/graphics/rosenpass-wp-message-handling-code.png b/papers/graphics/rosenpass-wp-message-handling-code.png index 82b7f5c..7b4adbf 100644 Binary files a/papers/graphics/rosenpass-wp-message-handling-code.png and b/papers/graphics/rosenpass-wp-message-handling-code.png differ diff --git a/papers/graphics/rosenpass-wp-message-handling-code.svg b/papers/graphics/rosenpass-wp-message-handling-code.svg index b4c8398..79092ad 100644 --- a/papers/graphics/rosenpass-wp-message-handling-code.svg +++ b/papers/graphics/rosenpass-wp-message-handling-code.svg @@ -1,10 +1,10 @@ - - + + - + @@ -70,9 +70,6 @@ - - - @@ -94,6 +91,9 @@ + + + @@ -310,7 +310,7 @@ - pidiC + pidi_ct ← @@ -351,9 +351,9 @@ mix(sidi, epki) - + - decaps_and_mix<SKEM>(sskr, spkr, ct1) + decaps_and_mix<SKEM>(sskr, spkr, sctr) @@ -362,9 +362,9 @@ ← - + - lookup_peer(decrypt_and_mix(pidiC)) + lookup_peer(decrypt_and_mix(pidi_ct)) @@ -720,9 +720,9 @@ decaps_and_mix<SKEM>(sski, spki, scti); - + - mix(biscuit) + mix(biscuit_ct) @@ -774,9 +774,9 @@ store_biscuit(); - + - biscuit + biscuit_ct ← @@ -816,10 +816,10 @@ biscuit_no - ← - + ← + - load_biscuit(biscuit); + load_biscuit(biscuit_ct) @@ -924,32 +924,32 @@ - - - + + + - - - + + + - - - + + + - + - InitHello { sidi, epki, sctr, pidiC, auth } + InitHello { sidi, epki, sctr, pidi_ct, auth } - - + + - RespHello { sidr, sidi, ecti, scti, biscuit, auth } + RespHello { sidr, sidi, ecti, scti, biscuit_ct, auth } - + - InitConf { sidi, sidr, biscuit, auth } + InitConf { sidi, sidr, biscuit_ct, auth } diff --git a/papers/graphics/rosenpass-wp-message-types-rgb.pdf b/papers/graphics/rosenpass-wp-message-types-rgb.pdf deleted file mode 100644 index ea9e7c3..0000000 Binary files a/papers/graphics/rosenpass-wp-message-types-rgb.pdf and /dev/null differ diff --git a/papers/graphics/rosenpass-wp-message-types-rgb.svg b/papers/graphics/rosenpass-wp-message-types-rgb.svg deleted file mode 100644 index 87d0fa8..0000000 --- a/papers/graphics/rosenpass-wp-message-types-rgb.svg +++ /dev/null @@ -1,393 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - type - reserved - payload - mac - - - cookie - - - 1 - 3 - n - 16 - 6 - - - envelope  n + 36 - - - Envelope - - - bytes - - - - - - - - - - - MAC_WIRE_DATA - - - - - COOKIE_WIRE_DATA - - - - - - - - - - - - InitHello - - - type=0x81 - - - sidi - epki - sctr - peerid - auth - - - 4 - 800 - 188 - 32 + 16 = - 48 - 16 - payload  1056 - - - + envelope  1092 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - RespHello - - - type=0x82 - - - sidr - sidi - ecti - scti - biscuit - - - auth - - - 4 - 4 - 768 - 188 - 76 + 24 + 16 = - 116 - 16 - payload  1096 - - - + envelope  1132 - - - - - data - - - - - nonce - - - - - auth code - - - - - - - - - - - - EmptyData - - - type=0x84 - - - sidx - ctr - - - auth - - - 4 - 8 - 16 - payload  28 - - - + envelope  64 - - - - - - - - - - - - CookieReply - - - type=0x86 - - - sidx - nonce - - - cookie - - - 4 - 24 - 16 + 16 = - 32 - payload  60 - - - + envelope  96 - - - - - - - - - - - - - - - - - - - - - - - - - - - - InitConf - - - type=0x83 - - - sidi - sidr - biscuit - - - auth - - - 4 - 4 - 76 + 24 + 16 = - 116 - 16 - payload  140 - - - + envelope  176 - - - - - - - - - - - - Data - - - type=0x85 - - - sidx - ctr - - - data - - - 4 - 8 - variable + - 16 - payload - variable + - 28 - + envelope - variable + - - - 64 - - - - - - - - - - - - - - biscuit - - - 32 - 12 - 32 - biscuit  76 - + nonce  100 - - - + auth code  116 - - - - - - peerid - no - - - ck - - - - diff --git a/papers/graphics/rosenpass-wp-message-types.afdesign b/papers/graphics/rosenpass-wp-message-types.afdesign new file mode 100644 index 0000000..80e85af Binary files /dev/null and b/papers/graphics/rosenpass-wp-message-types.afdesign differ diff --git a/papers/graphics/rosenpass-wp-message-types.pdf b/papers/graphics/rosenpass-wp-message-types.pdf index 3423351..95ca28e 100644 Binary files a/papers/graphics/rosenpass-wp-message-types.pdf and b/papers/graphics/rosenpass-wp-message-types.pdf differ diff --git a/papers/graphics/rosenpass-wp-message-types.png b/papers/graphics/rosenpass-wp-message-types.png index 04fbe27..6e9b730 100644 Binary files a/papers/graphics/rosenpass-wp-message-types.png and b/papers/graphics/rosenpass-wp-message-types.png differ diff --git a/papers/graphics/rosenpass-wp-message-types.svg b/papers/graphics/rosenpass-wp-message-types.svg index 0199599..40dbb75 100644 --- a/papers/graphics/rosenpass-wp-message-types.svg +++ b/papers/graphics/rosenpass-wp-message-types.svg @@ -1,10 +1,10 @@ - - + + - + @@ -72,7 +72,7 @@ 16 - envelope  n + 36 + package  n + 36 Envelope @@ -115,7 +115,7 @@ sidi epki sctr - pidiC + pidi_ct auth @@ -136,14 +136,14 @@ - + - + - + @@ -151,7 +151,7 @@ - + @@ -159,7 +159,7 @@ - + @@ -178,19 +178,17 @@ sidi ecti scti - biscuit - - - auth + auth + biscuit_ct 4 4 768 188 - 76 + 24 + 16 = - 116 - 16 + 16 + 76+24+16 = + 116 payload  1096 @@ -275,7 +273,7 @@ 32 - payload  64 + package  64 @@ -285,13 +283,13 @@ - + - + - + @@ -311,7 +309,7 @@ sidi sidr - biscuit + biscuit_ct auth @@ -319,7 +317,7 @@ 4 4 - 76 + 24 + 16 = + 76+24+16 = 116 16 payload  140 diff --git a/papers/references.bib b/papers/references.bib index 16e788b..16c87d2 100644 --- a/papers/references.bib +++ b/papers/references.bib @@ -179,25 +179,22 @@ @techreport{mceliece, title = {{C}lassic {M}c{E}liece: conservative code-based cryptography}, author = {Martin R. Albrecht and Daniel J. Bernstein and Tung Chou and Carlos Cid and Jan Gilcher and Tanja Lange and Varun Maram and Ingo von Maurich and Rafael Misoczki and Ruben Niederhagen and Kenneth G. Paterson and Edoardo Persichetti and Christiane Peters and Peter Schwabe and Nicolas Sendrier and Jakub Szefer and Cen Jung Tjhai and Martin Tomlinson and Wen Wang}, - year = 2022, + year = 2020, month = 10, - day = 23, - type = {NIST Post-Quantum Cryptography Round 4 Submission}, - url = {https://classic.mceliece.org/} + day = 10, + type = {NIST Post-Quantum Cryptography Round 3 Submission}, + url={https://classic.mceliece.org/nist/mceliece-20201010.pdf}, } @techreport{kyber, - title = {CRYSTALS-Kyber}, - author = {Roberto Avanzi and Joppe Bos and Léo Ducas and Eike Kiltz and Tancrède Lepoint and -Vadim Lyubashevsky and John M. Schanck and Peter Schwabe and Gregor Seiler and Damien Stehlé}, - year = 2020, - month = 10, - day = 1, - type = {NIST Post-Quantum Cryptography Selected Algorithm}, - url = {https://pq-crystals.org/kyber/} + title={CRYSTALS-Kyber algorithm specifications and supporting documentation}, + author={Avanzi, Roberto and Bos, Joppe and Ducas, L{\'e}o and Kiltz, Eike and Lepoint, Tancr{\`e}de and Lyubashevsky, Vadim and Schanck, John M and Schwabe, Peter and Seiler, Gregor and Stehl{\'e}, Damien and others}, + year = 2021, + month = 08, + day = 04, + url = {https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf} } - @misc{SHAKE256, author = "National Institute of Standards and Technology", title = "FIPS PUB 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", @@ -206,3 +203,18 @@ Vadim Lyubashevsky and John M. Schanck and Peter Schwabe and Gregor Seiler and D doi = {10.6028/NIST.FIPS.202} } +@misc{boneh_shoup_graduate, + title = "A graduate course in applied cryptography", + author = "Dan Boneh and Victor Shoup", + url = "https://toc.cryptobook.us/", + year = {2023}, +} + +@inproceedings{hmac, + title={Keying hash functions for message authentication}, + author={Bellare, Mihir and Canetti, Ran and Krawczyk, Hugo}, + booktitle={Annual international cryptology conference}, + pages={1--15}, + year={1996}, + organization={Springer} +} diff --git a/papers/whitepaper.md b/papers/whitepaper.md index 0f81f20..82432b6 100644 --- a/papers/whitepaper.md +++ b/papers/whitepaper.md @@ -21,10 +21,10 @@ abstract: | \enlargethispage{5mm} \setupimage{label=img:KeyExchangeProt,width=.9\linewidth} -![Rosenpass Key Exchange Protocol](graphics/rosenpass-wp-key-exchange-protocol-rgb.svg) +![Rosenpass Key Exchange Protocol](graphics/rosenpass-wp-key-exchange-protocol.svg) \setupimage{label=img:MessageTypes} -![Rosenpass Message Types](graphics/rosenpass-wp-message-types-rgb.svg) +![Rosenpass Message Types](graphics/rosenpass-wp-message-types.svg) \clearpage @@ -68,11 +68,13 @@ All symmetric keys and hash values used in Rosenpass are 32 bytes long. ### Hash {#hash} -A keyed hash function with one 32-byte input, one variable-size input, and one 32-byte output. As keyed hash function we offer two options that can be configured on a peer-basis, with Blake2s being the default: +A keyed hash function with one 32-byte input, one variable-size input, and one 32-byte output. As keyed hash function we offer two options that can be configured on a peer-basis, with Blake2b being the default: -1. the HMAC construction [@rfc_hmac] with BLAKE2s [@rfc_blake2] as the inner hash function. +1. an **incorrect** HMAC construction [@rfc_hmac] with BLAKE2b [@rfc_blake2] as the inner hash function. See Sec. \ref{incorrect-hmac} for details. 2. the SHAKE256 extendable output function (XOF) [@SHAKE256] truncated to a 32-byte output. The result is produced be concatenating the 32-byte input with the variable-size input in this order. +The use of BLAKE2b is being phased out. + ```pseudorust hash(key, data) -> key ``` @@ -98,7 +100,7 @@ XAEAD::dec(key, nonce, ciphertext, additional_data) -> plaintext ### SKEM {#skem} -“Key Encapsulation Mechanism” (KEM) is the name of an interface widely used in post-quantum-secure protocols. KEMs can be seen as asymmetric encryption specifically for symmetric keys. Rosenpass uses two different KEMs. SKEM is the key encapsulation mechanism used with the static keypairs in Rosenpass. The public keys of these keypairs are not transmitted over the wire during the protocol. We use Classic McEliece 460896 [@mceliece] which claims to be as hard to break as 192-bit AES. As one of the oldest post-quantum-secure KEMs, it enjoys wide trust among cryptographers, but it has not been chosen for standardization by NIST. Its ciphertexts and private keys are small (188 bytes and 13568 bytes), and its public keys are large (524160 bytes). This fits our use case: public keys are exchanged out-of-band, and only the small ciphertexts have to be transmitted during the handshake. +“Key Encapsulation Mechanism” (KEM) is the name of an interface widely used in post-quantum-secure protocols. KEMs can be seen as asymmetric encryption specifically for symmetric keys. Rosenpass uses two different KEMs. SKEM is the key encapsulation mechanism used with the static keypairs in Rosenpass. The public keys of these keypairs are not transmitted over the wire during the protocol. We use Classic McEliece 460896\footnote{The exact Classic McEliece version is from the NIST-Competition, Round 3: \par https://classic.mceliece.org/nist/mceliece-20201010.tar.gz}[@mceliece] which claims to be as hard to break as 192-bit AES. As one of the oldest post-quantum-secure KEMs, it enjoys wide trust among cryptographers, but it has not been chosen for standardization by NIST. Its ciphertexts and secret keys are small (188 bytes and 13568 bytes), and its public keys are large (524160 bytes). This fits our use case: public keys are exchanged out-of-band, and only the small ciphertexts have to be transmitted during the handshake. ```pseudorust SKEM::enc(public_key) -> (ciphertext, shared_key) @@ -107,7 +109,7 @@ SKEM::dec(secret_key, ciphertext) -> shared_key ### EKEM -Key encapsulation mechanism used with the ephemeral KEM keypairs in Rosenpass. The public keys of these keypairs need to be transmitted over the wire during the protocol. We use Kyber-512 [@kyber], which has been selected in the NIST post-quantum cryptography competition and claims to be as hard to break as 128-bit AES. Its ciphertexts, public keys, and private keys are 768, 800, and 1632 bytes long, respectively, providing a good balance for our use case as both a public key and a ciphertext have to be transmitted during the handshake. +Key encapsulation mechanism used with the ephemeral KEM keypairs in Rosenpass. The public keys of these keypairs need to be transmitted over the wire during the protocol. We use Kyber-512\footnote{The exact Kyber version is from the NIST-Competition, Round 3: \par https://pq-crystals.org/kyber/data/kyber-submission-nist-round3.zip \par https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf}[@kyber], which has been selected in the NIST post-quantum cryptography competition and claims to be as hard to break as 128-bit AES. Its ciphertexts, public keys, and secret keys are 768, 800, and 1632 bytes long, respectively, providing a good balance for our use case as both a public key and a ciphertext have to be transmitted during the handshake. ```pseudorust EKEM::enc(public_key) -> (ciphertext, shared_key) @@ -118,7 +120,46 @@ Using a combination of two KEMs – Classic McEliece for static keys and Kyber f Rosenpass uses libsodium [@libsodium] as cryptographic backend for hash, AEAD, and XAEAD, and liboqs [@liboqs] for the post-quantum-secure KEMs. -## Variables {#variables} +## Protocol Roles {#roles} + +The protocol specifies two roles: initiator and responder. + +* initiator – The party that starts a handshake. +* responder – The party that does not start a handshake. + +All Rosenpass instances operate in either mode; the traditional "client"/"server" distinction does not apply to the Rosenpass protocol. We sometimes use the term "server". In these cases, we generally refer to the "Rosenpass Server," as in the application that implements the Rosenpass protocol, not to a server/client distinction. + +The initiator is stateful, and directs the handshake process. The responder is stateless for most of the protocol and reacts to the initiator's messages; this is important to protect our protocol against state disruption (protocol level denial of service) attacks. Since the responder does require some state to complete the protocol, this state is moved into an encrypted cookie, called "biscuit". + +The number of concurrent responder-role handshakes with another client is unlimited to account for the possibility of an imposter trying to execute a handshake: before completion of said handshake, there is no way to figure out which peer is an imposter and which peer is a legitimate party; any attempt to do so might lead to a state-disruption attack -- denial of service on the protocol level. + +There is no particular mechanism to negotiate which party acts as initiator and which acts as responder. At startup and when a key exchange is timer-triggered, Rosenpass will *initiate* a key exchange in initiator mode. At startup of another peer, and when they start a timer-triggered key exchange, the local server will *respond* in responder mode. + +Implementations must account for one ongoing initiator-role key exchange and many ongoing responder-role key exchanges. Upon receiving a well-formed InitConf package and successfully completing a responder-role key exchange, implementations should abort any ongoing initiator-role key exchange. Implementations should also use different back-off periods depending on whether the handshake was completed in initiator role or in responder role. The following values are used in the Rust reference implementation: + +- Initiator rekey interval: 130s +- Responder rekey interval: 120s + +In practice these delays cause participants to take turns acting as initiator and acting as responder, since the ten-second difference is usually enough for the handshake with switched roles to complete before the old initiator's rekey timer goes to zero. + +## Packages {#packages} + +The packages, their contents, and their type IDs are graphically represented in Fig. \ref{img:MessageTypes}. Their purposes are: + +* \textbf{Envelope} – This is not a package on its own; it is the envelope all the other packages are put into. +* \textbf{InitHello} – First package of the handshake, from initiator to responder. +* \textbf{RespHello} – Second package of the handshake, from responder to initiator. +* \textbf{InitConf} – Third package of the handshake, from initiator to responder. +* \textbf{EmptyData} – Empty payload package. Used as acknowledgment to abort data retransmission (see Secs. \ref{payload-keys}, \ref{packet-loss}, and function `enter_live()` in Sec. \ref{fn:enter_live}). +* \textbf{Data} – Transmission of actual payload data is not used in Rosenpass, but the package is still specified since it is part of WireGuard (see Sec. \ref{payload-keys} and function `enter_live()` in Sec. \ref{fn:enter_live}). +* \textbf{CookieReply} – Used for proof-of-IP-ownership-based denial-of-service mitigation (see Sec. \ref{dos-mitigation}). +* \textbf{biscuit} – This is not a stand-alone package; instead, it is an encrypted fragment present in \textbf{RespHello} and \textbf{InitConf}. + +## Endianness {#endianess} + +Unless otherwise specified, all integer values in the Rosenpass protocol use little-endian encoding. + +## Variables and Domain Separators {#variables} ### KEM Keypairs and Ciphertexts @@ -138,10 +179,10 @@ Rosenpass uses multiple keypairs, ciphertexts, and plaintexts for key encapsulat These values use a naming scheme consisting of four lower-case characters. The first character indicates whether the key is static `s` or ephemeral `e`. The second character is an `s` or a `p` for secret or public. The third character is always a `k`. The fourth and final character is an `i`, `r`, `m`, or `t`, for `initiator`, `responder`, `mine`, or `theirs`. The initiator's static public key for instance is `spki`. During execution of the protocol, three KEM ciphertexts are produced: `scti`, `sctr`, and `ecti`. -Besides the initiator and responder roles, we define the roles `mine` and `theirs` (`m`/`t`). These are sometimes used in the code when the assignment to initiator or responder roles is flexible. As an example, “this server's” static secret key is `sskm`, and the peer's public key is `spkt`. +Besides the initiator and responder roles, we define the roles `mine` and `theirs` (`m`/`t`). These are sometimes used in the code when the assignment to initiator or responder roles is flexible. As an example, our static secret key is `sskm`, and the peer's public key is `spkt`. -### IDs +### IDs {#peer-ids} Rosenpass uses two types of ID variables. See Figure \ref{img:HashingTree} for how the IDs are calculated. @@ -168,33 +209,103 @@ We mix all key material (e.g. `psk`) into the chaining key and derive symmetric The protocol allows for multiple `osk`s to be generated; each of these keys is labeled with a domain separator to make sure different key usages are always given separate keys. The domain separator for using Rosenpass and WireGuard together is a token generated using the domain separator sequence `["rosenpass.eu", "wireguard psk"]` (see Fig. \ref{img:HashingTree}), as described in \ref{protocol-extension-wireguard-psk}. Third-parties using Rosenpass-keys for other purposes are asked to define their own protocol-extensions. Standard protocol extensions are described in \ref{protocol-extensions}. +#### Symmetric Keys and Nonces for payload data transmission {#payload-keys} + +Keys generated by the Rosenpass key exchange could be used for encryption of payload data if post-quantum security but not hybrid post-quantum security is a goal. Despite this, we do not generally offer payload transmission in the protocol. Instead, the Rosenpass protocol focuses on providing a key exchange, letting external applications handle data transmission. When used with WireGuard, the default use case, this integration also ensures hybrid security. + +Still we specify the `Data` and `EmptyData` packets. `Data` is not used, but we still specify it as the same packet is also present in WireGuard. `EmptyData` is used for packet retransmission (see Sec. \ref{packet-loss}). + +We also specify how symmetric keys are generated for payload encryption. See Sec. {#live-session-state} and the function `enter_live()` (Sec. \ref{fn:enter_live}). + +Keys and nonces for this purpose use the following naming scheme: + +\begin{namepartpicture} +\namepart{tx=Transmission,rx=Reception} +\namepart[3.5cm]{k=Key,n=Nonce} +\namepart[7cm]{i=Initiator,r=Responder,m=Mine,t=Theirs} +\begin{scope}[decoration={brace,amplitude=5mm},thick] +\namebraceright{tx}{rx} +\namebraceleft{k}{n} +\namebraceright{k}{n} +\namebraceleft{i}{t} +\end{scope} +\end{namepartpicture} + +Note that this scheme is deliberately redundant. For instance, when we are the initiator, then `txki = rxki = txkm = rxkt`. I.e. the initiator's transmission key is the responder's reception key. Since we are the initiator, the initiator's transmission key is also the transmission key of `mine` and the reception key of `theirs`. + +There also is a -- now deprecated -- naming scheme: + +\begin{namepartpicture} +\namepart{ini=Initiator,res=Responder,hs=Handshake} +\SingleNamePart[3.5cm]{enc}{\textunderscore{}enc}{Encryption} +\begin{scope}[decoration={brace,amplitude=5mm},thick] +\namebraceright{ini}{hs} +\namebraceleft{enc}{enc} +\end{scope} +\end{namepartpicture} + +`ini_enc = txki = rxkr` and `res_enc = txkr = rxki`, but this usage is deprecated. The third name `hs_enc` is for encryption as part of the key exchange itself; this name is still in use. + +### Labels + +Fig. \ref{img:HashingTree} specifies multiple domain separators for various uses. + +* `PROTOCOL` (`[0, PROTOCOL]`) – The global domain separator; used to generate more domain separators. + +Immediately below the global domain separator, you can find: + +* `"mac"` – Network package integrity verification and pre-authentication with `spkt`. See Sec. \ref{envelope-mac-field}. +* `"cookie"` – Denial of Service mitigation through proof-of-ip ownership. See Sec. \ref{dos-mitigation}. +* `"peer id"` – Generation of peer ids. See Sec. \ref{peer-ids}. +* `"biscuit additional data"` – Storing the protocol state in encrypted cookies so the responder is stateless. See Sec. \ref{hs-state-and-biscuits}. +* `"chaining key init"` – Starting point for the execution of the actual rosenpass protocol. +* `"chaining key extract"` – Key derivation from the current protocol state, the chaining key. See Sec. \ref{symmetric-keys}. + +Below `"chaining key extract"`, there are multiple labels, generating domain separators for deriving keys for various purposes during the execution of the protocol. + +It is important to understand that there are two phases for these labels, e.g. applying the `"mix"` label produces a random fixed-size hash value we call `mix`. Not the label `"mix"` but the resulting hash value is used to derive keys during protocol execution. This allows us to use very complicated label structures for key derivation without losing efficiency. + +The different labels are: + +* `"mix"` – Mixing further values into the chaining key; i.e. into the protocol state. +* `"user"` – Labels for external uses; these are what generate the `osk` (output shared key). See Sec. \ref{symmetric-keys}. +* `"handshake encryption"` – Used when encrypting data using a shared key as part of the protocol execution; e.g. used to generate the `auth` (authentication tag) fields in protocol packages. +* `"initiator handshake encryption"` and `"responder handshake encryption"` – For transmission of data after the key-exchange finishes. See Sec. \ref{symmetric-keys}. ## Hashes Rosenpass uses a cryptographic hash function for multiple purposes: * Computing the message authentication code in the message envelope as in WireGuard -* Computing the cookie to guard against denial of service attacks. This is a feature adopted from WireGuard, but not yet included in the implementation of Rosenpass. +* Computing the cookie to guard against denial of service attacks. * Computing the peer ID * Key derivation during and after the handshake * Computing the additional data for the biscuit encryption, to provide some privacy for its contents -Recall from Section \ref{hash} that rosenpass supports using either BLAKE2s or SHAKE256 as hash function, which can be configured for each peer ID. However, as noted above, rosenpass uses a hash function to compute the peer ID and thus also to access the configuration for a peer ID. This is an issue when receiving an `InitHello`-message, because the correct hash function is not known when a responder receives this message and at the same the responders needs it in order to compute the peer ID and by that also identfy the hash function for that peer. The reference implementation resolves this issue by first trying to derive the peer ID using SHAKE256. If that does not work (i.e. leads to an AEAD decryption error), the reference implementation tries again with BLAKE2s. The reference implementation verifies that the hash function matches the one confgured for the peer. Similarly, if the correct peer ID is not cached when receiving an InitConf message, the reference implementation proceeds in the same manner. +Recall from Section \ref{hash} that rosenpass supports using either BLAKE2b or SHAKE256 as hash function, which can be configured for each peer ID. However, as noted above, rosenpass uses a hash function to compute the peer ID and thus also to access the configuration for a peer ID. This is an issue when receiving an `InitHello`-message, because the correct hash function is not known when a responder receives this message and at the same the responders needs it in order to compute the peer ID and by that also identfy the hash function for that peer. The reference implementation resolves this issue by first trying to derive the peer ID using SHAKE256. If that does not work (i.e. leads to an AEAD decryption error), the reference implementation tries again with BLAKE2b. The reference implementation verifies that the hash function matches the one confgured for the peer. Similarly, if the correct peer ID is not cached when receiving an InitConf message, the reference implementation proceeds in the same manner. Using one hash function for multiple purposes can cause real-world security issues and even key recovery attacks [@oraclecloning]. We choose a tree-based domain separation scheme based on a keyed hash function – the previously introduced primitive `hash` – to make sure all our hash function calls can be seen as distinct. \setupimage{landscape,fullpage,label=img:HashingTree} -![Rosenpass Hashing Tree](graphics/rosenpass-wp-hashing-tree-rgb.svg) +![Rosenpass Hashing Tree](graphics/rosenpass-wp-hashing-tree.svg) Each tree node $\circ{}$ in Figure \ref{img:HashingTree} represents the application of the keyed hash function, using the previous chaining key value as first parameter. The root of the tree is the zero key. In level one, the `PROTOCOL` identifier is applied to the zero key to generate a label unique across cryptographic protocols (unless the same label is deliberately used elsewhere). In level two, purpose identifiers are applied to the protocol label to generate labels to use with each separate hash function application within the Rosenpass protocol. The following layers contain the inputs used in each separate usage of the hash function: Beneath the identifiers `"mac"`, `"cookie"`, `"peer id"`, and `"biscuit additional data"` are hash functions or message authentication codes with a small number of inputs. The second, third, and fourth column in Figure \ref{img:HashingTree} cover the long sequential branch beneath the identifier `"chaining key init"` representing the entire protocol execution, one column for each message processed during the handshake. The leaves beneath `"chaining key extract"` in the left column represent pseudo-random labels for use when extracting values from the chaining key during the protocol execution. These values such as `mix >` appear as outputs in the left column, and then as inputs `< mix` in the other three columns. -The protocol identifier depends on the hash function used with the respective peer is defined as follows if BLAKE2s [@rfc_blake2] is used: +The protocol identifier depends on the hash function used with the respective peer is defined as follows if BLAKE2b [@rfc_blake2] is used: ```pseudorust -PROTOCOL = "rosenpass 1 rosenpass.eu aead=chachapoly1305 hash=blake2s ekem=kyber512 skem=mceliece460896 xaead=xchachapoly1305" +PROTOCOL = "Rosenpass v1 mceliece460896 Kyber512 ChaChaPoly1305 BLAKE2s" +``` +Note that the domain separator used here maintains that BLAKE2s is used, while in +reality, we use BLAKE2b. The reason for this is an implementation error. Since fixing this would have led to a breaking change in the Rosenpass reference implementation, and all other known implementations of Rosenpass simply reproduced this error, we chose to harmonize the white paper with the implementation instead of fixing the implementation. + +If SHAKE256 [@SHAKE256] is used, then `BLAKE2s` is substituted with `SHAKE256`: + +```pseudorust +PROTOCOL = "Rosenpass v1 mceliece460896 Kyber512 ChaChaPoly1305 SHAKE256" ``` -If SHAKE256 [@SHAKE256] is used, `blake2s` is replaced by `shake256` in `PROTOCOL`. Since every tree node represents a sequence of `hash` calls, the node beneath `"handshake encryption"` called `hs_enc` can be written as follows: +Since every tree node represents a sequence of `hash` calls, the node beneath `"handshake encryption"` called `hs_enc` can be written as follows: ```pseudorust hs_enc = hash(hash(hash(0, PROTOCOL), "chaining key extract"), "handshake encryption") @@ -218,7 +329,7 @@ hs_enc = hash(hash(hash(0, PROTOCOL), "chaining key extract"), "handshake encryp = lhash("chaining key extract", "handshake encryption") ``` -## Server State +## Rosenpass Server State ### Global @@ -242,9 +353,9 @@ For each peer, the server stores: * `psk` – The pre-shared key used with the peer * `spkt` – The peer's public key * `biscuit_used` – The `biscuit_no` from the last biscuit accepted for the peer as part of InitConf processing -* `hash_function` – The hash function, SHAKE256 or BLAKE2s, used with the peer. +* `hash_function` – The hash function, SHAKE256 or BLAKE2b, used with the peer. -### Handshake State and Biscuits +### Handshake State and Biscuits {#hs-state-and-biscuits} The initiator stores the following local state for each ongoing handshake: @@ -265,9 +376,13 @@ The responder stores no state. While the responder has access to all of the abov The biscuit is encrypted with the `XAEAD` primitive and a randomly chosen nonce. The values `sidi` and `sidr` are transmitted publicly as part of InitConf, so they do not need to be present in the biscuit, but they are added to the biscuit's additional data to make sure the correct values are transmitted as part of InitConf. -The `biscuit_key` used to encrypt biscuits should be rotated every two minutes. Implementations should keep two biscuit keys in memory at any given time to avoid having to drop packages when `biscuit_key` is rotated. +The `biscuit_key` used to encrypt biscuits should be rotated frequently. Implementations should keep two biscuit keys in memory at any given time to avoid having to drop packages when `biscuit_key` is rotated. The Rosenpass reference implementation retires biscuits after five minutes and erases them after ten. -### Live Session State +### Live Session State {#live-session-state} + +These variables are used after the handshake terminates for encryption of the \textbf{Data} and \textbf{EmptyData} packages. +\textbf{EmptyData} is used as an acknowledgement package to terminate package retransmission (see Sec. \ref{packet-loss}). +\textbf{Data} would be used for transmission of actual payload, but this feature is currently not specified for Rosenpass. Despite this, we do specify the however as it is also part of WireGuard. * `ck` – The chaining key * `sidm` – Our session ID (“mine”) @@ -277,6 +392,13 @@ The `biscuit_key` used to encrypt biscuits should be rotated every two minutes. * `txkt` – Peer's transmission key * `txnt` – Peer's transmission nonce +## Protocol Code {#functions} + +The main reference for how messages are processed in the Rosenpass protocol can be found in Fig. \ref{img:HandlingCode}. The figure uses Rust-like pseudo code. + +\setupimage{landscape,fullpage,label=img:HandlingCode} +![Rosenpass Message Handling Code](graphics/rosenpass-wp-message-handling-code.svg) + ## Helper Functions {#functions} Given the peer ID, look up the peer and load the peer's variables. @@ -347,13 +469,13 @@ Rosenpass is built with KEMs, not with NIKEs (Diffie-Hellman-style operations); ```pseudorust fn encaps_and_mix(pk) { let (ct, shk) = T::enc(pk); - mix(pk, ct, shk); + mix(pk, shk, ct); ct } fn decaps_and_mix(sk, pk, ct) { let shk = T::dec(sk, ct); - mix(pk, ct, shk); + mix(pk, shk, ct); } ``` @@ -375,40 +497,40 @@ fn store_biscuit() { "biscuit additional data", spkr, sidi, sidr); let ct = XAEAD::enc(k, n, pt, ad); - let nct = concat(n, ct); + let biscuit_ct = concat(n, ct); - mix(nct) - nct + mix(biscuit_ct) + biscuit_ct } ``` -Note that the `mix(nct)` call updates the chaining key, but that update does not make it into the biscuit. Therefore, `mix(nct)` is reapplied in `load_biscuit`. The responder handshake code also needs to reapply any other operations modifying `ck` after calling `store_biscuit`. The handshake code on the initiator's side also needs to call `mix(nct)`. +Note that the `mix(biscuit_ct)` call updates the chaining key, but that update does not make it into the biscuit. Therefore, `mix(biscuit_ct)` is reapplied in `load_biscuit`. The responder handshake code also needs to reapply any other operations modifying `ck` after calling `store_biscuit`. The handshake code on the initiator's side also needs to call `mix(biscuit_ct)`. ```pseudorust -fn load_biscuit(nct) { +fn load_biscuit(biscuit_ct) { // Decrypt the biscuit let k = biscuit_key; - let (n, ct) = nct; + let concat(n, ct) = biscuit_ct; let ad = lhash( "biscuit additional data", spkr, sidi, sidr); let pt : Biscuit = XAEAD::dec(k, n, ct, ad); // Find the peer and apply retransmission protection - lookup_peer(pt.peerid); + lookup_peer(pt.pidi); - // In December 2024, the InitConf retransmission mechanisim was redesigned + // In December 2024, the InitConf retransmission mechanism was redesigned // in a backwards-compatible way. See the changelog. // // -- 2024-11-30, Karolin Varner if (protocol_version!(< "0.3.0")) { // Ensure that the biscuit is used only once - assert(pt.biscuit_no <= peer.biscuit_used); + assert(pt.biscuit_no >= peer.biscuit_used); } // Restore the chaining key ck ← pt.ck; - mix(nct); + mix(biscuit_ct); // Expose the biscuit no, // so the handshake code can differentiate @@ -417,6 +539,8 @@ fn load_biscuit(nct) { } ``` +\phantomsection\label{fn:enter_live} + Entering the live session is very simple in Rosenpass – we just use `extract_key` with dedicated identifiers to derive initiator and responder keys. ```pseudorust @@ -462,13 +586,15 @@ The responder code handling InitConf needs to deal with the biscuits and package ICR5 and ICR6 perform biscuit replay protection using the biscuit number. This is not handled in `load_biscuit()` itself because there is the case that `biscuit_no = biscuit_used` which needs to be dealt with for retransmission handling. -### Denial of Service Mitigation and Cookies +### Denial of Service Mitigation and Cookies {#dos-mitigation} -Rosenpass derives its cookie-based DoS mitigation technique for a responder when receiving InitHello messages from Wireguard [@wg]. +Rosenpass derives its cookie-based DoS mitigation technique for a responder when receiving InitHello messages from WireGuard [@wg]. + +**This is currently implemented in the Rosenpass implementation but still considered an experimental feature and not enabled by default.** When the responder is under load, it may choose to not process further InitHello handshake messages, but instead to respond with a cookie reply message (see Figure \ref{img:MessageTypes}). -The sender of the exchange then uses this cookie in order to resend the message and have it accepted the following time by the reciever. +The sender of the exchange then uses this cookie in order to resend the message and have it accepted the following time by the receiver. For an initiator, Rosenpass ignores all messages when under load. @@ -483,9 +609,9 @@ cookie_encrypted = XAEAD(lhash("cookie-key", spkm), nonce, cookie_value, mac_pee where `cookie_secret` is a secret variable that changes every two minutes to a random value. Moreover, `lhash` is always instantiated with SHAKE256 when computing `cookie_value` for compatability reasons. `initiator_host_info` is used to identify the initiator host, and is implementation-specific for the client. This paramaters used to identify the host must be carefully chosen to ensure there is a unique mapping, especially when using IPv4 and IPv6 addresses to identify the host (such as taking care of IPv6 link-local addresses). `cookie_value` is a truncated 16 byte value from the above hash operation. `mac_peer` is the `mac` field of the peer's handshake message to which message is the reply. -#### Envelope `mac` Field +#### Envelope `mac` Field {#envelope-mac-field} -Similar to `mac.1` in Wireguard handshake messages, the `mac` field of a Rosenpass envelope from a handshake packet sender's point of view consists of the following: +Similar to `mac.1` in WireGuard handshake messages, the `mac` field of a Rosenpass envelope from a handshake packet sender's point of view consists of the following: ```pseudorust mac = lhash("mac", spkt, MAC_WIRE_DATA)[0..16] @@ -508,7 +634,7 @@ else { } ``` -Here, `seconds_since_update(peer.cookie_value)` is the amount of time in seconds ellapsed since last cookie was received, and `COOKIE_WIRE_DATA` are the message contents of all bytes of the retransmitted message prior to the `cookie` field. +Here, `seconds_since_update(peer.cookie_value)` is the amount of time in seconds elapsed since last cookie was received, and `COOKIE_WIRE_DATA` are the message contents of all bytes of the retransmitted message prior to the `cookie` field. The inititator can use an invalid value for the `cookie` value, when the responder is not under load, and the responder must ignore this value. However, when the responder is under load, it may reject InitHello messages with the invalid `cookie` value, and issue a cookie reply message. @@ -517,18 +643,18 @@ However, when the responder is under load, it may reject InitHello messages with This whitepaper does not mandate any specific mechanism to detect responder contention (also mentioned as the under load condition) that would trigger use of the cookie mechanism. -For the reference implemenation, Rosenpass has derived inspiration from the Linux implementation of Wireguard. This implementation suggests that the reciever keep track of the number of messages it is processing at a given time. +For the reference implemenation, Rosenpass has derived inspiration from the Linux implementation of WireGuard. This implementation suggests that the receiver keep track of the number of messages it is processing at a given time. -On receiving an incoming message, if the length of the message queue to be processed exceeds a threshold `MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD`, the client is considered under load and its state is stored as under load. In addition, the timestamp of this instant when the client was last under load is stored. When recieving subsequent messages, if the client is still in an under load state, the client will check if the time ellpased since the client was last under load has exceeded `LAST_UNDER_LOAD_WINDOW` seconds. If this is the case, the client will update its state to normal operation, and process the message in a normal fashion. +On receiving an incoming message, if the length of the message queue to be processed exceeds a threshold `MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD`, the client is considered under load and its state is stored as under load. In addition, the timestamp of this instant when the client was last under load is stored. When recieving subsequent messages, if the client is still in an under load state, the client will check if the time elapsed since the client was last under load has exceeded `LAST_UNDER_LOAD_WINDOW` seconds. If this is the case, the client will update its state to normal operation, and process the message in a normal fashion. -Currently, the following constants are derived from the Linux kernel implementation of Wireguard: +Currently, the following constants are derived from the Linux kernel implementation of WireGuard: ```pseudorust MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD = 4096 LAST_UNDER_LOAD_WINDOW = 1 //seconds ``` -## Dealing with Packet Loss +## Dealing with Packet Loss {#packet-loss} The initiator deals with packet loss by storing the messages it sends to the responder and retransmitting them in randomized, exponentially increasing intervals until they get a response. Receiving RespHello terminates retransmission of InitHello. A Data or EmptyData message serves as acknowledgement of receiving InitConf and terminates its retransmission. @@ -544,6 +670,40 @@ When a responder is under load and it receives an InitHello handshake message, t When the responder is under load and it recieves an InitConf message, the message will be directly processed without checking the validity of the cookie field. +## Timers + +The Rosenpass protocol uses various timer-triggered events during its operation. This section provides a listing of the timers used and gives the values used in the reference implementation. Other implementations may choose different values. + +### Rekeying + +Period after which the previous responder starts a new handshake in initiator role; period after which the previous initiator starts a new handshake in initiator role again; period after which a peer rejects an existing shared key. + +```pseudorust +REKEY_AFTER_TIME_RESPONDER = 120s +REKEY_AFTER_TIME_INITIATOR = 130s +REJECT_AFTER_TIME = 180s +``` + +### Biscuits + +Period after which the biscuit key is rotated. + +```pseudorust +BISCUIT_EPOCH = 300s +``` + +### Retransmission + +Delay after which all retransmission attempts are aborted; exponential backoff factor for retransmission delay; initial (minimum) retransmission delay; final (maximum) retransmission delay; retransmission jitter/variance factor. + +```pseudorust +RETRANSMIT_ABORT = 120s +RETRANSMIT_DELAY_GROWTH = 2 +RETRANSMIT_DELAY_BEGIN = 500ms +RETRANSMIT_DELAY_END = 10s +RETRANSMIT_DELAY_JITTER = 0.5 +``` + # Protocol extensions {#protocol-extensions} The main extension point for the Rosenpass protocol is to generate `osk`s (speak output shared keys, see Sec. \ref{symmetric-keys}) for purposes other than using them to secure WireGuard. By default, the Rosenpass application generates keys for the WireGuard PSK (see \ref{protocol-extension-wireguard-psk}). It would not be impossible to use the keys generated for WireGuard in other use cases, but this might lead to attacks[@oraclecloning]. Specifying a custom protocol extension in practice just means settling on alternative domain separators (see Sec. \ref{symmetric-keys}, Fig. \ref{img:HashingTree}). @@ -651,13 +811,255 @@ fn on_key_timeout() { } ``` +\begin{minipage}{\textwidth} \setupimage{label=img:ExtWireguardPSKHybridSecurity,fullpage} ![Rosenpass + WireGuard: Hybrid Security](graphics/rosenpass-wireguard-hybrid-security.pdf) +\end{minipage} + +# Errata {#errata} + +## Incorrect HMAC, Hash Function Choice {#incorrect-hmac} + +Initially, we chose to use `HMAC+BLAKE2s` for our message authentication code, mostly as a form of cargo cult. WireGuard used BLAKE2s, so we should use it too. BLAKE2 supports a directly keyed mode, so there is not much reason to prefer rolling your own using HMAC from a security standpoint. + +It seems likely that WireGuard used HMAC as a heuristic security measure. Message authentication codes, keyed hash functions, had long been constructed by combining HMAC with a hash function; why change that? And there actually is a good reason to use HMAC: Merkle-Damgard constructions have long been the norm for hash functions; their usage was even standardized as MD5 or SHA-2. But Merkle-Damgard constructions are susceptible to extension attacks, where you can calculate `H(message || suffix)` assuming `H(message)` is known to you. HMAC fixes this issue[@boneh_shoup_graduate][@hmac]. + + +But SHA-3 (or SHAKE) and BLAKE2 depart from this long-standing status quo: these hash functions are not based on Merkle-Damgard and they are deliberately designed so they are not susceptible to length extension attacks. On top of this, both schemes provide a keyed mode as a feature of the hash function. At this point it makes much more sense to require a keyed hash function, satisfying the PRF ("pseudo random function") security property and the PRF-SWAP security property[@pqwg] instead of building our own keyed hash from a hash function. HMAC can still be used; if someone wanted to operate Rosenpass with SHA2, the best way to do it would be using `HMAC-SHA512` as the underlying keyed hash. We just also allow using `SHAKE256` without an extra application of HMAC. + +Unfortunately, there were a couple of errors in the implementation: we should have used BLAKE2s like WireGuard; instead, we used BLAKE2b. We should have implemented HMAC properly, but we failed to do so. For a fixed-length, 32 byte key and a 32 byte block size, the HMAC function is specified as: + +```pseudorust +type Key = [u8; 32]; +type HashFunction = Fn(&[u8]) -> Key; + +const INNER_PAD: [u8; KEY_LEN] = [0x36u8; KEY_LEN]; +const OUTER_PAD: [u8; KEY_LEN] = [0x5Cu8; KEY_LEN]; + +fn hmac(h: Hash, key: Key, data: &[u8]) -> Key { + // `^` denotes XOR, `||` denotes concatenation + + let inner_key = key ^ INNER_PAD; + let outer_key = key ^ OUTER_PAD; + + let inner_hash = h(inner_key || data); + let outer_hash = h(outer_key || inner_hash); + + return outer_hash; +} +``` + +Instead of implementing this function, we somehow lost track of the fact that HMAC uses concatenation to combine the keys with its data, and instead we built a construction around BLAKE2b in keyed hash mode. That is, we replaced the concatenation with calls to the keyed version of our hash: + +```pseudorust +type Key = [u8; 32]; +type KeyedHashFunction = Fn(Key, &[u8]) -> Key; + +const INNER_PAD: [u8; KEY_LEN] = [0x36u8; KEY_LEN]; +const OUTER_PAD: [u8; KEY_LEN] = [0x5Cu8; KEY_LEN]; + +fn incorrect_rosenpass_hmac(kh: KeyedHashFunction, key: Key, data: &[u8]) -> Key { + // `^` denotes XOR, `||` denotes concatenation + + let inner_key = key ^ INNER_PAD; + let outer_key = key ^ OUTER_PAD; + + let inner_hash = kh(inner_key, data); + let outer_hash = kh(outer_key, inner_hash); + + return outer_hash; +} +``` + +We therefore add this section explaining our incorrect HMAC usage to harmonize the white paper with the implementation. +To ensure compatibility with the existing versions of Rosenpass, you have to replicate this incorrect variant of HMAC. + +Neither mistake is assumed to cause security issues. BLAKE2b is a secure hash function. +There is no reason to assume that our incorrect variant of HMAC-BLAKE2b would be insecure; it is, however, non-standard and needlessly complicates the protocol. We are therefore phasing out usage of HMAC-BLAKE2b in favor of us using SHAKE256 as our keyed hash of choice. # Changelog ### 0.3.x +#### 2025-08-10 – Applying fixes from Steffen Vogel proof reading of the whitepaper + +\vspace{0.5em} + +Author: Karolin varner + +Issue: [#68](https://github.com/rosenpass/rosenpass/issues/68) + +PR: [#664](https://github.com/rosenpass/rosenpass/) + +\vspace{0.5em} + +Early in the project lifetime, Steffen Vogel successfully implemented a [port of the Rosenpass protocol in [go](https://github.com/cunicu/go-rosenpass). +This implementation has not received an in-depth review from a cryptography implementation perspective, which is why we (the Rosenpass project) are not yet recommending this implementation for production usage; +still, creating this implementation was a great achievement. + +During the process, Steffen discovered a large number of possible improvements for the whitepaper. With this update, we are addressing those issues. + +This process also ensures that the world knows, that I have ADHD and makes me fix all the little mistakes I could not spot even on the seventh review of the whitepaper. + +Changes, in particular: + +1. Added a comprehensive reference about labels used in the protocol +2. Added a comprehensive reference about symmetric keys and nonces used for encryption/decryption (`txki`, `txni`, `ini_enc`, `hs_enc`, …) +3. Added a comprehensive reference about packages used. +4. Added an explaining paragraph to section "Live Session State". +5. Added a section about protocol roles. +6. Brief section about endianness. +7. In Fig. 5: Rosenpass Message Handling Code; in IHR5 we replace + + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + decaps_and_mix(sskr, spkr, ct1) + \end{minted} + \end{quote} + + ``` + + by + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + decaps_and_mix(sskr, spkr, sctr) + \end{minted} + \end{quote} + ``` + +8. In `load_biscuit()`, there was a typo doing an incorrect comparison between `biscuit_no` and `biscuit_used`. This is not a security issue, as a verbatim implementation would simply have lead to a non-functional implementation. We replace + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + assert(pt.biscuit_no <= peer.biscuit_used); + \end{minted} + \end{quote} + + ``` + + by + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + assert(pt.biscuit_no >= peer.biscuit_used); + \end{minted} + \end{quote} + ``` + +9. In the whitepaper we used the labels `"initiator session encryption"` and `"responder session encryption"`, but in the implementation we used `"initiator handshake encryption"` and `"responder handshake encryption"`. While the whitepaper was correct and the implementation was not, we opt to harmonize the whitepaper with the implementation to avoid a breaking change. +10. The protocol strings used in the whitepaper where different to the ones used in the implementation. We harmonize the two by updating the whitepaper to reflect the protocol identifier used in the implementation. We substitute + + ``` {=tex} + \begin{quote} + The protocol identifier depends on the hash function used with the respective peer is defined as follows if BLAKE2s is used: + + \begin{minted}{pseudorust} + PROTOCOL = "rosenpass 1 rosenpass.eu aead=chachapoly1305 hash=blake2s ekem=kyber512 skem=mceliece460896 xaead=xchachapoly1305" + \end{minted} + + If SHAKE256 is used, \texttt{blake2s} is replaced by \texttt{shake256} in \texttt{PROTOCOL}. + \end{quote} + ``` + + with + + ``` {=tex} + \begin{quote} + The protocol identifier depends on the hash function used with the respective peer is defined as follows if BLAKE2s is used: + + \begin{minted}{pseudorust} + PROTOCOL = "Rosenpass v1 mceliece460896 Kyber512 ChaChaPoly1305 BLAKE2s" + \end{minted} + + If SHAKE256 is used, then \texttt{BLAKE2s} is substituted with \texttt{SHAKE256}: + + \begin{minted}{pseudorust} + PROTOCOL = "Rosenpass v1 mceliece460896 Kyber512 ChaChaPoly1305 SHAKE256" + \end{minted} + \end{quote} + ``` +11. The whitepaper stated that Rosenpass uses BLAKE2s, while the implementation used BLAKE2b; we update the whitepaper to reflect that reality. The places where this substitution happened are a bit too numerous to count them all here. On top of this, we added the following paragraph to explain the discrepancy between `PROTOCOL` and actual hash function used: + ``` {=tex} + \begin{quote} + Note that the domain separator used here maintains that BLAKE2s is used, while in + reality, we use BLAKE2b. The reason for this is an implementation error. Since fixing this would have led to a breaking change in the Rosenpass reference implementation, and all other known implementations of Rosenpass simply reproduced this error, we chose to harmonize the white paper with the implementation instead of fixing the implementation. + \end{quote} + ``` +12. Added a section to explain and specify our incorrect implementation of HMAC-BLAKE2b. +13. In `encaps_and_mix()`/`decaps_and_mix()` the whitepaper stated that public key, ciphertext, and shared key are mixed into the chaining key in that order, but the implementation used a different order: public key, shared key, and ciphertext (shared key and ciphertext are swapped). We harmonize the white paper with the implementation. +14. In the white paper, in package `RespHello` the field `auth` was indicated to come after `biscuit`, but in the implementation, `auth` came first and `biscuit` was last. The semantics of how fields in Rosenpass messages are processed generally demand that fields are processed in the order they appear in the message, so having `biscuit` first and `auth` second—as was done in the white paper—would be correct; still, we harmonize the white paper with the implementation. +15. Fix a discrepancy with regard to biscuit key life times. + + ``` {=tex} + \begin{quote} + The \texttt{biscuit\textunderscore{}key} used to encrypt biscuits should be rotated every two minutes. Implementations should keep two biscuit keys in memory at any given time to avoid having to drop packages when \texttt{biscuit\textunderscore{}key} is rotated. + \end{quote} + ``` + + by + + ``` {=tex} + \begin{quote} + The \texttt{biscuit\textunderscore{}key} used to encrypt biscuits should be rotated frequently. Implementations should keep two biscuit keys in memory at any given time to avoid having to drop packages when \texttt{biscuit\textunderscore{}key} is rotated. The Rosenpass reference implementation retires biscuits after five minutes and erases them after ten. + \end{quote} + ``` +16. Point out explicitly that we use KEMs from NIST-Competition Round 3. Include links to the competition submission packages. Update citations to reflect the exact specification version. +17. Consistent naming convention. Always use the term `secret key`, never `private key`. +18. `pidiC` -> `pidi_ct`; to make it clearer that this is a cipher text +19. Where we refer to the biscuit ciphertext, we now use the term `biscuit_ct`. Previously we had used various variable names such as `nct` (nonce followed by cipher text) or just plain `biscuit`. +20. In `load_biscuit`, we make it clear that destructuring of `biscuit_ct` destructures a concatenation. + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + let (n, ct) = biscuit_ct; + \end{minted} + \end{quote} + ``` + + with + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + let concat(n, ct) = biscuit_ct; + \end{minted} + \end{quote} + ``` +21. Added a section about timers used in the Rosenpass protocol + +Additional changes (also motivated by a close review, but not reported by Steffen): + +1. Fig. 2 "Rosenpass Message Types", CookieReply package. Renamed the length sum from payload to package. +2. Fig. 2 "Rosenpass Message Types", Envelope package. Renamed the length sum from envelope to package. +3. In `load_biscuit()` fix a naming typo: + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + lookup_peer(pt.peerid); + \end{minted} + \end{quote} + ``` + + with + + ``` {=tex} + \begin{quote} + \begin{minted}{pseudorust} + lookup_peer(pt.pidi); + \end{minted} + \end{quote} + ``` +4. Remove reference to the proof-of-IP-ownership-based DoS mitigation feature not being implemented. Add a notice, that the feature is currently experimental. +5. Fixed a few typos and capitalization issues + #### 2025-06-24 – Specifying the `osk` used for WireGuard as a protocol extension \vspace{0.5em} @@ -749,7 +1151,7 @@ By removing all retransmission handling code from the cryptographic protocol, we ``` {=tex} \begin{quote} \begin{minted}{pseudorust} - // In December 2024, the InitConf retransmission mechanisim was redesigned + // In December 2024, the InitConf retransmission mechanism was redesigned // in a backwards-compatible way. See the changelog. // // -- 2024-11-30, Karolin Varner @@ -777,7 +1179,3 @@ PR: [#142](https://github.com/rosenpass/rosenpass/pull/142) - Added section "Denial of Service Mitigation and Cookies", and modify "Dealing with Packet Loss" for DoS cookie mechanism \printbibliography - -\setupimage{landscape,fullpage,label=img:HandlingCode} -![Rosenpass Message Handling Code](graphics/rosenpass-wp-message-handling-code-rgb.svg) - diff --git a/rosenpass/.test_vectors/crypto_server_test_vector_1.toml b/rosenpass/.test_vectors/crypto_server_test_vector_1.toml index 89b2e4b..14a1db1 100644 --- a/rosenpass/.test_vectors/crypto_server_test_vector_1.toml +++ b/rosenpass/.test_vectors/crypto_server_test_vector_1.toml @@ -150,7 +150,7 @@ test_vec_set_code_location = "rosenpass/src/protocol/test_vector_sets.rs:44" [[entries]] entry_type = "Output" -name = "ih.pidic" +name = "ih.pidi_ct" value = "Y3Wstn84+vmUb/a/CtWHFixkdyTFKEaE7joUFM0vBZPehPAeDOXls/u5I1PvViF6" code_location = "rosenpass/src/protocol/protocol.rs:3615" test_vec_set_code_location = "rosenpass/src/protocol/test_vector_sets.rs:44" diff --git a/rosenpass/src/hash_domains.rs b/rosenpass/src/hash_domains.rs index cc0333b..df64779 100644 --- a/rosenpass/src/hash_domains.rs +++ b/rosenpass/src/hash_domains.rs @@ -166,7 +166,7 @@ hash_domain_ns!( protocol, cookie_key, "cookie-key"); hash_domain_ns!( /// Hash domain based on [protocol] for calculating the peer id as transmitted (encrypted) - /// in [crate::msgs::InitHello::pidic]. + /// in [crate::msgs::InitHello::pidi_ct]. /// /// # Examples /// @@ -179,7 +179,7 @@ hash_domain_ns!( hash_domain_ns!( /// Hash domain based on [protocol] for calculating the additional data /// during [crate::msgs::Biscuit] encryption, storing the biscuit into - /// [crate::msgs::RespHello::biscuit]. + /// [crate::msgs::RespHello::biscuit_ct]. /// /// # Examples /// diff --git a/rosenpass/src/msgs.rs b/rosenpass/src/msgs.rs index f6ea1b6..9fbeba2 100644 --- a/rosenpass/src/msgs.rs +++ b/rosenpass/src/msgs.rs @@ -135,7 +135,7 @@ pub struct InitHello { /// Classic McEliece Ciphertext pub sctr: [u8; StaticKem::CT_LEN], /// Encryped: 16 byte hash of McEliece initiator static key - pub pidic: [u8; Aead::TAG_LEN + 32], + pub pidi_ct: [u8; Aead::TAG_LEN + 32], /// Encrypted TAI64N Time Stamp (against replay attacks) pub auth: [u8; Aead::TAG_LEN], } @@ -188,7 +188,7 @@ pub struct RespHello { /// Empty encrypted message (just an auth tag) pub auth: [u8; Aead::TAG_LEN], /// Responders handshake state in encrypted form - pub biscuit: [u8; BISCUIT_CT_LEN], + pub biscuit_ct: [u8; BISCUIT_CT_LEN], } /// This is the third message sent by the initiator to the responder @@ -233,7 +233,7 @@ pub struct InitConf { /// Copied from RespHello pub sidr: [u8; 4], /// Responders handshake state in encrypted form - pub biscuit: [u8; BISCUIT_CT_LEN], + pub biscuit_ct: [u8; BISCUIT_CT_LEN], /// Empty encrypted message (just an auth tag) pub auth: [u8; Aead::TAG_LEN], } diff --git a/rosenpass/src/protocol/protocol.rs b/rosenpass/src/protocol/protocol.rs index ff1a155..faaa056 100644 --- a/rosenpass/src/protocol/protocol.rs +++ b/rosenpass/src/protocol/protocol.rs @@ -3608,11 +3608,11 @@ impl CryptoServer { // IHI6 protocol_section!("IHI6", { hs.core.encrypt_and_mix( - ih.pidic.as_mut_slice(), + ih.pidi_ct.as_mut_slice(), self.pidm(peer.get(self).protocol_version.keyed_hash())? .as_ref(), )?; - TV::check_value(&test_values.init_hello_pidic, &ih.pidic); + TV::check_value(&test_values.init_hello_pidi_ct, &ih.pidi_ct); TV::check_value( &test_values.init_handshake_mix_3, &hs.core.ck.clone().danger_into_secret(), @@ -3707,7 +3707,7 @@ impl CryptoServer { // IHR6 let peer = protocol_section!("IHR6", { let mut peerid = PeerId::zero(); - core.decrypt_and_mix(&mut *peerid, &ih.pidic)?; + core.decrypt_and_mix(&mut *peerid, &ih.pidi_ct)?; self.find_peer(peerid) .with_context(|| format!("No such peer {peerid:?}."))? }); @@ -3784,7 +3784,7 @@ impl CryptoServer { // RHR6 protocol_section!("RHR6", { - core.store_biscuit_with_test_vector::(self, peer, &mut rh.biscuit)?; + core.store_biscuit_with_test_vector::(self, peer, &mut rh.biscuit_ct)?; TV::check_value( &test_values.chaining_key_rhr_6, &core.ck.clone().danger_into_secret(), @@ -3872,7 +3872,7 @@ impl CryptoServer { // RHI6 protocol_section!("RHI6", { - core.mix(&rh.biscuit)?; + core.mix(&rh.biscuit_ct)?; }); // RHI7 @@ -3889,7 +3889,7 @@ impl CryptoServer { // ICI3 protocol_section!("ICI3", { core.mix(&ic.sidi)?.mix(&ic.sidr)?; - ic.biscuit.copy_from_slice(&rh.biscuit); + ic.biscuit_ct.copy_from_slice(&rh.biscuit_ct); }); // ICI4 @@ -3937,7 +3937,7 @@ impl CryptoServer { let (peer, biscuit_no, mut core) = protocol_section!("ICR1", { HandshakeState::load_biscuit( self, - &ic.biscuit, + &ic.biscuit_ct, SessionId::from_slice(&ic.sidi), SessionId::from_slice(&ic.sidr), keyed_hash, diff --git a/rosenpass/src/protocol/test_vector_sets.rs b/rosenpass/src/protocol/test_vector_sets.rs index 615f13a..89cd9e9 100644 --- a/rosenpass/src/protocol/test_vector_sets.rs +++ b/rosenpass/src/protocol/test_vector_sets.rs @@ -61,10 +61,10 @@ pub struct HandleInitiationTestValues { #[test_vec(name = "hs.core.ck 2")] pub init_handshake_mix_2: TestValue>, - #[test_vec(name = "ih.pidic")] + #[test_vec(name = "ih.pidi_ct")] #[test_vec(serialize_with = "serialize_byte_arr")] #[test_vec(deserialize_with = "deserialize_byte_arr")] - pub init_hello_pidic: TestValue<[u8; rosenpass_ciphers::Aead::TAG_LEN + 32]>, + pub init_hello_pidi_ct: TestValue<[u8; rosenpass_ciphers::Aead::TAG_LEN + 32]>, #[test_vec(name = "hs.core.ck 3")] pub init_handshake_mix_3: TestValue>, diff --git a/supply-chain/config.toml b/supply-chain/config.toml index 396bd69..9dbddb4 100644 --- a/supply-chain/config.toml +++ b/supply-chain/config.toml @@ -662,7 +662,7 @@ version = "0.9.8" criteria = "safe-to-deploy" [[exemptions.stacker]] -version = "0.1.19" +version = "0.1.21" criteria = "safe-to-deploy" [[exemptions.syn]]