Aaron D. Gifford (agifford@infowest.com)
Fri, 08 May 1998 20:13:00 +0000
bram wrote:
>
> 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
Hey, I like that! In a stream where order of packets is guaranteed, a serial
number or packet number can be implied by the order they arrive in. Why
didn't I think of that? ;)
As per my previous messge with this subject, using an implied serial number
and a 1-bit unpacketed chaffing system, bloat would be reduced from 400 bytes
per payload byte to 336 bytes per payload byte (21-byte packet length * 16
packets), and with a packed system, bloat decreases from 386 to 322 (161 bit
packet length * 16 packets). 322 bytes per payload byte is MUCH better than
the 441 bytes per payload byte.
Aaron out.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:18 ADT