Subject: [Hipsec] How much for that hash?

From: Robert Moskowitz <[email-masked]>
Date: Tue, 08 Jun 2010 15:40:45 -0400

It is really being driven home to me how important a cryptographic hash 
is to a total security solution.  Trying to design around this is really 
hard!

So since the argument for not using a hash is the code cost, can anyone 
supply me with a good value for the amount of code (in Kb) for SHA-1?  
For SHA-256?

Thank you.

---

From: Miika Komu <[email-masked]>
Date: Wed, 09 Jun 2010 09:16:42 +0300

On 08/06/10 22:40, Robert Moskowitz wrote:

Hi,

> supply me with a good value for the amount of code (in Kb) for SHA-1?

good point. I am not sure if this was a rhetorical question but replying 
nevertheless :) For example, the the SHA1 code in RFC4634 consists of 
total 700 hundreds lines of code, including the header file, or 332 
physical lines of code (sloccount).

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 9 Jun 2010 18:56:40 +1200

There's a big table of sizes of different crypto algorithms with many different optimisations here: http://www.das-labor.org/wiki/AVR-Crypto-Lib/en

The target processor is AVR, commonly used for these embedded systems.

Andrew

On 09/06/2010, at 6:16 PM, Miika Komu wrote:

> good point. I am not sure if this was a rhetorical question but replying nevertheless :) For example, the the SHA1 code in RFC4634 consists of total 700 hundreds lines of code, including the header file, or 332 physical lines of code (sloccount).
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Jun 2010 14:50:01 +0300

> supply me with a good value for the amount of code (in Kb) for SHA-1?  

Checking our crypto library the sha1 is from 1331 bytes to 8471 bytes
depending how much the round functions are unrolled.

Sha256 function is 2869 bytes of object code. These are c-source
compiled with gcc -Os on i386 architecture and only using memcpy and
memset from external libraries. The interface is normal higher level
interface meaning reset_context, update, final taking variable length
of data in.

If using assembler optimizations would most likely make those even
smaller, especially if the cpu has round function instructions or
similar crypto-optimized instructions, so I would assume it would be
possible to make those even smaller. If you do not need to worry about
getting partial blocks to update or padding for the final data etc
then that would also remove some code (few hundred bytes).
-- 
[email-masked]