Which SHA-2 algorithm should be used?

[Man Ho (Certizen)]

Hi,

I have noted that a lot of arguments being discussed regarding
deprecation of SHA-1 certificates, both intermediate CA certificate and
end-entity certificates.

However, we know SHA-2 is a set of algorithms SHA-224, SHA-256, SHA-384,
SHA-512, SHA-512/224, SHA-512/256. Which SHA-2 algorithm should CAs use?

It seems that most CAs who has SHA-2 root certificate trusted in Mozilla
products has chosen SHA-256. Do you know why not to choose SHA-512 given
that SHA-512 is stronger security strength than SHA-256?


Man Ho

[Man Ho (Certizen)]

[Gervase Markham]

On 08/01/14 06:29, Man Ho (Certizen) wrote:
> However, we know SHA-2 is a set of algorithms SHA-224, SHA-256, SHA-384,
> SHA-512, SHA-512/224, SHA-512/256. Which SHA-2 algorithm should CAs use?

Note that MS does not support SHA-224, so we can exclude that one.

Gerv

[Kurt Roeckx]

I'm not convinced there is a need for the CA certificates themselves to
start using SHA-2. I think the only thing we care about for those is
a preimage attack. SHA-1 still provides 160 bit of security for that.

An 2048 bit RSA key only provides about 112 bit of security. For a 4096
bit key it's slightly over 128 bit, it's hard to find good numbers for
it, but it's around 140 bits. SHA-1 still seems fine for that.

SHA-256 would provide 128 bit for a collision attack and 256 bit for a
preimage attack.

I think it would be nice to have in the future, and would recommend
SHA-256 for new keys, but I see no need to start moving the CAs to
SHA-256 at this time.

For end user certificates I think it's different and we also have to be
more worried about the collision attack. I think for both 2048 and 4096
bit keys SHA-256 should be fine there. The entropy of at least 20 bit
in the certificate should make the collision attack harder and 4096 bit
certificates are probably going to be used in a system were the
total chain is supposed to provide 128 bit of security.


Kurt

[Rob Stradling]

On 08/01/14 11:30, Gervase Markham wrote:
> On 08/01/14 06:29, Man Ho (Certizen) wrote:

>> However, we know SHA-2 is a set of algorithms SHA-224, SHA-256, SHA-384,
>> SHA-512, SHA-512/224, SHA-512/256. Which SHA-2 algorithm should CAs use?
>

> Note that MS does not support SHA-224, so we can exclude that one.

SHA-512/224, SHA-512/256 and SHA-512/t aren't supported either.

SHA-256, SHA-384 and SHA-512 are the algorithms that CAs should use.
See http://www.keylength.com/ for advice on when to use each one.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Peter Gutmann]

Rob Stradling <rob.st...@comodo.com> writes:

>SHA-256, SHA-384 and SHA-512 are the algorithms that CAs should use.

In my playing around with all the TLS and SSH implementations I could find
that talk SHA-2, I've found that SHA-256 is the new SHA-1. In other words if
you want interoprability with anything that does SHA-2, go with SHA-256.

Peter.

[Rob Stradling]

Peter, do you have a list of software/versions that have TLS
implementations that work fine with SHA-256 in certificate signatures
but fail to work with SHA-384 and/or SHA-512 in certificate signatures?

Based on the NIST guidance, we've been using SHA-384 when using RSA-4096
and secp384r1 CA private keys to sign certificates. I've not yet become
aware of any interop issues with stuff that claims to talk SHA-2.

Thanks.

[Kurt Roeckx]

On Wed, Jan 08, 2014 at 01:36:48PM +0100, Mathias Tausig wrote:

> On Wednesday 08. January 2014 12:33:56 Kurt Roeckx wrote:
> > I'm not convinced there is a need for the CA certificates themselves to
> > start using SHA-2. I think the only thing we care about for those is
> > a preimage attack. SHA-1 still provides 160 bit of security for that.
> >
>

> Microsoft requires in its SHA1 deprecation policy, to have SHA-2 based
> intermediate certificates, so it will be a necessity anyway.

Right, the root CAs can stay as they are but the intermediates need
to change to SHA-2 according to Microsoft's policy.

Anyway, for 2048 bit certificates SHA-256 should be fine. For
4096 bit you can argue if SHA-256 is fine or that you should go to
SHA-384. But I don't see the need for SHA-384 for intermediates.


Kurt

[Man Ho (Certizen)]

On 1/8/2014 8:12 PM, Rob Stradling wrote:
> On 08/01/14 11:58, Peter Gutmann wrote:
>> Rob Stradling <rob.st...@comodo.com> writes:
>>
>>> SHA-256, SHA-384 and SHA-512 are the algorithms that CAs should use.
>>
>> In my playing around with all the TLS and SSH implementations I could
>> find
>> that talk SHA-2, I've found that SHA-256 is the new SHA-1. In other
>> words if
>> you want interoprability with anything that does SHA-2, go with SHA-256.
>
> Peter, do you have a list of software/versions that have TLS
> implementations that work fine with SHA-256 in certificate signatures
> but fail to work with SHA-384 and/or SHA-512 in certificate signatures?
>
> Based on the NIST guidance, we've been using SHA-384 when using
> RSA-4096 and secp384r1 CA private keys to sign certificates. I've not
> yet become aware of any interop issues with stuff that claims to talk
> SHA-2.
>
> Thanks.
>

If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why
CAs are so conservative and prefer SHA-256 rather than SHA-512? I think
going directly to a higher security strength should be preferable.

Peter mentioned about interop issues. Does anyone encounter interop
issues with SHA-512?

[Peter Gutmann]

"Man Ho (Certizen)" <ma...@certizen.com> writes:

>If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why CAs
>are so conservative and prefer SHA-256 rather than SHA-512? I think going
>directly to a higher security strength should be preferable.

What extra security does -512 give you that -256 doesn't? I mean actual
security against real threats, rather than just "it has a bigger number so it
must be better"? What I've heard was that the extra-sized hashes were added
mostly for political reasons, in the same way that AES-192 and -256 were added
for political reasons (there was a perceived need to have a "keys go to 10"
and a "keys go to 11" form for Suite B, since government users would look over
at non-suite-B crypto with keys that went to 11 and wonder why they couldn't
have that too).

Given that there's no effective security difference, you need to look at other
issues. SHA-512 certainly leads to a loss in performance when used as a MAC
and you have to attach 64 bytes of MAC to a ten-byte payload. In addition the
need to have 64-bit op support makes SHA-512 suck on 32-bit systems, which is
most of the embedded world.

Peter.

[Man Ho (Certizen)]

On 1/9/2014 9:34 AM, Peter Gutmann wrote:
> What extra security does -512 give you that -256 doesn't? I mean actual
> security against real threats, rather than just "it has a bigger number so it
> must be better"?

According to NIST SP 800-57, only SHA-512 can provide a security
strength of 256 bits, while SHA-256 can only provide 128 bits. I am not
an expert on crypto, but at least it is what it said.

> SHA-512 certainly leads to a loss in performance when used as a MAC
> and you have to attach 64 bytes of MAC to a ten-byte payload.

I just did a google search again. One analysis is that SHA-256 and
SHA-512 have block size of 32 bits and 64 bits respectively. On 64-bit
processor, the arithmetic operations can be performed in the same number
of clock cycles as either 32-bit or 64-bit operations. Therefore, when
working on a 64-bits message, SHA-256 requires two block operations
(each performing 64 iterations of arithmetic operations). SHA-512
requires only one block operations (performing 80 iterations of
arithmetic operations). It also estimate that when performing operations
on 64 bit (8 bytes) message, SHA-512 is about 17% faster and performance
levels out with message size of 4096 bits (512 bytes) at about 53% faster.

> In addition the
> need to have 64-bit op support makes SHA-512 suck on 32-bit systems, which is
> most of the embedded world.

Yes, this is a real concern


Man

[Phillip Hallam-Baker]

On Wed, Jan 8, 2014 at 8:34 PM, Peter Gutmann <pgu...@cs.auckland.ac.nz>wrote:

> "Man Ho (Certizen)" <ma...@certizen.com> writes:
>
> >If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why
> CAs
> >are so conservative and prefer SHA-256 rather than SHA-512? I think going
> >directly to a higher security strength should be preferable.
>

> What extra security does -512 give you that -256 doesn't? I mean actual
> security against real threats, rather than just "it has a bigger number so
> it

> must be better"? What I've heard was that the extra-sized hashes were
> added
> mostly for political reasons, in the same way that AES-192 and -256 were
> added
> for political reasons (there was a perceived need to have a "keys go to 10"
> and a "keys go to 11" form for Suite B, since government users would look
> over
> at non-suite-B crypto with keys that went to 11 and wonder why they
> couldn't
> have that too).
>

The main advantage is more rounds to crypto.

In PPE I use SHA-512 and truncate to 128 bits for Phingerprints.

--
Website: http://hallambaker.com/

[Peter Gutmann]

"Man Ho (Certizen)" <ma...@certizen.com> writes:

>According to NIST SP 800-57, only SHA-512 can provide a security strength of
>256 bits, while SHA-256 can only provide 128 bits.

In that case why not go for a hash with million-bit security? That statement
is meaningless without some sort of qualifiers for what you're trying to
achieve/defend against/whatever. In particular, claiming "256-bit security"
instead of "128-bit security" is only useful when dealing with people who
don't understand its lack usefulness (thus my earlier comment about the
political motivation for keys-that-go-to-11 key sizes, it's so you can come
back to The Mgt. and tell them that your product is twice as secure as
everyone else's [*]).

Peter.

[*] For someone who doesn't understand that a 128-bit key can't be brute-
forced by going out and buying a faster PC, 256-bit is twice as secure as
128-bit.

[Man Ho (Certizen)]

On 1/8/2014 8:12 PM, Rob Stradling wrote:
> Based on the NIST guidance, we've been using SHA-384 when using
> RSA-4096 and secp384r1 CA private keys to sign certificates. I've not
> yet become aware of any interop issues with stuff that claims to talk
> SHA-2.

Do you mean using SHA-384 to sign sub-root certificate and then that
sub-root certificate sign SHA-384 end-entity certificates?

BTW, I have a second thought that the sub-root certificate can be signed
with SHA-384 while the end-entity certificates can be signed with
SHA-256, or vice versa. It should be possible, shouldn't it?

[Rob Stradling]

On 17/01/14 03:39, Man Ho (Certizen) wrote:
>
> On 1/8/2014 8:12 PM, Rob Stradling wrote:
>> Based on the NIST guidance, we've been using SHA-384 when using
>> RSA-4096 and secp384r1 CA private keys to sign certificates. I've not
>> yet become aware of any interop issues with stuff that claims to talk
>> SHA-2.
>
> Do you mean using SHA-384 to sign sub-root certificate

Yes, when we're using our RSA-4096 and secp384r1 root keys to sign the
sub-root certificates.

> and then that sub-root certificate sign SHA-384 end-entity certificates?

Depends on the sub-root key size. When we're using RSA-2048 and
secp256r1, (the NIST guidance says that) SHA-256 is an appropriate match.

> BTW, I have a second thought that the sub-root certificate can be signed
> with SHA-384 while the end-entity certificates can be signed with
> SHA-256, or vice versa. It should be possible, shouldn't it?

Yes.

Examples:
https://comodorsacertificationauthority-ev.comodoca.com/
https://comodoecccertificationauthority-ev.comodoca.com/