4
$\begingroup$

I am trying to understand the security level of TinyJAMBU-128.

As shown in Table 4.1 page 12 of this document, TinyJAMBU-128 claims 112-bit security. However, it has a 128-bit key. How have we lost 16 bits of key? What is the obvious attack that has $2^{112}$ time complexity?

Improve this question
$\endgroup$
2
  • $\begingroup$ I don't see any rationale behind this. $128-112 = 16, 256-224= 32, 256/128 =2= 32/16$ $\endgroup$
    – kelalaka
    Dec 20, 2020 at 19:33
  • 2
    $\begingroup$ See the better question "Why do NIST want 112-bit security from 128-bit key size for Lightweight Cryptography"crypto.stackexchange.com/questions/87058 $\endgroup$
    – user
    Dec 21, 2020 at 6:09

2 Answers 2

Reset to default
4
$\begingroup$

I believe this is simply a statement of the intention to meet the submission requirements set out by NIST for lightweight ciphers. Note that the paper linked in the question refers to "security goals".

As per section 3.1:

An AEAD algorithm shall not specify key lengths that are smaller than 128 bits. Cryptanalytic attacks on the AEAD algorithm shall require at least ${2}^{112}$ computations on a classical computer in a single-key setting. If a key size larger than 128 bits is supported, it is recommended that at least one recommended parameter set has a key size of 256 bits, and that its resistance against cryptanalytical attacks is at least $2^{224}$ computations on a classical computer in a single-key setting.

Note that these are the final submission requirements from 2018. It seems the figure for 192-bit is deduced from the requirements for 256 bit, or is perhaps referencing earlier requirements.

Improve this answer
$\endgroup$
5
  • $\begingroup$ This is the necessary requirement. The article fails to explain at any point why their 128-bit will have 112 bits security. They even can say we have 128-bit security, too. There is no argument to verify both. Actually, the linear-diff attack claims tend to 128 but they claim 112. Not a good argument around there, as far as I can say. $\endgroup$
    – kelalaka
    Dec 20, 2020 at 21:57
  • 1
    $\begingroup$ The paper in the question only mentions that the security goal of their 128 bit mode is 112 bits security. It doesn't say it has 112 bit security. As they submitted it to NIST they met (and I suppose exceeded) the necessary requirements. Agree it's a bad paper though, even misspells 'bytes' as 'byes' at one point. $\endgroup$
    – Modal Nest
    Dec 20, 2020 at 22:07
  • $\begingroup$ That is the point, why do you target 112 while you can target 128. I see it as an empty claim. The OP asked only 128 and there is not a single argument for this. $\endgroup$
    – kelalaka
    Dec 20, 2020 at 22:13
  • $\begingroup$ @kelalaka Well why do NIST target 112 when they can target 128? It's not a claim as it's a goal. You'd know better than me whether it's a weak paper, but they are security goals. The security goals of the Maginot line aren't weak claims, regardless of how stupid the Maginot line was. The empty claims in that paper can only exist in the later security analysis part. $\endgroup$
    – Modal Nest
    Dec 20, 2020 at 22:33
  • $\begingroup$ This still doesn't explain the goal, since expect discarding the keys, there is no direct way to tell what kind of attack can cause the loss of 16-bit key security. Still, AES has 128 bits and after 20 years it still has 128 bits security on single targets, not in multi-targets. It is just playing with the numner. I should write more articles after seend those around. +1 for the necessary requirement. $\endgroup$
    – kelalaka
    Dec 20, 2020 at 22:46
1
$\begingroup$

I can't read the mind of the authors, but beside 112-bit security being enough to meet the submission requirements as pointed in that other answer, there are reasons to take a small security margin in what's claimed compared to key size:

  • The algorithm will still stand fully unbroken if one comes with an attack costing slightly less than brute force. Contrast with AES-128, which is technically broken by Andrey Bogdanov, Dmitry Khovratovich, Christian Rechberger's Biclique Cryptanalysis of the Full AES (in proceedings of AsiaCrypt 2011), with cost $2^{126.1}$ encryptions ($\lesssim 2$ bits within $128$).
  • For many crypto algorithms, a small saving compared to pure brute force is possible. For example, in DES, key search can be sped up by enumerating keys in a well-chosen order that allows caching earlier results, like first outer rounds (that was used for DESCHALL, see Rocke Verser's method). If we count cost in rounds or S-boxes access, that counts as a break, and justifies removing a fraction of a bit from a security claim.
Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.