Re: [quicwg/base-drafts] Packet number encryption (#1079)

[ekr <[e-mail]>]

On Tue, Apr 17, 2018 at 7:13 AM, Antoine Delignat-Lavaud <
[e-mail]> wrote:

> We have been discussing this PR at Microsoft with Cedric Fournet and Nick
> Banks and have some comments on the current proposal:
>
>    1.
>
>    As pointed out in the other reviews of this PR, there is a lot of
>    ambiguity regarding whether the packet number length is or isn’t encrypted.
>    In the current PR, the formula to compute the sample_offset only makes
>    sense if the packet number is a “varint”. However, the proposed change does
>    not alter the short packet header, and the PN length is indicated by the
>    last 3 bits of the flags byte, and restricted to be one of 8, 16, or 32
>    bits. Under this assumption, the sample_offset can be redefined as the
>    length of the packet header - we think it is reasonable to keep the PN
>    length public, and avoid having a fuzzy limit between packet header and
>    contents, which could be a source of side channels in the processing of the
>    packet after PN decryption, in particular considering point 2 below.
>    2.
>
>    Given that packet numbers in short packets are only a few bytes and
>    get encrypted without authentication, they are extremely vulnerable to
>    malleability, and using a XOR mask encryption (such as CTR mode or ChaCha20
>    keystream) compounds the problem even further, because an adversary can
>    selectively flip the few bits of interests for him (the low weight ones) to
>    find out using side channels what position the reader is at in the stream
>    (as discussed in the PR comments). We are concerned that some
>    implementations may try to perform optimizations based on the decrypted PN
>    without first first decrypting the packet (for instance, an implementation
>    may chose not to decrypt the packet if the decrypted SN has been acked, or
>    above some threshold). Any such optimization is a side channel that can be
>    extremely efficiently used to recover the PN. We think it is a weakness of
>    the PN encryption scheme to allow implementations to fall into this trap.
>    Using a 32-bit permutation cipher rather than AES-CTR or ChaCha20 would
>    make such attacks less effective. A cipher such as Speck with 32 bit blocks
>    could be well suited for this purpose, and also much faster.
>
>
Note that if we're willing to bake in a permutation, we can just go back to
Kazuho's original proposal of AES-ECBing the PN + <X bytes of ciphertext>
in place.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382445631