SHA-3 is not a standard yet

[stbuehler]

SHA-3 is not a standard yet, so it is strange you claim to already be using it.

The final SHA-3 will probably include Sakura as additional "padding" (probably something like 111) before the 10*1 padding, which I couldn't find in your implementation.

At least @blockSize : (1600 - 2 * SHA3.outputLength)/32 looks like it could be the parameters that are actually going to make it.

See kelsey-email-moving-forward-110113.pdf from http://csrc.nist.gov/groups/ST/hash/sha-3/sha-3_standardization.html and search for "Sakura" on http://keccak.noekeon.org/

[maxtaco]

Thanks for the note. It's only used in the second MAC in the most recent Triplesec (v3). Once SHA3 is standardized, we'll bump to v4 and keep backwards-compatibility with the current version of Keccak for decrypting old ciphertexts.

[rilchr]

@stbuehler Nobody cares about "SHA-3" anymore. The NIST (NSA) has been making too many changes to it. Everybody should just use the final version of Keccak which was chosen as the winner in the competition. We don't need ANY post modifications from NSA which will undoubtedly weaken the cryptography or they simply select a weaker subset of Keccak. Say no to SHA-3.

[stbuehler]

@rilchr plonk

Anyway, while we're at it: the draft is out, and the parameters look pretty final to me. It uses sane parameters as demanded by "the community" (and as your implementation selects: capacity := 2 * "security bits") - the only modification is some domain separation padding.

[rilchr]

@stbuehler Sorry but what you say has too many unknowns.

1) What are these "sane" parameters and how do they differ from the original Keccak specification? What is the net effect of these changes from the original. Is it a faster vs more secure tradeoff? If it's faster but less secure I don't want it. A few microseconds improvement is not my use case. I would prefer the greater security margin, or better collision resistance whatever it is.

2) Who do you define as "the community" or who makes up that group of people? Is it made up of 51% NSA employees/JTRIG accounts and 49% reputable cryptographers, security researchers and everyone else?

3) What's this "domain separation padding", why is it needed? Why does it need to be different from Keccak? What security effect does it have? More or less? Does it introduce another subtle weakness?

It's easier and safer just to use the Keccak which won the competition than try debate the validity of these changes by NSA who we know weaken cryptography standards.

[stbuehler]

Don't ask question is you don't want to hear the answers. Read http://keccak.noekeon.org/ if you are actually interested in getting the answers. Stop posting myths about something if you are too lazy to read it up - that is just trolling.

Also stop addressing me - I simply said that what triplesec implements is not SHA3 but plain Keccak; in no way did I ask them to actually use one thing or another.

[rilchr]

@stbuehler I do want to hear the answers. They're not covered at the Keccak homepage either. There's still something not right about the whole SHA3 standardizing process and the changes they're making to it.

This site already knows they're using Keccak it says so on their website:

Similarly, TripleSec protects against a break in HMAC-SHA-512 by always combining it with an HMAC based on Keccak hash algorithm (soon to become the SHA-3 standard).

As far as I'm concerned they can keep using it, there's nothing wrong with it. They don't need to "upgrade" to the SHA3 version.

What myths are you talking about? Here's the facts: 1, 2. We know for a fact NSA have a MOU with NIST. NIST rely on NSA for all their cryptographic knowledge and help during the standardization process. NSA have been proven to use covert efforts to undermine encryption standards. So potentially all standards from NIST is compromised. They already found one as proof, Dual EC DRBG. There will be others. So how can you honestly say that these SHA3 additions are totally trustworthy and not bad?

The SHA3 competition went on for a number of years then a winner was chosen. This took hours, weeks and months of public cryptographer's time to analyze even a few of the contestants. Now during the standardization process the NSA is tweaking things. This forces the public cryptography community to reanalyze every small little change they make just to see how it affects the security. Nobody has time to do that. Lets say some years down the road someone finds one of the new flaws introduced by NSA in the new standard and writes a research publication on it. NIST says "oops, you found our flaw", let's tweak it again using these changes". More months go by and a different researcher discovers another problem with the changes. Repeat ad infinitum. The NSA is wasting everyone's time meanwhile the whole time they'll be using the introduced flaws and breaking the cryptography.

It makes more sense just to use the algorithms as the original designers designed them and which have undergone all the original years of cryptanalysis. It makes absolutely no sense to blindly trust a bad actor such as the NSA with arbitrary changes to the algorithm or to standardize on the weaker parameters in it. Even during the standardization process where you would hope they copy/paste the majority of the Keccak spec to the FIPS spec, who is going to go over the new spec and see if every letter and digit matches up with the original? Even a small change could have disastrous security ramifications.

In conclusion, use Keccak as is and choose your own parameters to meet the needs of your application.

[stbuehler]

This will be the last response on this subject here as it is totally off topic.

The security parameters for SHA3-n are the ones from the original Keccak submission. The only change is the two additional bits as suffix (which is based on a proposal of the original Keccak authors, and nobody seriously thinks this has an impact on security).

The security parameters of SHAKE256 (capacity of 512 bits) are a little bit below of what the Keccak submission contained (capacity of 576 bits), but again no one is seriously asking for more than 256 bits of security (the other change for SHAKE are additional four bits as suffix).

[heronhaye]

Triplesec Version 4 uses the SHA3 standard now.