@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hagen
+orignal
+postman
+weko
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
FreefallHeavens
Irc2PGuest43975
Irc2PGuest48909
Irc2PGuest67564
Irc2PGuest91332
Onn4l7h
SoniEx2
T3s|4_
Teeed
anon2
b3t4f4c3__
bak83_
boonst
dr4wd3
eyedeekay_bnc
goose2
goose2_
hk
itsjustme
j6
not_bob_afk
numberwang
onon_1
poriori_
profetikla
qend-irc2p
rapidash
shiver_
u5657
unwr
veiledwizard
w8rabbit
x74a6
psi
zzz: would pq efforts here be for resisting decryption of traffic sent before pq or resisting decryption of traffic sent after pq? the former i have seen a few schemes the latter doesnt seem very practical from the key sizes.
zzz
psi, you're talking hybrid vs. pq-only?
psi
sort of, more like is it meant to resist online attacks where the attacker can mangle traffic as it crosses the mitm, or just traffic captured from the past.
psi
the former being sent after pq, the latter being sent before pq
zzz
think I'm confused about "after pq" and "before pq" terminology
dr|z3d
I think he's referring to whether or not the traffic is captured in realtime (after pq) or whether it's processed as a dump of traffic captured some time before we hit post-quantum.
dr|z3d
"pq" being the point in time at which quantum decryption of existing schemes can be broken.
dr|z3d
s/can be broken/is possible
psi
correct
zzz
psi why does "after pq" require larger key sizes?
dr|z3d
this java 19 you speak of, zzz.. looks like you jumped into a tardis to retrieve it :)
dr|z3d
oh, my bad, I was looking in the 21.04 repos.
dr|z3d
*22.04
psi
zzz: with schemes that are before pq, you can do a pq key exchange over an already established authenticated channel to generate an extra parameter to use in a kdf that can generate a secure shared secret. but... this auth is usually secure if ecdlp is not broken. afterwards you'll need a pq auth scheme which has huge keys
psi
cloudflare did some cool research on using key encapsulation mechanisms for post quantum but idk if that interactive protocol can work pq
psi
the pq public signing keys are like 64KB or something ludicrous
zzz
no
psi
you'd have to address them via hash at that point
zzz
sntrup761 is 1158 byte pubkey which is viable
zzz
openssl is doing it
psi
sntrup is for kem
psi
do they have a signing version?
zzz
no, afaik all PQ signing is broken
zzz
so this is encryption only
psi
yeah sounds about right
zzz
so the choice is hybrid (PQ + regular DH, what openSSL is doing) or just PQ
psi
is it at least authenticated?
zzz
it's on top of regular ssl
zzz
the pq part is encryption only with eph. keys only
psi
yeah we do hybrid sntrup761 + x25519 + blake2 the result
psi
at work
zzz
so with hybrid, there's no pubkeys in the netdb. Or we could yolo pq-only with static keys in the netdb
zzz
either way I don't see any "before/after" distinction
psi
you could use hash of the sntrup pubkey as the "identity" then bundle the whole thing in the router info
psi
fair
psi
i assumed the sntrup keys could malleable
psi
could be*
zzz
I probably misspoke about authentication. With the non-hybrid approach you would get it presumably
zzz
see the paper "Post-quantum WireGuard".