Hash functions and streaming

From: frank (francis.moore_at_gmail.com)
Date: 10/24/05 

Date: 24 Oct 2005 12:45:09 -0700

Hi,

I can't seem to find any answers to some questions I have regarding
hash functions and streaming. If anyone can answer those questions, I'd
be extremely grateful.

I have the following scenario:

I have a continuous audio stream of data blocks passing from a server
to a client.
Each block is unencrypted but contains a message digest (hash) of that
block using SHA-1. The message digest is encrypted using RSA with a
private key, creating a digital signature.

At the client side, the public key is used to decrypt the message
digest.
The data block is hashed to produce another message digest.
The two digests are compared to see if they match.
If they do, the data block is accepted. If they do not the data block
is rejected.

I have just heard (although apparently it's old news) that the SHA-1
algorithm
has been fundamentally broken. It doesn't take 2**80 hashes for a
collision to occur, but only 2**69 hashes.

I don't really understand what problem is caused by someone finding a
collision.

So, my questions are:

1. Does this mean that they have reversed the hash back to plaintext?
2. Or have they found some plaintext that hashes to the same value as
some other plaintext? And if so, why is this considered dangerous?
3. How would someone launch an attack against a stream with an
encrypted SHA-1 message digest?
4. If the SHA-1 message digest was not encrypted, what is the worst
that someone could do if they could create a collision?
5. If the stream is very long and the compromised block is just 60
seconds or less of that stream, could a hash collision of that one
block provide a vulnerability for the rest of the stream? Even though
each block will have a completely different hash?

Many thanks,
frank.

Relevant Pages

  • Re: what is a hash ?
    ... >]A hashing function has the same properties. ... And this hash will be the same for the input given, ... > collision. ... two different messages which produce the same message digest. ...
    (sci.crypt)
  • Re: Help with Streams
    ... In particular, it's actually extremely inconvenient to maintain a mapping between the reader and stream positions, and doing so would perform very poorly in any case, because you would have to decode the bytes to characters one at a time. ... You could still buffer the stream data into a byte buffer, but even the overhead of having to call the encoder one character at time would be very noticeable. ... It'd probably be easier to just open the file twice and have my hash routine figure out where it needs to go. ... If it's the latter, then you could actually encode the search string itself into the bytes representing that string, and then scan the stream bytes for a matching sequence of bytes. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: how to generate license keys for software
    ... truncate if you use a hash with larger output length, ... to a fixed 10,000 byte data stream known by both the software and thelicensekey generator. ... the software that takes perhaps 1 second to validate alicensecode. ... One other way to make license key validation slow is to use RSA ...
    (sci.crypt)
  • Re: How random is dev/random?Also Keypress random generator
    ... We filtered out streams of zeroes and ones from the stream, ... When we had 256 bits of data, we ran that through a hash algorithm ... >that needed to use randomness. ... >We could generate slightly over 1 kilobytes of randomness per second ...
    (sci.crypt)
  • Re: How random is dev/random?Also Keypress random generator
    ... We read the mono samples and discarded everything but the ... We filtered out streams of zeroes and ones from the stream, ... When we had 256 bits of data, we ran that through a hash algorithm ... We could generate slightly over 1 kilobytes of randomness per second ...
    (sci.crypt)