I have been reading IP Encapsulating Payload-(ESP) RFC4303 where use of
combined mode algorithms are mentioned and accommodated for.
In trying to determine how I should handle this, I examined the
crypto code and could not readily recognize any combined mode
algorithms. Are there any current plans to implement combined mode
algorithms?
Thanks!
Regards,
Joy
On Mon, Jun 25, 2007 at 05:13:58PM -0500, Joy Latten ([email protected]) wrote:
> I have been reading IP Encapsulating Payload-(ESP) RFC4303 where use of
> combined mode algorithms are mentioned and accommodated for.
> In trying to determine how I should handle this, I examined the
> crypto code and could not readily recognize any combined mode
> algorithms. Are there any current plans to implement combined mode
> algorithms?
I think it should be first supported by ipsec stack at least with state,
where SA cold be configured, integrity check for the data/header is not
a problem after that changes are stable. sha1/encryption is a poor man's
combined algo after all with hash data being ICV :)
--
Evgeniy Polyakov
On Tue, 2007-06-26 at 13:09 +0400, Evgeniy Polyakov wrote:
> On Mon, Jun 25, 2007 at 05:13:58PM -0500, Joy Latten ([email protected]) wrote:
> > I have been reading IP Encapsulating Payload-(ESP) RFC4303 where use of
> > combined mode algorithms are mentioned and accommodated for.
> > In trying to determine how I should handle this, I examined the
> > crypto code and could not readily recognize any combined mode
> > algorithms. Are there any current plans to implement combined mode
> > algorithms?
>
> I think it should be first supported by ipsec stack at least with state,
> where SA cold be configured, integrity check for the data/header is not
> a problem after that changes are stable. sha1/encryption is a poor man's
> combined algo after all with hash data being ICV :)
>
Ok, thanks. This helps. I can code up the infrastructure for this. I
am thinking I will eventually need one of the algorithms to test and
complete it though. RFCs 4309 and 4106 specify ESP working with AES-CCM
and AES-GCM.
Regards,
Joy
On Tue, Jun 26, 2007 at 10:02:36AM -0500, Joy Latten wrote:
>
> Ok, thanks. This helps. I can code up the infrastructure for this. I
> am thinking I will eventually need one of the algorithms to test and
> complete it though. RFCs 4309 and 4106 specify ESP working with AES-CCM
> and AES-GCM.
Any progress on this Joy?
I'm about to start working on this myself in the next couple of
days.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, 2007-07-18 at 12:46 +0800, Herbert Xu wrote:
> On Tue, Jun 26, 2007 at 10:02:36AM -0500, Joy Latten wrote:
> >
> > Ok, thanks. This helps. I can code up the infrastructure for this. I
> > am thinking I will eventually need one of the algorithms to test and
> > complete it though. RFCs 4309 and 4106 specify ESP working with AES-CCM
> > and AES-GCM.
>
> Any progress on this Joy?
>
> I'm about to start working on this myself in the next couple of
> days.
>
Great! I have been distracted with some other things, but will also
start this in the next day or two.
Regards,
Joy
>
>The salt will just come from the key field. So instead of having
>an 128-bit key for example, you'd have 152 bits.
ok, quick question, this 152 bits key will be part
of input to setkey()?
The reason I am asking is because setkey in ablkcipher and
blkcipher check key length for min and max size.
Thus for example, aes, when using a 256 bit key, would
pass in 288 bits or 36 octet key. max is 32 bits, so would
result in error.
If not passed into setkey, then I assume the salt/nonce
would be parsed from key when ipsec daemon passes keys
into kernel...
Joy
Joy Latten <[email protected]> wrote:
>>
>>The salt will just come from the key field. So instead of having
>>an 128-bit key for example, you'd have 152 bits.
>
> ok, quick question, this 152 bits key will be part
> of input to setkey()?
Yes.
> The reason I am asking is because setkey in ablkcipher and
> blkcipher check key length for min and max size.
> Thus for example, aes, when using a 256 bit key, would
> pass in 288 bits or 36 octet key. max is 32 bits, so would
> result in error.
No AES or blkcipher will never see the longer key. The key
will be broken up by the CCM template (yet to be written)
and part of it goes to AES while the other part gets used
as the nonce.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt