[tor-dev] Comparing Proposals 295 and 308

Jean Paul Degabriele jpdega at gmail.com
Wed Oct 23 15:39:44 UTC 2019


Hello everyone,

Below is our response to the main issues raised by Tomer in his previous
email. We went into some detail in order to better convey the severity of
the issues we raised. In summary the main points are the following:

1) The feedback in the polynomial hash is dangerous and renders the overall
   security of proposal 295 unclear. This is not a mere technicality as
   evidenced by our attack below. We show, for a reasonable choice of hash
   function, an attack that breaks basic IND-CPA security of the original
   specification of proposal 295.

2) Proposals 202 and 261 already mention forward security as a desirable
   feature. Proposal 295 provides no forward security at all - see the
   attack below. Even if the hash function in 295 is replaced with SHA3,
   at the expense of a substantial toll in performance, proposal 308 would
   still offer better forward security.

3) A main observation in 308 is that in order to protect against tagging
   attacks, RUP security is not needed at the uppermost layer. It is by
   making that deviation that 308 manages to attain forward security, in a
   provable way, without deteriorating the efficiency. (We actually expect
   it to be faster than 295 as the last node requires only 2 passes Instead
   of 3). Tomer makes a valid point that having RUP security at the
uppermost
   layer would be beneficial in the event that an implementation screws up
   that particular IF statement. However, as we explain below, in the
specific
   case of Tor we do not expect this to be much of an issue.

A more in-depth technical discussion of these points is provided below.
We start by stating our case as to why the basic security of 295 does not
stand on solid ground, then discuss its forward insecurity, and finally
argue why we believe RUP is largely irrelevant as an end-to-end design
goal for Tor.

Overall, the security of 295 is currently unclear and it most likely
requires
changes (from GHASH to a more costly and heavy weight primitive). As far
as we can see, the only benefit that this modified 295 would have over 308
is
end-to-end RUP security. On the other hand 308 offers forward security
(whereas 295 does not), better performance, and it follows well-established
design choices. Moreover, forward security is not easy to add on for any
scheme,
especially when considering leaky pipes. We advocate that a scheme should
be designed and analysed as a whole and are worried that 295 would require
considerable modifications to attain provable, ordinary security, let alone
meaningful forward security.


(1) ``SUBTLETIES'' CONCERNING THE (IN)SECURITY OF PROPOSAL 295.
    Proposal 295 is based on [ADL17]. In [ADL17] a proof of security is
provided to
    obtain authenticated encryption secure against release of unverified
plaintext.
    [ADL17] crucially relies on a wide-tweak tweakable blockcipher. In
proposal
    295 this wide-tweak tweakable blockcipher is instantiated with a
universal
    hash function (GHASH) combined with AES in XEX mode, following results
in
    [ST13], [MI15] and [LRW02].

    However, the problem is that all that theory only applies to a setting
where
    the tweakable blockcipher is called as a stateless whole. In proposal
295
    the output of the universal hash function (T'_1, T'_2, T'_3, T'_4) is
fed
    back into the input of the next invocation of this universal hash
function.
    This mechanism, designed to prevent replay and reorder attacks, results
in
    an unfortunate key-dependency that invalidates the idea that the
universal
    hash together with AES in XEX modes operates as a tweakable blockcipher.
    We disagree that this key-dependency is just a subtlety and we don't
see a
    straightforward way to fix it in a security proof. In general, dealing
with
    key-dependency in security proofs is far from trivial.

    Our observation that feeding a key-dependent input to a polynomial hash
    breaks down the security proof goes beyond the proof in [ADL17]. Indeed
    the results in [ST13], [MI15], [LRW02] all require the hash function to
be
    Almost-XOR-Universal (AXU) and similarly the security of GCM and GCM-SIV
    rests on GHASH and POLYVAL being AXU secure. Now our point is that the
    feedback employed in 295 is outside the model of AXU security and it
    invalidates the results in [ADL17], [ST13], [MI15], [LRW02]. Addressing
this
    issue requires either major alterations to the results in [MI15] and
[LRW02]
    to cater for this feedback or identifying a new non-standard security
    property for the hash function which suffices to prove the security of
295
    and show that POLYVAL or GHASH satisfy that property.

    To see that feeding the digest of an AXU hash back into its input is
    dangerous and not just a theoretical curiosity, consider the following.
For
    fixed-size inputs A = A1||..||Am (consisting of m blocks each of which
    represents an element in GF(2^n)) and a hash key K \in GF(2^n), the hash
    function defined by H(K,A) = A1.K + .. + Am.K^m is a perfectly valid AXU
    hash. Now we construct inputs A, B, and C as follows:

    A = A1||0^n||..||0^n,
    B = Ta||-A1||0^n||...||0^n where Ta = H(K,A),
    D = Tb||0^n||...||0^n where Tb = H(K,B).

    As you can see B contains the digest of A, and D contains the digest of
B.
    Now, evaluating the digests of A and B we get that:

    H(K,A) = A1.K = Ta
    H(K,B) = Ta.K -A1.K^2 = A1.K^2 - A1.K^2 = 0 = Tb
    H(K,D) = 0

    As you can see, irrespective of the value of the key K, we are able to
set
    H(K,B) = 0 (with probability 1), and even worse we have that H(K,B) =
H(K,D)
    = 0 for B \neq D. This should not be possible for an AXU hash, but
because
    inputs B and D are key-dependent this is now possible.

    Note how this corresponds to the setting in 295 (see
    https://people.torproject.org/~nickm/prop295/cascade.pdf) where T' is
    initialised to a fixed known value -- in this case A1. Then the above
choice
    of messages (M = -A1||0^n||...||0^n and M' = 0^n||...||0^n) would
result in
    identical values of N_4 and consequently related layer-3 ciphertexts,
where
    C_3 \xor C'_3 = M \xor M', thereby breaking IND-CPA security. At a more
    fundamental level, this attack also serves to show that the combination
of
    AXU hash and block cipher, in this feedback configuration, does not
yield a
    secure tweakable block cipher.

    Looking at the email discussion from July 11th, 295 originally
specified T'
    to be initialised to a constant value but was later amended to be
    initialised to a random secret value via the KDF. Thus, because of this
    feedback mechanism, the original proposal would have failed to satisfy
even
    basic IND-CPA security. Moreover, the change in the way T' is
initialised
    seems to have been adopted only as an extra precautionary measure
(proposed
    by Nick) rather than purposefully to stifle this attack. We hope that
this
    convinces you that although it looks like a minor difference the
feedback
    mechanism has significant consequences on security. We didn't find an
attack
    on 295 in its current form and it might be possible to prove it secure.
However
    it should be noted that it is a rather unorthodox construction which
deviates
    significantly from the way that AXU hash functions (like GHASH and
POLYVAL)
    are normally used and thus its security simply cannot be taken for
granted.
    The construction appears brittle and would need a dedicated security
    analysis.

    A secondary issue is the choice of hash function. Proposal 295
specifies an
    Almost-XOR-Universal hash function (GHASH), though later in July 2019,
Tomer
    suggested that, in the context of forward security one would probably
need
    something stronger and more costly, referring detailed analysis (and see
    below). From the most recent email we get the impression that Proposal
295
    should be understood to work with an AXU (as specified), although the
    statement "GHASH or POLYVAL or any other collision resistant hash
function
    are all the same to us" confuses us. Collision resistant hash functions
and
    AXU hash functions are really quite different beasts and GHASH and
POLYVAL
    are expressly not preimage or collision-resistant hash functions.

    Clearly, the choice of primitive affects both security and efficiency.
We
    contend that Proposal 295 should not be using an AXU, whereas our
proposal
    can.


(2) THE FORWARD (IN)SECURITY OF 295

    Note that forward security was already indicated as one of the desired
goals
    of new relay cryptography in proposals 202 and 261.

      "A more reasonable definition for forward secrecy would be that no
message
      can be decrypted *after* the state (including ephemeral secrets) that
was
      used to generate this message was replaced."

    In general the security goal should be independent of the internal
workings
    of a scheme, and hence it should not depend on when the scheme updates
its
    state. Rather it is the other way round: forward security requires that
once
    a message has been decrypted, the state ought to be updated immediately.
    The literature on forward security conforms to this principle as well.

      "I find that the attack is not very convincing."

    It is true that the attack we described in our previous email recovers
only
    the last ciphertext. However this was under the assumption that the hash
    function is a *random oracle*. This was meant to show that even for a
    stronger and less efficient choice of hash function (like SHA3) 295
would
    still not be able to attain full-fledged forward security. However,
with a
    hash function like GHASH or POLYVAL, the situation is much worse as 295
    provides no forward security whatsoever. Referring once again to the
    notation used in:
https://people.torproject.org/~nickm/prop295/cascade.pdf
    consider the following attack. Given the current state of the exit node
    (Ktf3, Khf3, T'_3, T'_4) and the sequence of prior ciphertexts pairs
(N3,
    C3), the attacker can use this information to recover previous values of
    T'_3 and T'_4. Let T''_3 represent the preceding value of T'_3, then
T'_3 =
    GHASH(Khf3, T''_3 || C_3) which yields a linear equation with only one
    unknown: T''_3. A similar situation arises for T''_4 an it thus can
also be
    recovered. Once T''_3 and T''_4 are recovered, the same process can be
    repeated to recover the previous values in an iterative fashion. Note
that
    this recovers all key and state material thereby allowing the
decryption of
    all prior ciphertexts.


(3) AUTHENTICATION AND THE IF STATEMENT.

      "authentication of the last node depends solely on the proper
execution
      of the IF statement on Line 266. As a result, if this line is skipped
for
      some reason (e.g., because an adversary corrupted the last node, a
bug,
      or as a result of over-optimization), modified messages may leave the
      network. "

    Both 295 and 308 have an IF statement that if bypassed authenticity
would be
    broken. The difference is that in 308 the adversary would have control
over
    the plaintext (a chosen forgery), whereas in 295 the plaintext would be
    randomised (an existential forgery). This is the only difference here.
For
    general AEAD schemes this would normally be considered as providing
    robustness against misuse. However in the specific case of Tor we do
not see
    this to be much of an issue for the reasons set out below. This choice
has
    an effect on efficiency: the last round in 308 requires only *two
passes*
    whereas 295 requires *three passes*. Thus the last layer decryption in
308
    is more efficient than 295 thereby reducing the load on the exit nodes.

    Now consider the scenarios listed by Tomer in which the IF statement
could
    be skipped:

    a) The last node is corrupted - If the exit node is corrupted then no
       authenticity is possible. Remember that authenticity is only
end-to-end
       and if the last node is corrupted it can always output any message
of its
       choice.

    b) Thus the only setting where it makes sense to consider this
possibility
       is that of a bad implementation. However, to begin with, Tor is a
       relatively closed ecosystem, in that there aren't that many
       implementations of onion relays. More importantly however, such a
flaw is
       unlikely to go unnoticed as it would affect correct functionality
due to
       the leaky-pipe architecture. If a ciphertext is accepted even when
the IF
       statement fails then that would cause an intermediate onion router to
       recognise the ciphertext as its own and consequently the ciphertext
would
       not reach the intended recipient. As such the likelihood of such a
bug
       seems rather remote.


Best,

Martijn, Alessandro, and Jean Paul

----------------------------------------------

[LRW02] M. Liskov, R. Rivest, D. Wagner, "Tweakable block ciphers", CRYPTO
2002.

[MI15] K. Minematsu and T. Iwata, "Tweak-Length Extension for Tweakable
Blockciphers", IMACC 2015.

[ADL17] Tomer Ashur, Orr Dunkelman, Atul Luykx, "Boosting Authenticated
Encryption Robustness with Minimal Modifications", CRYPTO 2017.

[ST13] Thomas Shrimpton, R. Seth Terashima, "A Modular Framework for
Building
Variable-Input Length Tweakable Ciphers", ASIACRYPT 2013.

On Wed, Oct 16, 2019 at 10:57 AM Tomer Ashur <tomer.ashur at esat.kuleuven.be>
wrote:

> Dear all,
>
> Some time ago I sent to this mailing list a proposal for using the ADL
> construction to solve the crypto tagging attack and it was registered as
> Proposal 295. Then, about a month ago Jean Paul Degabriele sent another
> proposal aiming for the same, which was registered as Proposal 308. We’ve
> now had the chance to compare both proposals and we provide our
> observations below.  But before we discuss the pros and cons of each
> proposal, I’d like to re-state our goal for Proposal 295. Our aim was to
> build something that:
>
> 1. does not lose any security guarantees that are already in place;
>
> 2. prevents successful crypto-tagging; and
>
> 3. does not introduce new weaknesses.
>
> We *did not* consider advanced security goals such as forward secrecy
> and/or non-repudiation which was also mentioned earlier on this mailing
> list.
>
>
>
> In achieving these goals, the two proposals are almost the same: for the
> encryption part, both use layered encryption where the nonce is tweaked
> with a digest of the ciphertext, and sent in encrypted form to the next
> node as part of the ciphertext. The only meaningful difference I could find
> is that instead of using the output of the universal hash function (i.e.,
> GHASH) as a running digest as is done in Proposal 295, Proposal 308 uses
> the encrypted nonce. Jean Paul made the correct observation that our
> security proof did not account for key-dependent input, but we believe that
> this can be resolved by rewriting the proof. In either case, this is a
> subtlety and common ground can be found. On a high level, both proposals
> use the same mechanism to avoid crypto-tagging.
>
>
>
> Where the proposals differ is in the authentication part. Proposal 295
> makes a functional separation between the encryption part and the
> authentication part, cf. Lines 150-152 (authentication) and Lines 156-160
> (layered encryption). Conversely, Proposal 308 does not offer such
> separation, and the authentication and encryption of the last node are done
> in a single pass (cf. Lines 227-230 and Lines 244-252). This comes with
> what we think are two highly unwanted side effects defeating the purpose of
> using the ADL construction to begin with: the authentication of the last
> node depends solely on the proper execution of the IF statement on Line
> 266. As a result, if this line is skipped for some reason (e.g., because an
> adversary corrupted the last node, a bug, or as a result of
> over-optimization), modified messages may leave the network. Moreover, the
> last layer is malleable which means that a difference introduced to the
> ciphertext entering the last node will be preserved through the final
> decryption (given that the IF statement on Line 266 is skipped). This is
> because the decryption nonce does not depend on the authentication process
> (in the lingo of Proposal 308 this is called a “dynamic nonce”).
>
>
>
> Comparing this to Proposal 295 we see that the same cannot happen. Any
> change introduced at any point (including the ciphertext entering the last
> node) will completely destroy the payload in an irrecoverable way (the same
> happens in the “static layers” of Proposal 308; only the dynamic layer is
> malleable).
>
>
>
> For the record, a corollary of all of this is that if Sf_I is leaked
> (e.g., via a side channel in the generation process of Nf_I that is used by
> the IF statement), the adversary now has the secret it needs to decrypt the
> ciphertext regardless of the authentication process. Not being able to do
> this is exactly what’s captured by the RUP property used in Proposal 295 in
> which the only way to obtain N_4 (the counterpart of Proposal 308’s Nf_I)
> is via a successful digest of an unmodified ciphertext.
>
>
>
> The place where Proposal 308 nicely extends over Proposal 295 is in the
> forward secrecy domain. In an email to this mailing list we conjectured
> that if certain changes are made to Proposal 295 it will provide forward
> secrecy in addition to its crypto-tagging resistance. Jean Paul suggested
> an attack against this conjecture, but I find that the attack is not very
> convincing. Indeed, once the keys are leaked, the last message can be
> recovered. But I don’t think that there’s anything surprising in the fact
> that the set of keys that would have normally decrypted a message will also
> do so if leaked to an adversary. A more reasonable definition for forward
> secrecy would be that no message can be decrypted **after** the state
> (including ephemeral secrets) that was used to generate this message was
> replaced. Admittedly, Proposal 308 replaces this state earlier than
> Proposal 295 (immediately after processing  the message vs. after
> processing the next message), which may be desirable, but is anyway not
> disastrous.
>
>
>
> That being said, this discussion is theoretic in nature since of the two
> proposals, only Proposal 308 offers an actual mechanism. For Proposal 295
> we only offer a conjecture. We also tend to somewhat agree that frequent
> re-keying is a better way to achieve forward secrecy.
>
>
>
> Regardless of which is the better way, both can be built on top of the
> encryption mechanism we offered in Proposal 295 whose goal is to resist
> crypto-tagging. In the interest of moving forward we propose to implement
> Proposal 295 as suggested or something close to it (e.g., using POLYVAL) to
> counter crypto-tagging, then discuss alternatives to achieving forward
> secrecy and add those on top of the ADL construction via Proposal 308.
>
>
>
> A few side notes:
>
> 1. Proposal 308 argues that POLYVAL is more suited than GHASH to our this
> use-case. This is an implementation issue. GHASH or POLYVAL or any other
> collision resistant hash function are all the same to us.
>
> 2. I'm pretty sure there's a typo on Line 250 in Proposal 308 and that the
> text should be Y_I = Tf_{I+1} ^ X_I. Otherwise, I can't see how the
> protocol decrypts on Line 285.
>
> 3. The lengths in Section 2.2 (marked for revision) are given in bytes,
> but then in Section 2.3 they are treated as bits.
>
> 4. Line 230 has unbalanced parenthesis.
>
>
>
> Tomer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20191023/e9f4fc09/attachment-0001.html>


More information about the tor-dev mailing list