NFD » ndn-cxx

calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name

Why SHA1?

• SHA1 is deprecated.
• SHA256(issuer_name)[0:4] can serve the same purpose.
• SHA256 is already available in most NDN libraries; using it requires no new code.

Junxiao Shi wrote:

calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name

Why SHA1?

• SHA1 is deprecated.
• SHA256(issuer_name)[0:4] can serve the same purpose.
• SHA256 is already available in most NDN libraries; using it requires no new code.

SHA1 is deprecated for signature calculation usage, but it is still widely used to get a roughly unique id (such as Git). The reason of not using SHA256 is because the calculation overhead. SHA1 is just one round calculation, but SHA256 requires multiple rounds of iterations...

SHA1 is deprecated for signature calculation usage, but it is still widely used to get a roughly unique id (such as Git).

Yes I know that.

The reason of not using SHA256 is because the calculation overhead. SHA1 is just one round calculation, but SHA256 requires multiple rounds of iterations...

Why is calculation overhead significant? Certificate issuers are running on powerful devices.

Is there a use case where certificates need to be issued on an IoT device?

When verifier is a power constrained device, and the device want to retrieve a certificate issued by a particular issuer.

I agree with note-5 about the reason of choosing SHA-1.

For now, we defines only one way to calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name:

Per note-5, the verifier is expected to compute the IssuerId from an issuer name.

There are two concerns:

• The algorithm for IssuerId is described as extensible (based on the usage of "for now" phrase). How could a verifier know which algorithm is chosen?
• Why not use the full SHA-1 digest?
  How to handle collisions caused by truncated SHA-1 digest? If a certificate has 3000 issuers (e.g. web-of-trust, endorsed by every Facebook friend of a person), the probability of having a collision is over 0.1%, which is significant.

For note-5:

• If the device is constrained and have issues calculating sha256, it will not be able to do any RSA/DCA cryptography and there is no point of getting anything

• I'm in general not clearly seeing / agreeing with the concept of hashing "issuer name" and relying on it for purposes other than just disambiguation.

Alex Afanasyev wrote:

• If the device is constrained and have issues calculating sha256, it will not be able to do any RSA/DCA cryptography and there is no point of getting anything

It is not that the device cannot compute SHA256, I just want to safe some computation if it is possible. But anyway, given this is only research demo, let's reject the SHA1 proposal, and use SHA256 instead.

• I'm in general not clearly seeing / agreeing with the concept of hashing "issuer name" and relying on it for purposes other than just disambiguation.

Are you against using hash or against generally disambiguate the certs?

Junxiao Shi wrote:

Per note-5, the verifier is expected to compute the IssuerId from an issuer name.

There are two concerns:

• The algorithm for IssuerId is described as extensible (based on the usage of "for now" phrase). How could a verifier know which algorithm is chosen?

There should be only one mechanism. The reason for "for now" is because we cannot say this one is the best one eventually.

• Why not use the full SHA-1 digest?
  

Because Alex does not like long hashes...

How to handle collisions caused by truncated SHA-1 digest?
If a certificate has 3000 issuers (e.g. web-of-trust, endorsed by every Facebook friend of a person), the probability of having a collision is over 0.1%, which is significant.

Well, I did not expect that many issuers, but if that is really the concern, can we use 8-octets instead, should be long enough

• I'm in general not clearly seeing / agreeing with the concept of hashing "issuer name" and relying on it for purposes other than just disambiguation.

Are you against using hash or against generally disambiguate the certs?

I'm against making assumptions about the disambiguation. Hash/sha1/2 are just viable options for that, without any attached semantic meanings.