Use SHA512 instead of SHA-1 exclusively.

[schulze]

NIST recommends not to use SHA-1 since 2006 http://csrc.nist.gov/groups/ST/hash/policy_2006.html and even Microsoft decided to get rid of SHA-1 (in TLS certificates) https://www.schneier.com/blog/archives/2013/11/microsoft_retir.html

So https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Drop should say that

A digest of the final encrypted message including header, the encrypted AES key, IV, and the ciphertext is created via the SHA512 hash function."

[aBothe]

Could this break any binary protocols we use within Qabel?

[cburkert]

Banning SHA-1 is fine. I don't see why this should break something.

[L-Henke]

No. It just states 'or' since the final algorithm is not yet chosen.

[aBothe]

Alright, then..go ahead and change it! :)

[schulze]

Done.

[L-Henke]

No. Dont change anything yet. We are willing to support mobile devices. And SHA512 uses a lot more computing power than any SHA modes. We should give it a little test before chosing blindly.

[schulze]

Can we leave this as SHA512 or SHA256 and change to a more complicated system with different hash functions if it gets a problem in practive?

I don't thing that the hash function will be the bottleneck; hash functions are extremely fast and AES is not.

[schulze]

And RSA is even slower.

[Gottox]

sha512 and we're future-proof. For the post-beta phase I would recommend a plugable cipher-system though

[thechauffeur]

@Gottox do you think SHA512 will be a problem on mobile devices?

[schulze]

In fact iff we really care about speed on ARM devices we should use curve25519, chacha20, poly1305 instead of RSA, AES, SHA-x.

See e.g. Google's Speeding up and strengthening HTTPS connections for Chrome on Android

I won't push for that though :)

[L-Henke]

A short test on my Nexus 4: sha512sum is running 30% slower than sha1sum. This should be feasible. But of course this is a device with a quad core and 2 GB ram. It might be a higher impact on a slower device.

[roeslpa]

I think crypto should be performant, secure and widely known/used/implemented. So programming would be easy because code/libs are available and people would trust us because they heard about it. Using elliptic curve crypto would bring speed and is nearly as known as RSA but at least AES should stay as the symmetric cipher because of the mentioned reasons.

[aBothe]

Alright, then keep SHA512 opt-in/reserved for future use™. :)

[roeslpa]

But I also think that SHA-1 should be banned because of the security reason. :D

[L-Henke]

To fix the direction this issue has taken: The original statement was '... is created via a hash function like SHA1 or SHA512'. Why might the word 'like' be in this sentence?!? Because we chose to use SHA1 and SHA512? No! Because it just wasn't defined yet. Everyone now argues as if we would utilize exactly these two algorithms. The idea to write 'like $WEAKEST_SHA1_ALGORITHM or $STRONGEST_SHA2_ALGORITHM' was to just give an idea or a range what might be used.

It is pretty clear why we don't want to use the broken SHA1 function. But it is really necessary to use the most (time) complex SHA function? That is a fact witch can be discussed here, and in my option decisions like this have to be reasoned. So if you state 'lets use SHA512' at least give a good reason. There are people that argue SHA256 is enough, because if the SHA2 family gets broken, all of these algorithms are almost equally insecure.

There might also be totally different hash algorithms which are much more suitable due to its performance and security...

[roeslpa]

So shall we open 3 issues for a discussion of the symmetric, asymmetric and hash algorithm and discuss separately. And afterwards discuss which key/hash length is our standard security level. And maybe for future versions there are different security levels available for skilled users?

Or is everyone okay with AES and SHA-2? And a discussion should stick to the asymmetric algorithm (which first was not the subject of this issue) and the standard security level for the beta version?

[schulze]

Is it really important to have this discussion now? I understood that it was decided that there should be some algorithmic agility after the beta. Until then "some SHA-2 algorithm", AES, and RSA seems to be a good conservative choice to start with.

I think that deciding which primitives we want to use in the end, is less important, that deciding how we use these primitives in a sensible and secure way (e.g. the mode. nonce, ... decisions and how these things should operate together to do proper authenticated encryption).

Still we need a first specification that can be implemented and "something like one of these algorithms" doesn't work here. SHA-256 and SHA-512 both are viable choices and SHA-1 isn't. I just wrote SHA-512 because it was in the document already.

[thechauffeur]

On 08.09.2014 09:41, Frithjof Schulze wrote:

Is it really important to have this discussion now? I understood that it was decided that there should be some algorithmic agility after the beta. Until then "some SHA-2 algorithm", AES, and RSA seems to be a good conservative choice to start with.

Correct. We do not need this discussion now since we do not need to define a specific algorithm for an infinite use. Every protocol MUST have a version field and as long as we have this we can change the specific algorithm - and even adding a possibility to choose an algorithm - with a version bump.

I think that deciding which primitives we want to use in the end, is less important, that deciding how we use these primitives in a sensible and secure way (e.g. the mode. nonce, ... decisions and how these things should operate together to do proper authenticated encryption).

I support this.

Still we need a first specification that can be implemented and "something like one of these algorithms" doesn't work here. SHA-256 and SHA-512 both are viable choices and SHA-1 isn't. I just wrote SHA-512 because it was in the document already.

Let's roll a dice :P

[aBothe]

https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1

[L-Henke]

We all know that SHA1 is outdated, but you are all arguing with the collision weakness of SHA1 (This is e.g. relevant to set up a rouge CA). A signature has to be exploited with a preimage attack. A preimage attack is extremely more complex than a collision attack. So if the collision resistance of SHA1 is currently 2^61, the preimage resistance is still 2^122 (2^n*2). This is why GnuPG states that SHA1 is still fine for signatures. (And I guess they do really know what they are talking about) https://www.gnupg.org/faq/weak-digest-algos.html

I really don't want to defend SHA1, but if you argue about something at least get your facts straight.

To SHA256 vs SHA512: On my notebook and my server and the Wikipedia example performances SHA512 is faster than SHA256 (Maybe due to the larger state). On my smartphone, SHA512 is 30% slower than SHA256. In conclusion, both should be usable thus I would vote for SHA512.

[roeslpa]

An authenticated encryption can be attacked by a collision weakness if we enc-then-sign: append "collision-bytes" to an own ciphertext which cannot be decrypted, but a software might ignore them and use a signature from another message. But it does not matter since we want to use SHA256/512. I also think SHA512 is a good choice because 30% is something, but hashs are still fast computed.

[L-Henke]

@roeslpa We will definitely not simply ignore undecryptable parts in a drop message and move on like nothing strange happened.

[thechauffeur]

Decision time! :P

[schulze]

Let's stick to SHA512 for now. This is also what the spec is already saying.