Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?

Subject: Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2013-11-13 18:03:53

>> 2) Please, please please make them templates suitable
>> for use in *all* systems including 8-bit through 64-bit
>> microcontrollers. Thereby I explicitly mean making the
>> so called "padding length" (of bits in your case) a template
>> parameter. Hash algos with any kind of 64-bit use are
>> can not be sensibly ported to a wide range of micros.

> I'm not entirely sure how the padding length changes based on the
> processor upon which the routine is running. The pad length is spec'd
> to SHA, which I am sure you know, so I must be missing something here.
> Nevertheless I am willing to work with you to get things right on
> e.g., 8-bit micros.
 
Let me try to add a few details. Most developers only think
of large desktop PCs when developing hash algorithms.
They are, however, extremely useful for small embedded
systems for such versatile tasks as checking the integrity of
ROM/Flash memory regions, securing small data packages
in communication protocols, or data hiding when field
programming with a boot loader, etc.
 
Consider the counter that counts the total number of bits
in the digest sequence. Some people call this the padding length,
although I find this name non-intuitive. This is the running total
bit count that will be integrated into the hash in the finalize stage.
Many programmers simply set the size this counter up to the
maximum, which may be unsigned 64-bit integer. This makes
sense because when supporting very long data streams.
 
But consider a microcontroller that might handle small
data payloads. These might fit into unsigned 8-bit integer.
In this case, forcing the microcontroller to manipulate
a 64-bit counter leads to unduly poor performance.
So let the user decide the size of the parameter via
template parameter.
 
In addition, there are numerous loops in hashing algorithms
that run to an upper limit of, say, 64 or 80. Instead of using
plain integer for these, it is possible to retain portable
performance and still handle the size of the loop by using
uint_least8_t or uint_fast8_t.
 
There are several such design choices. If you would
like to compare notes, you may be interested in md5,
sha1, or sha256 in the directory shown below at git.
 
https://github.com/ckormanyos/real-time-cpp/tree/master/ref_app/src/math/checksums/crypto_hash
 
There is another interface detail that can lead to a
useful flexibility. In addition to init --- digest --- finalize scheme,
some use cases need to finalize a running hash, yet retain
its state. This can be accomplished with a kind of function
such as "get_result_and_nochange_the_state".
In this way, a running hash final result can be obtained,
but more bytes can be fed into the hash. This can be
a constant member function, as a copy of the hash
object needs to be made.
 
If you would like to compare notes, or need some
MD5, SHA-1, SHA-256 test cases based on the NIST vectors,
or just would like to see a really efficient microcontroller
(and PC) implementation, the codes in my git above
may useful.
 
Keep up the good work!
 
Sincerely, Chris.
 



On Wednesday, November 13, 2013 8:56 PM, foster brereton <fosterb+boost_at_[hidden]> wrote:
  
On Wed, Nov 13, 2013 at 11:40 AM, Christopher Kormanyos
<e_float_at_[hidden]> wrote:

[snip]

> Yes. Absolutely.
>
> I thought there were some restrictive licensing conditions on the
> algorithms themselves that were incompatible with BPL.
> But others will know this better than I do.
>
> I have two suggestions, if it ever gets that far.
>
> 1) Consider making the interface similar to Boost's CRC
> interface, which already exists. I think this does the
> init --- digest --- finish thing, more or less, whereby
> the concept of the final XOR value might be the finish.

An interface is being provided that closely mimics init-digest-finish.
In OpenSSL's implementation of SHA it's init-update-final, and I am
thinking it would be best to conform to other SHA implementations as
close as possible.

> 2) Please, please please make them templates suitable
> for use in *all* systems including 8-bit through 64-bit
> microcontrollers. Thereby I explicitly mean making the
> so called "padding length" (of bits in your case) a template
> parameter. Hash algos with any kind of 64-bit use are
> can not be sensibly ported to a wide range of micros.

I'm not entirely sure how the padding length changes based on the
processor upon which the routine is running. The pad length is spec'd
to SHA, which I am sure you know, so I must be missing something here.
Nevertheless I am willing to work with you to get things right on
e.g., 8-bit micros.


-foster

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost