bram (bram@gawth.com)
Fri, 8 May 1998 10:55:42 -0700 (PDT)
On Fri, 8 May 1998 mgraffam@mhv.net wrote:
> On Thu, 7 May 1998, Mark Rosen wrote:
> > There are also many security improvements that can be made. I have
> > pasted the appropriate source code below, but here are my observations: The
> > main point of attack is the RNG. I use a simple LFSR.
>
> If you have SHA1 available, why not make a random number generated based
> on that?
Sha1 wasn't designed to be used as a random number generator, and hence is
less than ideal when used in that way. It is, however, vastly better than
LFSR, which should be considered worthless for cryptographic applications.
> > The message is divided up into 1 byte packets. As
> > per Rivest's document, an authentication key is computed using the hash
> > (SHA1) of the packet and an authentication key. I don't use a serial number
> > because the packets are stored in order (the architecture of my encryption
> > library prevents me from storing the packets in random order, though this is
> > certainly a possible improvement).
>
> So you have:
>
> byte+phrase where + is concatencation, and this is hashed?
>
> I don't like it.. could be bad.. and here's why:
I think hashing byte+passphrase+packetNumber+initializationVector would
fix that, with the initialization vector passed plaintext at the
beginning.
I'm a little bit queasy with this general use of hashing functions - known
plaintext attacker is given a ton of hashes and is told that certain bits
of the hashed messages are all the same, and to crack the code only has to
deduce those bits. This is an attack which hashing functions aren't
designed to withstand. And remember that Sha1 came from the NSA - I doubt
the NSA publishes weak algorithms, but I wouldn't be surprised if they
publish ones which are very weak when used for tasks they werent specified
for. The NSA plays a civilized game.
-Bram
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:18 ADT