[PATCH] IPsec: add support for Twofish and Serpent

[PATCH] IPsec: add support for Twofish and Serpent

[Kyle McMartin]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]


This patch adds support for the use of twofish and serpent as
ESP algorithms. The ESP index numbers given are in accordance
with RFC2407, draft-ietf-ipsec-ciph-aes-cbc-00 (before Rijndael
was selected), and KAME which assigns 253 to twofishcbc.

Support for using twofish was requested on linux-kernel, and
since I noticed serpent was missing too, included that as well.

Regards,
-- 
Kyle McMartin <kyle@debian.org>
1024D/191FCD8A - 331A 9468 C04D 3A76 5C56  BA68 7EB7 92DF 191F CD8A
2048R/F515317D -   68 A9 0D 28 1B DF 8D 42  0F CC AF 98 A8 D5 A4 04

[-- Attachment #2: pfkeyv2.diff --]
[-- Type: text/plain, Size: 660 bytes --]

--- linux-2.6.0-test3-mm2/include/linux/pfkeyv2.h.old	2003-08-14 10:11:32.000000000 -0400
+++ linux-2.6.0-test3-mm2/include/linux/pfkeyv2.h	2003-08-14 11:30:46.000000000 -0400
@@ -284,7 +284,10 @@
 #define SADB_X_EALG_BLOWFISHCBC		7
 #define SADB_EALG_NULL			11
 #define SADB_X_EALG_AESCBC		12
-#define SADB_EALG_MAX			12
+#define SADB_EALG_MAX                   253 /* last EALG */
+/* private allocations should use 249-255 (RFC2407) */
+#define SADB_X_EALG_SERPENTCBC  252     /* draft-ietf-ipsec-ciph-aes-cbc-00 */
+#define SADB_X_EALG_TWOFISHCBC  253     /* draft-ietf-ipsec-ciph-aes-cbc-00 */
 
 /* Compression algorithms */
 #define SADB_X_CALG_NONE		0

[-- Attachment #3: xfrm_algo.diff --]
[-- Type: text/plain, Size: 1118 bytes --]

--- linux-2.6.0-test3-mm2/net/xfrm/xfrm_algo.c.old	2003-08-14 10:15:04.000000000 -0400
+++ linux-2.6.0-test3-mm2/net/xfrm/xfrm_algo.c	2003-08-14 11:06:20.000000000 -0400
@@ -217,6 +217,40 @@
 		.sadb_alg_maxbits = 256
 	}
 },
+{
+        .name = "serpent",
+
+        .uinfo = {
+                .encr = {
+                        .blockbits = 128,
+                        .defkeybits = 128,
+                }
+        },
+
+        .desc = {
+                .sadb_alg_id = SADB_X_EALG_SERPENTCBC,
+                .sadb_alg_ivlen = 8,
+                .sadb_alg_minbits = 128,
+                .sadb_alg_maxbits = 256,
+        }
+},
+{
+        .name = "twofish",
+                 
+        .uinfo = {
+                .encr = {
+                        .blockbits = 128,
+                        .defkeybits = 128,
+                }
+        },
+
+        .desc = {
+                .sadb_alg_id = SADB_X_EALG_TWOFISHCBC,
+                .sadb_alg_ivlen = 8,
+                .sadb_alg_minbits = 128,
+                .sadb_alg_maxbits = 256
+        }
+},
 };
 
 static struct xfrm_algo_desc calg_list[] = {

Re: [PATCH] IPsec: add support for Twofish and Serpent

[Pekka Pietikainen]

On Thu, Aug 14, 2003 at 12:48:19PM -0400, Kyle McMartin wrote:
> 
> This patch adds support for the use of twofish and serpent as
> ESP algorithms. The ESP index numbers given are in accordance
> with RFC2407, draft-ietf-ipsec-ciph-aes-cbc-00 (before Rijndael
> was selected), and KAME which assigns 253 to twofishcbc.

> Support for using twofish was requested on linux-kernel, and
> since I noticed serpent was missing too, included that as well.
Hi

Nothing against twofish or serpent per se, but I have this feeling that 
supporting every possible crypto algoritm known to man
is not necessarily wise (see eg. Practical Cryptography for the rationale).

There's absolutely no need to add complexity unless there are some technical
arguments for doing so, say compatibility with legacy implementations
which justifies bothering with DES/3DES/MD5 although they're inferior to 
AES and SHA1 in just about every aspect.

-- 
Pekka Pietikainen

Re: [PATCH] IPsec: add support for Twofish and Serpent

[Pekka Savola]

On Thu, 14 Aug 2003, Pekka Pietikainen wrote:
> On Thu, Aug 14, 2003 at 12:48:19PM -0400, Kyle McMartin wrote:
> > 
> > This patch adds support for the use of twofish and serpent as
> > ESP algorithms. The ESP index numbers given are in accordance
> > with RFC2407, draft-ietf-ipsec-ciph-aes-cbc-00 (before Rijndael
> > was selected), and KAME which assigns 253 to twofishcbc.
> 
> > Support for using twofish was requested on linux-kernel, and
> > since I noticed serpent was missing too, included that as well.
> Hi
> 
> Nothing against twofish or serpent per se, but I have this feeling that 
> supporting every possible crypto algoritm known to man
> is not necessarily wise (see eg. Practical Cryptography for the rationale).
> 
> There's absolutely no need to add complexity unless there are some technical
> arguments for doing so, say compatibility with legacy implementations
> which justifies bothering with DES/3DES/MD5 although they're inferior to 
> AES and SHA1 in just about every aspect.

Very much agree.

Also, I could be missing something, but I think it takes much more to add 
an encryption algorithm than what the patch does?!?!

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH] IPsec: add support for Twofish and Serpent

[David S. Miller]

On Thu, 14 Aug 2003 23:25:11 +0300 (EEST)
Pekka Savola <pekkas@netcore.fi> wrote:

> Very much agree.

I totally disagree, choice is everything.

That's why we allow NULL crypto algorithms.  Not doing
so turns this into a political thing, which I decidedly
do not want our IPSEC implementation to be all about.

And therefore I will add the patch.

> Also, I could be missing something, but I think it takes much more to add 
> an encryption algorithm than what the patch does?!?!

If you use the netlink based IPSEC implementation, any crypto
algorithm is supported fully the moment it is added to crypto/.

When using pfkeyv2 sockets, yes you have to assign a number and then
the APP has to be aware of it.  This just shows how bogus it is to use
fixed numbers instead of strings to select crypto algorithms.

Re: [PATCH] IPsec: add support for Twofish and Serpent

[Kyle McMartin]

On Thu, Aug 14, 2003 at 07:12:59PM -0700, David S. Miller wrote:
> I totally disagree, choice is everything.
> 
> That's why we allow NULL crypto algorithms.  Not doing
> so turns this into a political thing, which I decidedly
> do not want our IPSEC implementation to be all about.
>
> And therefore I will add the patch.
>
Thank you, David. I completely agree with allowing users to choose
which algorithms they wish to deploy. 
 
> When using pfkeyv2 sockets, yes you have to assign a number and then
> the APP has to be aware of it.  This just shows how bogus it is to use
> fixed numbers instead of strings to select crypto algorithms.
>
Again, I agree. Especially given the limitations of using the
private ESP id space, since there is no new RFC delegating
additions yet.

Regards,
-- 
Kyle McMartin <kyle@debian.org>
1024D/191FCD8A - 331A 9468 C04D 3A76 5C56  BA68 7EB7 92DF 191F CD8A
2048R/F515317D -   68 A9 0D 28 1B DF 8D 42  0F CC AF 98 A8 D5 A4 04

Re: [PATCH] IPsec: add support for Twofish and Serpent

[Kyle McMartin]

On Thu, Aug 14, 2003 at 11:25:11PM +0300, Pekka Savola wrote:
> Very much agree.
> 
> Also, I could be missing something, but I think it takes much more to add 
> an encryption algorithm than what the patch does?!?!
> 
The algorithms were already part of the CryptoAPI. All the
patch did was simply make them accessible to IPsec, by adding
numerical IDs for ESP.

Regards,
-- 
Kyle McMartin <kyle@debian.org>
1024D/191FCD8A - 331A 9468 C04D 3A76 5C56  BA68 7EB7 92DF 191F CD8A
2048R/F515317D -   68 A9 0D 28 1B DF 8D 42  0F CC AF 98 A8 D5 A4 04

Re: [PATCH] IPsec: add support for Twofish and Serpent

[Kyle McMartin]

On Thu, Aug 14, 2003 at 09:08:57PM +0300, Pekka Pietikainen wrote:
> There's absolutely no need to add complexity unless there are some technical
> arguments for doing so, say compatibility with legacy implementations
> which justifies bothering with DES/3DES/MD5 although they're inferior to 
> AES and SHA1 in just about every aspect.
> 
There are simple technical arguments for doing so, SERPENT and Twofish
are both either as secure, or more secure than rijndael, as it stood with
the amount of cryptanalysis the three received as part of the AES
selection process. (Serpent, as it stood, was more secure, since it had
more rounds, and more proven sboxes).

Adding more *secure* algorithms does no harm.

Regards,
-- 
Kyle McMartin <kyle@debian.org>
1024D/191FCD8A - 331A 9468 C04D 3A76 5C56  BA68 7EB7 92DF 191F CD8A
2048R/F515317D -   68 A9 0D 28 1B DF 8D 42  0F CC AF 98 A8 D5 A4 04