109300+ entries in 0.064s
mircea_popescu: you have
to get it in your head,
that 0 is an invariant, and permitting it is always dangerous, because it's not "just another number".
mircea_popescu: the problem is fundamental,
though.
the same EXACT
thinking informs
this problem as informs
the earlier discussion with asciilifeform over null ciphers.
zx2c4: i suppose your point is
that you _could_ choose
to obscure
the lengths of
the messages youre sending back? whereas with zero
that isnt a possibility?
mircea_popescu: this reduces your strength, like it or not, because ~attacker inferred something~.
that's what strength is, "attacker doesn't infer". see
the history of
the concept of "ban" and hopw
turning bamburismus'd.
zx2c4: with many
TCP protocols you can infer what's behind it based on
the length
mircea_popescu: one
thing at a
time : if an attacker observes a stream of n messages of lengths != 0,
there is nothing he can infer : maybe
they're part of one message, or maybe
they're not, or maybe
they don't even say anything.
zx2c4: why do you
think zero is a special case?
mircea_popescu: anyway,
the point here isn't
that padded protocols infoleak in multiples of
the paddiong.,
the point is
that 0 is a special case invariant, and yhou can never leak a multiple of 0 safely. because, again, a message of arbitrary length n can be presented as m messages of length k ; but 0 messages can never carry anything.
mircea_popescu: yes,
that's how wer dop it. do you happen
to be familiar with diana coman's work on
the ada impl of rsa/keccak etc >?
zx2c4: this may indeed be
too large of an infoleak and you'd prefer a different padding scheme like always filling
the entire MTU
zx2c4: mircea_popescu: padded protocols infoleak in multiples of
the padding. you get
to see if a given packet elicited a 0 reply, a 16 reply, a 32 reply, a 48 reply, and so forth
mircea_popescu: zx2c4 is
this constant
time ecc implementation on display somewhere btw ? i don't
think i ever saw one before.
zx2c4: the ecc is constant
time. but anyway
the
transport layer doesnt use any ecc
mircea_popescu: in any case, cryptography comes in
two sorts : sort a), known here as "this must be secure, it's so confusing
to me", and sort b).
the moment you say "i can't see what
this gives attacker" you force-shove yourself in group a. it's not your business
to know
the attacker,
that's
the whole fundamental philosophy of ciphering,
that you do not need
to know
the attacker.
zx2c4: then
thoes keepalives are in response
to some message he received
mircea_popescu: this is
the problem : you introduce a categorical breach with
this system.
mircea_popescu: because i can
turn a 31 message into
two 15 messages or back ; but i can't
turn 0 messages into anything else.
zx2c4: mircea_popescu: an attacker can also distinguish between a length 15 message and a length 31 message. i still maintain
this doesnt give an attacker anything useful
mircea_popescu: well, for instance, if i know six nodes in your network and know asciilifeform uses at most
two, and i see
those are not
transmitting, i know he's asleep and send
the
titassassins.
zx2c4: there _are_ attacks, on say voice compression algorithms, which can gather some information from having precise sizes alone, which is why
things are padded
to nearest 16. but i dont see what would be gathered by what youre suggesting
mircea_popescu: why am i held
to explain how a protocol breach can be elevated
to arbitrary height ?
the attracker FIND SOMETHING
zx2c4: what is
the attack here?
zx2c4: what do you get by knowing from inference
that it's a keepalive?
mircea_popescu: so
that eve can't distinguish silent keepalive from actual convo ?
zx2c4: so you can do
traffic analysis on 16 byte chunks
mircea_popescu: so wouldn't it make sense for me
to send 8 whether i have anything
to say or not ?
zx2c4: thats right.
the padding only happens in multiples of 16
mircea_popescu: and if my slut eve in
the other room is listening in, she can distinguish
the case where i sent 0 from
the case where i sent 8 ?
zx2c4: normally 8+16 (though wireguard pads
to nearest 16)
zx2c4: no, i dont
think sending a random string would make it more secure
zx2c4: when you encrypt a message of 0 bytes, you get 0 bytes of ciphertext + 16 bytes of authentication
tag
mircea_popescu: zx2c4 here's a simple alternative
to consider : would you agree
the assemblage would be more secure if instead of sending a null payload you sent a random string ?
zx2c4: normally when you encrypt a message of 32 bytes, you get 32 bytes of cipher
text + 16 bytes of authentication
tag
zx2c4: im not seeing
the vulnerability youre speaking about
mircea_popescu: can you off
the
top of your head give me a dummy example of such ?
zx2c4: in otherwords,
the empty plaintext is still a valid value
to be authenticated-encrypted
zx2c4: yea.
the plaintext is empty. but
the ciphertext is not, since it's authenticated
mircea_popescu: so it is not "empty" in
the sense of "" ; it is empty in
the sense of
the payload being null, but
the actual message is in fact a nonce and some
tags anyway.
zx2c4: because all i need is
the valid authtag/nonce. i dont have any actual content
to put in
there
zx2c4: in
this case, its important
that you send me a keepalive, so
that i know you at least got it. however,
these keepalives arent persistent. if subsequently, i have nothing more
to say
to you,
then we both go silent and dont say anything.
zx2c4: every
time i send you something, i expect
to hear back from you. if i dont hear back from you,
then something bad has happened,and i should start over with a new handshake. my way of hearing back
to you might be in
the natural sense -- i send a
TCP SYN, you send me back a
TCP ACK -- or it might be
the case
that you actually just have nothing
to send back
to me. you got my message just fine, but really just cant
think of anything
to say back
to me.
mircea_popescu: "If a packet has been received from a given peer, but we have not sent one back
to
the given peer in KEEPALIVE ms, we send an empty packet." <<
mircea_popescu: zx2c4
the fundamental problem with "set
to empty" is
that ciphers can be and many are vulnerable
to
this, as a particular case of "known plaintext"
mircea_popescu: asciilifeform he can't answer
that, because it'd be implementation dependant.
zx2c4: also, btw, when you're not using
the payload parameter in a message, it's just set
to empty, because
the authentication
tag used by it is still important for
the protocol.
zx2c4: i remember asking for
this on
the mailing list at some point
zx2c4: which is why
trevor explicitly spells it out
zx2c4: pretty unlikely
that somebody would design a protocol inadvertently
that way
mircea_popescu: this is principally enforced by dizzy operators not
touching
the framework in
the first place, but only given implementations of it.
mircea_popescu: so in no case a dizzy operator could naively set up noise 7.4 so as
to send his payloads in plaintext.
zx2c4: important
to
then know what level of confidentiality you get
there
zx2c4: one
thing
to keep in mind is
that Noise isn't a single ready-made protocol for every application designer
to
take. its instead a protocol framework for protocol designers
to use. knowing explicitly what
the payload param gives you in each message is really important, so
that you dont screw up and put your stuff somewhere it shouldnt be.
there are legitimate protocol use cases for using
the payload parameter early on during
the handshake. its
zx2c4: because IPsec's null cipher mode is for
transport data. what youre asking about with 7.4 is
the payload parameter of
the handshake messages
mircea_popescu: zx2c4 for
the public record, make
the "this is not
the case" distinction plain.
zx2c4: this is not
the case of
the "null mode" in IPsec, which is obviously a complete disaster with no good justification
mircea_popescu: the ready argument for doing it
this way is simplicity.
zx2c4: there are valid use cases of sending information in
the clear in
the payload parameter. for example, perhaps you want
to use it
to advertise which aspects of
the protocol are valid for subsequent messages. or you want
to send a certificate along
to authenticate yourself.
the payload parameter certainly shouldnt be confused with
transport messages, which are what are allowed after
the handshake completes
mircea_popescu: asciilifeform seems
to me
the case
to be,
that
they defined a matrix, and
then implemented all
the cells, and fuck you if you pick a dumb cell.
mircea_popescu: zx2c4 you can voice yourself (permanently) by saying !!up
to deedbot ; saves us
the
trouble.
zx2c4: its not an "unsecured mode" because
this isnt a "mode"
zx2c4: but
there's certainly not any "null-ciphering" and
this is only a misunderstanding of what
the specification says
zx2c4: this is spelled out explicitly in
the section you mentiond
zx2c4: noise defines several different handshakes. wireguard uses Noise_IKpsk2, which is 1-RTT. But
there are other noise handshakes, some of which are 0-RTT, 1-RTT, 2-RTT, 1.5-RTT, and so forth. each handshake message can optionally contain a payload --
to contain
things like, say, certificates or other data.
the question is at which stage of
the handshake do you use
the payload parameter? if you do it
too early in some, you get zero confidentiality. so
a111: Logged on 2018-04-11 16:11 asciilifeform: mircea_popescu: picture if
the selector on kalash had a 'fires backwards' position.
a111: Logged on 2018-04-12 15:36 zx2c4: - minimal state machine, as mentioned above, which means 1-RTT: if something goes wrong with a message being dropped,
the solution is always
to just "start over
the protocol", since it's only 1-RTT.
this saves amazing amounts of complexity
zx2c4: but
there are other noise handshakes
zx2c4: oh,
that's not quite what
that's about
zx2c4: Noise is from
Trevor Perrin. I've been very involved in contributing
to
the project
though (i mentioned at
the end of
the specification)