6 ms·

Kangaroo Twelve Implementation in Go

44 points by forestjc 9y ago

tptacek 9y ago
K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.
- snakeanus 9y ago
  > The best all-purpose cryptographic hash is probably truncated SHA-2 512 Could you elaborate on that please? Why would you consider it as the "best all-purpose cryptographic hash"?
  - likelynew 9y ago
    It is one most scrutinized hash function, for which no flaw is known. While no flaw is known for SHA-3 and many other hash functions and some might even say that likelihood of finding flaws in them is lesser than SHA-2, none has been analyzed by that many people for that long.
  - wongarsu 9y ago
    On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2). Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster), and it's the one with the longest track record, while the Blake-family and SHA3 are fairly new. It's also widely supported nearly everywhere. All that makes truncated SHA-512 a sane default.
    - snakeanus 9y ago
      > Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster) https://twitter.com/KeccakTeam/status/834789451708628995 https://twitter.com/KeccakTeam/status/834789451708628995 > It's also widely supported nearly everywhere This is true for the non-truncated variants, but I am not aware of any protocol that uses the truncated ones. I will agree with the "longest track record" however, this is an important part.
      - wolf550e 9y ago
        If you are free to choose a hash function, you are free to truncate SHA-512. Truncated SHA-512 is secure, there is no need to wait to see it used in a standardized protocol to increase confidence in its security. Creating a truncate(SHA-512, 256) out of regular SHA-512 is trivial, so it true that it is widely supported nearly everywhere.
        snakeanus 9y ago
        This is wrong, SHA-512/256 is not the same as calculating the output of SHA-512 and then taking the first 256 bits of it, there are some differences between them such as different IVs that would make the outputs also different.
        wolf550e 9y ago
        Yes, sorry. You need to overwrite the initial value (H0) too, in the constructor. You can do that if you can touch the equivalent of the private member variables. SHA-512/256 may be used to hash a message, M, having a length of 𝓁 bits, where 128 0 ≤ 𝓁 < 2. The algorithm is defined in the exact same manner as SHA-512 (Sec. 6.4), with the following two exceptions: 1. The initial hash value, H(0), shall be set as specified in Sec. 5.3.6.2; and 2. The 256-bit message digest is obtained by truncating the final hash value, H(N), to its left-most 256 bits. (from §6.7 in http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4....) EDIT: I trust 'tptacek (in sibling comment) that if there is no chance of protocol confusion, there is no advantage to the different initial value.
    - kobeya 9y ago
      > On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2). Unless you are doing hash trees, in which case SHA-512 is slower than SHA-256, and length extension is not possible. Point is there isn't and shouldn't be a blanket solution.
- sctb 9y ago
  Thanks, we've removed “A Faster SHA-3” from the submission title which isn't purported on the linked page.
- libeclipse 9y ago
  Not BLAKE2?
- NicoJuicy 9y ago
  Isn't swordfish good also? Because it's slow
  - tptacek 9y ago
    No.
  - snakeanus 9y ago
    I am not aware of any hash function with that name. Are you referring to skein maybe? (it uses the threefish cipher internally and was made by the same person who made twofish and blowfish)
- npscalar 9y ago
  Blake2, modern? With the same addition/xor mixture and narrow pipe Merkel-Damgard as MD4, MD5 or SHA-1/2, it's kinda old fashioned.
plygrnd 9y ago
A mention of the always-on culture of these times seemed appropriate. Easy access to information doesn't seem beneficial if said information is geared to attract clicks or foment fear. Or both.
mtgx 9y ago
Isn't this SHA-3 less safe, too? Why not just go with BLAKE2?
- snakeanus 9y ago
  BLAKE2 is less safe than BLAKE as well. >Isn't this SHA-3 less safe, too? Yes, both K12 and M14 are less safe than SHA3. Instead of 12 + 2ℓ rounds (where ℓ is 25 * 2^ℓ = r + c [where r + c = 1600 in both sha-3 and K12]) it uses just 12 rounds (14 for M14). It also uses half the c (c = 512 in sha3-256, c = 256 in K12, where c is the sponge capacity). It provides the same amount of bits of security against collision attacks for both quantum and classical systems, however the preimage security is the ~85 bits for quantum systems (128 in sha3-256) and 128 bits in classical systems (256 in sha3-256) due to the changes in c.
  - tptacek 9y ago
    The word "safe" isn't doing us any favors here. What we're really talking about is the "security margin" of the different hashes. Every hash we're talking about on this thread has a margin far beyond any plausible or foreseeable attacks. None are unsafe.
    - dsacco 9y ago
      This is a serious issue, and I think it's a problem of cryptography education. On the one hand, we (rightly, in my opinion) teach people who haven't studied cryptography that they shouldn't try to implement it on their own. This is good, because cryptography is mostly applied math (hard) and careful software implementation (also hard), and mixing these two hard things without shooting yourself in the foot is very hard. On the other hand, developers who follow this advice don't have a clear way to find the answer to questions like, "Which of these great algorithms do I want?" It's easy to find sound recommendations for which algorithms are well-studied and essentially safe; it's less easy to find guides that compare and contrast algorithms along nuanced axes like computational cost, interoperability, security margin or adaptability. This leads developers to come to their own conclusions based on imperfect understanding of the metrics they can quantify: "I need to encrypt something - Serpent has a much higher security margin than AES (Rijndael), I should probably go with that." "I need to hash something - Keccak won the SHA-3 contest, so I should use that instead of BLAKE." "I need to authenticate something - if I choose two strong algorithms it will be better than one, so I'll use AES-CTR and HMAC-SHA, instead of an AEAD." "More bits means higher security, so I'll use AES256 and SHA-512." I'm noticing this more and more in online discussion, where people seem to be talking past each other about things like the "safety" of algorithms without discriminating between other metrics like speed. In my opinion, it would be better for people to consider "safety" as a mostly binary property if they haven't done enough due diligence to know why one algorithm has a higher or lower security margin than another one, because the other metrics are so much more important. There probably needs to be better cryptography education as well, something that is a bit higher than "do this, don't do this" and which provides some elaboration about the whys inherent to different security margins.
tankfeeder 9y ago
KangarooTwelve on PicoLisp: https://bitbucket.org/mihailp/tankfeeder/src/5a91a025d78eacf68655b6dbec5c2dd346624146/crypto/kangaroo12.l?at=default&fileviewer=file-view-default https://bitbucket.org/mihailp/tankfeeder/src/5a91a025d78eacf...
dom0 9y ago
(from linked resources) > Keccak won the SHA-3 competition, and became the FIPS 202 standard on August 5, 2015. All the other contenders lost. I don't think many professionals would agree with this view of cryptographic competitions. > Being too late to take part in the fight to become SHA-3, it just stood on its own awkwardly. Again with the wording... SHA-3 is not an epic battle for blood and honour. Acting as if a NIST competition is a public fight is rather disconcerting. > It is only in 2013 that SHA-2 joined Intel's set of instructions, along with SHA-1... Technically true, but only now -- four years later -- desktop processors were released supporting the SHA extensions, and none of these are from Intel so far.

44 points by forestjc 9y ago

K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.

snakeanus 9y ago
> The best all-purpose cryptographic hash is probably truncated SHA-2 512 Could you elaborate on that please? Why would you consider it as the "best all-purpose cryptographic hash"?
- likelynew 9y ago
  It is one most scrutinized hash function, for which no flaw is known. While no flaw is known for SHA-3 and many other hash functions and some might even say that likelihood of finding flaws in them is lesser than SHA-2, none has been analyzed by that many people for that long.
- wongarsu 9y ago
  On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2). Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster), and it's the one with the longest track record, while the Blake-family and SHA3 are fairly new. It's also widely supported nearly everywhere. All that makes truncated SHA-512 a sane default.
  - snakeanus 9y ago
    > Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster) https://twitter.com/KeccakTeam/status/834789451708628995 https://twitter.com/KeccakTeam/status/834789451708628995 > It's also widely supported nearly everywhere This is true for the non-truncated variants, but I am not aware of any protocol that uses the truncated ones. I will agree with the "longest track record" however, this is an important part.
    - wolf550e 9y ago
      If you are free to choose a hash function, you are free to truncate SHA-512. Truncated SHA-512 is secure, there is no need to wait to see it used in a standardized protocol to increase confidence in its security. Creating a truncate(SHA-512, 256) out of regular SHA-512 is trivial, so it true that it is widely supported nearly everywhere.
      - snakeanus 9y ago
        This is wrong, SHA-512/256 is not the same as calculating the output of SHA-512 and then taking the first 256 bits of it, there are some differences between them such as different IVs that would make the outputs also different.
        wolf550e 9y ago
        Yes, sorry. You need to overwrite the initial value (H0) too, in the constructor. You can do that if you can touch the equivalent of the private member variables. SHA-512/256 may be used to hash a message, M, having a length of 𝓁 bits, where 128 0 ≤ 𝓁 < 2. The algorithm is defined in the exact same manner as SHA-512 (Sec. 6.4), with the following two exceptions: 1. The initial hash value, H(0), shall be set as specified in Sec. 5.3.6.2; and 2. The 256-bit message digest is obtained by truncating the final hash value, H(N), to its left-most 256 bits. (from §6.7 in http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4....) EDIT: I trust 'tptacek (in sibling comment) that if there is no chance of protocol confusion, there is no advantage to the different initial value.
  - kobeya 9y ago
    > On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2). Unless you are doing hash trees, in which case SHA-512 is slower than SHA-256, and length extension is not possible. Point is there isn't and shouldn't be a blanket solution.
sctb 9y ago
Thanks, we've removed “A Faster SHA-3” from the submission title which isn't purported on the linked page.
libeclipse 9y ago
Not BLAKE2?
NicoJuicy 9y ago
Isn't swordfish good also? Because it's slow
- tptacek 9y ago
  No.
- snakeanus 9y ago
  I am not aware of any hash function with that name. Are you referring to skein maybe? (it uses the threefish cipher internally and was made by the same person who made twofish and blowfish)
npscalar 9y ago
Blake2, modern? With the same addition/xor mixture and narrow pipe Merkel-Damgard as MD4, MD5 or SHA-1/2, it's kinda old fashioned.

plygrnd 9y ago

A mention of the always-on culture of these times seemed appropriate. Easy access to information doesn't seem beneficial if said information is geared to attract clicks or foment fear. Or both.

mtgx 9y ago

Isn't this SHA-3 less safe, too? Why not just go with BLAKE2?

snakeanus 9y ago
BLAKE2 is less safe than BLAKE as well. >Isn't this SHA-3 less safe, too? Yes, both K12 and M14 are less safe than SHA3. Instead of 12 + 2ℓ rounds (where ℓ is 25 * 2^ℓ = r + c [where r + c = 1600 in both sha-3 and K12]) it uses just 12 rounds (14 for M14). It also uses half the c (c = 512 in sha3-256, c = 256 in K12, where c is the sponge capacity). It provides the same amount of bits of security against collision attacks for both quantum and classical systems, however the preimage security is the ~85 bits for quantum systems (128 in sha3-256) and 128 bits in classical systems (256 in sha3-256) due to the changes in c.
- tptacek 9y ago
  The word "safe" isn't doing us any favors here. What we're really talking about is the "security margin" of the different hashes. Every hash we're talking about on this thread has a margin far beyond any plausible or foreseeable attacks. None are unsafe.
  - dsacco 9y ago
    This is a serious issue, and I think it's a problem of cryptography education. On the one hand, we (rightly, in my opinion) teach people who haven't studied cryptography that they shouldn't try to implement it on their own. This is good, because cryptography is mostly applied math (hard) and careful software implementation (also hard), and mixing these two hard things without shooting yourself in the foot is very hard. On the other hand, developers who follow this advice don't have a clear way to find the answer to questions like, "Which of these great algorithms do I want?" It's easy to find sound recommendations for which algorithms are well-studied and essentially safe; it's less easy to find guides that compare and contrast algorithms along nuanced axes like computational cost, interoperability, security margin or adaptability. This leads developers to come to their own conclusions based on imperfect understanding of the metrics they can quantify: "I need to encrypt something - Serpent has a much higher security margin than AES (Rijndael), I should probably go with that." "I need to hash something - Keccak won the SHA-3 contest, so I should use that instead of BLAKE." "I need to authenticate something - if I choose two strong algorithms it will be better than one, so I'll use AES-CTR and HMAC-SHA, instead of an AEAD." "More bits means higher security, so I'll use AES256 and SHA-512." I'm noticing this more and more in online discussion, where people seem to be talking past each other about things like the "safety" of algorithms without discriminating between other metrics like speed. In my opinion, it would be better for people to consider "safety" as a mostly binary property if they haven't done enough due diligence to know why one algorithm has a higher or lower security margin than another one, because the other metrics are so much more important. There probably needs to be better cryptography education as well, something that is a bit higher than "do this, don't do this" and which provides some elaboration about the whys inherent to different security margins.

tankfeeder 9y ago

KangarooTwelve on PicoLisp: https://bitbucket.org/mihailp/tankfeeder/src/5a91a025d78eacf68655b6dbec5c2dd346624146/crypto/kangaroo12.l?at=default&fileviewer=file-view-default https://bitbucket.org/mihailp/tankfeeder/src/5a91a025d78eacf...

dom0 9y ago

(from linked resources) > Keccak won the SHA-3 competition, and became the FIPS 202 standard on August 5, 2015. All the other contenders lost. I don't think many professionals would agree with this view of cryptographic competitions. > Being too late to take part in the fight to become SHA-3, it just stood on its own awkwardly. Again with the wording... SHA-3 is not an epic battle for blood and honour. Acting as if a NIST competition is a public fight is rather disconcerting. > It is only in 2013 that SHA-2 joined Intel's set of instructions, along with SHA-1... Technically true, but only now -- four years later -- desktop processors were released supporting the SHA extensions, and none of these are from Intel so far.