[prev in list] [next in list] [prev in thread] [next in thread] 

List:       botan-devel
Subject:    [Botan-devel] Re: Key generation for SEAL stream cipher
From:       lloyd () randombit ! net (Jack Lloyd)
Date:       2005-10-11 20:26:18
Message-ID: 20051011202618.GP28646 () randombit ! net
[Download RAW message or body]


That is a good point - I don't know how much analysis has been done of
WiderWAKE either. I believe the original paper showed some good results for
security, though IIRC the primary reason for the WiderWAKE design was better
performance rather than better security.

There are a number of newer stream ciphers that support the features you're
looking for, like Turing, Snow, Helix, and Lili-128, but as far as I know none
of them has been given much analysis yet, which is one of the reasons they
haven't been implemented in Botan yet (I think it's probably been at least a
year or two since I added any primitive algorithms to Botan, actually). So that
may be something to look into again, to expand the current options for users
who need 100 Mbyte+/sec encryption rates.

-Jack

On Tue, Oct 11, 2005 at 04:10:37PM -0400, Carlton Davis wrote:
> Thanks Jack for your response. It was very helpful.
> My concern about WiderWake4+1 is that it has not been
> given much  scrutiny, and considering that it is
> based on a similar design principle as Wake, which
> is known to be susceptible to chosen plaintext and chosen
> ciphertext attacks, I am wondering how secure it is.
> 
> In any case, the patent issue with SEAL might be a problem.
> Thanks for bringing this to my attention.
> I will likely need to consider using WiderWake4+1 or
> another stream cipher.
> 
> 
> Best regards,
> 
> -Carlton
> 
> > Date: Mon, 10 Oct 2005 19:01:02 -0400 (EDT)
> > From: Carlton Davis <carlton at cs.mcgill.ca>
> > Subject: [Botan-devel] Key generation for SEAL stream cipher
> > To: botan-devel at randombit.net
> > Message-ID: <20051010184506.N57218 at axon.CS.McGill.CA>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > I would like to use SEAL stream cipher in a secure MANET routing
> > protocol. Ideally, I would like to generate the symmetric keys for SEAL
> > using a pre-shared secret and a non-secret value (for example a packet's
> > sequence number); such that a pair of nodes which share a secret value
> > can generate the same encryption/decryption key using the shared secret
> > and a packet's sequence number. Does Botan provides this functionality?
> > If so what routines can I use to do this?
> >
> > Thanks much and best regards,
> >
> > -Carlton
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Mon, 10 Oct 2005 19:50:27 -0400
> > From: Jack Lloyd <lloyd at randombit.net>
> > Subject: Re: [Botan-devel] Key generation for SEAL stream cipher
> > To: botan-devel at randombit.net
> > Message-ID: <20051010235027.GJ28646 at randombit.net>
> > Content-Type: text/plain; charset=us-ascii
> >
> >
> > SEAL has the ability to seek within the cipher stream, at least to a limited
> > degree. The member function is seek(u32bit where); basically, a call of
> > seal_obj->seek(N) puts SEAL at the Nth byte of the cipherstream which is
> > defined by whatever key you set. So you can use the packet number to index into
> > a single cipherstream (up to 4 gigabytes of one, at least); just make sure none
> > of your packets overlap. One way to do this, if you know the maximum packet
> > size you will encrypt is N, is to encrypt each packet by seeking to
> > seq_number*N, which ensures that you never use any keystream twice.
> >
> > An alternate method is to use different keys each time, with each packet being
> > encrypted with a key equal to SHA(seq_number || master_key), or something like
> > that. However, SEAL's key schedule is very expensive computationally speaking,
> > so that wouldn't work too well.
> >
> > Unless you are tied to SEAL, I would recommend looking at
> WiderWake4+1. For
> > one, SEAL is patented by IBM, and AFAIK you may need to acquire a patent
> > license for certain uses of it within the United States. Also, WiderWake4+1 is
> > usually either as fast or faster than SEAL, depending on the platform/compiler,
> > and it supports a fast resync operation that takes a 64-bit input. That also
> > means you don't have to worry about overlapping keystreams, etc, as the way
> > WiderWAKE does it, the keystream generated by some IV has no (distinguishable)
> > relationship with a keystream generated using IV+1.
> >
> > Hope this helps.
> >
> > Jack
> >
> > On Mon, Oct 10, 2005 at 07:01:02PM -0400, Carlton Davis wrote:
> > > I would like to use SEAL stream cipher in a secure MANET routing
> > > protocol. Ideally, I would like to generate the symmetric keys for SEAL
> > > using a pre-shared secret and a non-secret value (for example a packet's
> > > sequence number); such that a pair of nodes which share a secret value
> > > can generate the same encryption/decryption key using the shared secret
> > > and a packet's sequence number. Does Botan provides this functionality?
> > > If so what routines can I use to do this?
> > >
> > > Thanks much and best regards,
> > >
> > > -Carlton
> > > _______________________________________________
> > > botan-devel mailing list
> > > botan-devel at randombit.net
> > > http://www.randombit.net/mailman/listinfo/botan-devel
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > botan-devel mailing list
> > botan-devel at randombit.net
> > http://www.randombit.net/mailman/listinfo/botan-devel
> >
> >
> > End of botan-devel Digest, Vol 11, Issue 4
> > ******************************************
> >
> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://www.randombit.net/mailman/listinfo/botan-devel


[prev in list] [next in list] [prev in thread] [next in thread]