modifying vnd to use twofish and DEBUG

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

modifying vnd to use twofish and DEBUG

Jacob Yocom-Piatt
i've been working on code that would have the twofish block cipher replace
blowfish when using encrypted vnd devices. i've generated source files twf.c and
twf.h where the function names are essentially the same as those in blf.c (make
replacements blf --> twf and Blowfish --> Twofish). i've tested that twf.c does
ECB and CBC operations correctly for 128 and 256 bit keys and am currently
modifying vnd.c to use the twofish functions in place of the usual blowfish ones.

in vnd.c, there are a bunch of debugging statements that start with #ifdef DEBUG
that i would like to turn on. already tried adding "#define DEBUG 1" in vnd.c
and recompiling the kernel to see if this would print info to the console when i
muck about with vnconfig and it doesn't work. what is the correct method for
getting this debugging info?

the only modifications i've made to vnd.c are to change all instances of blf to
twf. i am doing this using 3.9-release sources, here's a diff of the changes

--- vnd_orig.c  Mon Aug 28 14:45:17 2006
+++ vnd.c       Mon Aug 28 13:50:31 2006
@@ -79,7 +79,7 @@
 #include <sys/uio.h>
 #include <sys/conf.h>
 
-#include <crypto/blf.h>
+#include <crypto/twf.h>
 
 #include <miscfs/specfs/specdev.h>
 
@@ -131,7 +131,7 @@
        struct ucred    *sc_cred;               /* credentials */
        int              sc_maxactive;          /* max # of active requests */
        struct buf       sc_tab;                /* transfer queue */
-       blf_ctx         *sc_keyctx;             /* key context */
+       twf_ctx         *sc_keyctx;             /* key context */
 };
 
 /* sc_flags */
@@ -181,11 +181,11 @@
        for (i = 0; i < size/bsize; i++) {
                bzero(iv, sizeof(iv));
                bcopy((u_char *)&off, iv, sizeof(off));
-               blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv));
+               twf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv));
                if (encrypt)
-                       blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize);
+                       twf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize);
                else
-                       blf_cbc_decrypt(vnd->sc_keyctx, iv, addr, bsize);
+                       twf_cbc_decrypt(vnd->sc_keyctx, iv, addr, bsize);
 
                addr += bsize;
                off++;
@@ -856,7 +856,7 @@
 
                        vnd->sc_keyctx = malloc(sizeof(*vnd->sc_keyctx), M_DEVBUF,
                            M_WAITOK);
-                       blf_key(vnd->sc_keyctx, key, vio->vnd_keylen);
+                       twf_key(vnd->sc_keyctx, key, vio->vnd_keylen);
                        bzero(key, vio->vnd_keylen);
                } else
                        vnd->sc_keyctx = NULL;

i have also added twf.c to /usr/src/sys/conf/files:

--- files_orig  Mon Aug 28 14:50:54 2006
+++ files       Sun Aug 27 23:31:52 2006
@@ -765,7 +765,8 @@
 file crypto/rmd160.c                   (inet & ipsec) | crypto
 file crypto/sha1.c                     (inet & ipsec) | crypto | carp
 file crypto/sha2.c                     (inet & ipsec) | crypto
-file crypto/blf.c                      (inet & ipsec) | crypto | vnd
+file crypto/blf.c                      (inet & ipsec) | crypto
+file crypto/twf.c                      vnd
 file crypto/cast.c                     (inet & ipsec) | crypto
 file crypto/skipjack.c                 (inet & ipsec) | crypto
 file crypto/ecb_enc.c                  (inet & ipsec) | crypto


to get the replacement i desire, blowfish with twofish on vnd devices, is it
sufficient to recompile the kernel with the modifications i've mentioned above?
AFAICT, there aren't any mods to vnconfig.c, or other source files, that need to
be made to get this working, although i am likely wrong about this since
vnconfig isn't doing its job right with the modded kernel :P.

cheers,
jake

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Angelos D. Keromytis
Why? If you're going to replace blowfish with something, use AES.

Something else that'd be good, however, is to use the crypto framework
for vnd encryption.
-Angelos

Jacob Yocom-Piatt wrote:

> i've been working on code that would have the twofish block cipher replace
> blowfish when using encrypted vnd devices. i've generated source files twf.c and
> twf.h where the function names are essentially the same as those in blf.c (make
> replacements blf --> twf and Blowfish --> Twofish). i've tested that twf.c does
> ECB and CBC operations correctly for 128 and 256 bit keys and am currently
> modifying vnd.c to use the twofish functions in place of the usual blowfish ones.
>
> in vnd.c, there are a bunch of debugging statements that start with #ifdef DEBUG
> that i would like to turn on. already tried adding "#define DEBUG 1" in vnd.c
> and recompiling the kernel to see if this would print info to the console when i
> muck about with vnconfig and it doesn't work. what is the correct method for
> getting this debugging info?
>
> the only modifications i've made to vnd.c are to change all instances of blf to
> twf. i am doing this using 3.9-release sources, here's a diff of the changes
>
> --- vnd_orig.c  Mon Aug 28 14:45:17 2006
> +++ vnd.c       Mon Aug 28 13:50:31 2006
> @@ -79,7 +79,7 @@
>  #include <sys/uio.h>
>  #include <sys/conf.h>
>  
> -#include <crypto/blf.h>
> +#include <crypto/twf.h>
>  
>  #include <miscfs/specfs/specdev.h>
>  
> @@ -131,7 +131,7 @@
>         struct ucred    *sc_cred;               /* credentials */
>         int              sc_maxactive;          /* max # of active requests */
>         struct buf       sc_tab;                /* transfer queue */
> -       blf_ctx         *sc_keyctx;             /* key context */
> +       twf_ctx         *sc_keyctx;             /* key context */
>  };
>  
>  /* sc_flags */
> @@ -181,11 +181,11 @@
>         for (i = 0; i < size/bsize; i++) {
>                 bzero(iv, sizeof(iv));
>                 bcopy((u_char *)&off, iv, sizeof(off));
> -               blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv));
> +               twf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv));
>                 if (encrypt)
> -                       blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize);
> +                       twf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize);
>                 else
> -                       blf_cbc_decrypt(vnd->sc_keyctx, iv, addr, bsize);
> +                       twf_cbc_decrypt(vnd->sc_keyctx, iv, addr, bsize);
>  
>                 addr += bsize;
>                 off++;
> @@ -856,7 +856,7 @@
>  
>                         vnd->sc_keyctx = malloc(sizeof(*vnd->sc_keyctx), M_DEVBUF,
>                             M_WAITOK);
> -                       blf_key(vnd->sc_keyctx, key, vio->vnd_keylen);
> +                       twf_key(vnd->sc_keyctx, key, vio->vnd_keylen);
>                         bzero(key, vio->vnd_keylen);
>                 } else
>                         vnd->sc_keyctx = NULL;
>
> i have also added twf.c to /usr/src/sys/conf/files:
>
> --- files_orig  Mon Aug 28 14:50:54 2006
> +++ files       Sun Aug 27 23:31:52 2006
> @@ -765,7 +765,8 @@
>  file crypto/rmd160.c                   (inet & ipsec) | crypto
>  file crypto/sha1.c                     (inet & ipsec) | crypto | carp
>  file crypto/sha2.c                     (inet & ipsec) | crypto
> -file crypto/blf.c                      (inet & ipsec) | crypto | vnd
> +file crypto/blf.c                      (inet & ipsec) | crypto
> +file crypto/twf.c                      vnd
>  file crypto/cast.c                     (inet & ipsec) | crypto
>  file crypto/skipjack.c                 (inet & ipsec) | crypto
>  file crypto/ecb_enc.c                  (inet & ipsec) | crypto
>
>
> to get the replacement i desire, blowfish with twofish on vnd devices, is it
> sufficient to recompile the kernel with the modifications i've mentioned above?
> AFAICT, there aren't any mods to vnconfig.c, or other source files, that need to
> be made to get this working, although i am likely wrong about this since
> vnconfig isn't doing its job right with the modded kernel :P.
>
> cheers,
> jake

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Darrin Chandler
On Mon, Aug 28, 2006 at 04:27:35PM -0400, Angelos D. Keromytis wrote:
> Why? If you're going to replace blowfish with something, use AES.

That would be easier, but twofish is pretty nice. It almost *was* AES,
after all.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Jacob Yocom-Piatt
In reply to this post by Jacob Yocom-Piatt
---- Original message ----

>Date: Mon, 28 Aug 2006 17:13:19 -0700
>From: Darrin Chandler <[hidden email]>  
>Subject: Re: modifying vnd to use twofish and DEBUG  
>To: "Angelos D. Keromytis" <[hidden email]>
>Cc: [hidden email], [hidden email]
>
>On Mon, Aug 28, 2006 at 04:27:35PM -0400, Angelos D. Keromytis wrote:
>> Why? If you're going to replace blowfish with something, use AES.
>
>That would be easier, but twofish is pretty nice. It almost *was* AES,
>after all.
>

i cannot help but be extremely skeptical of anything a US agency proclaims as a
standard, even the NIST. as someone puts it on the DES wikipedia page:

"The other criticismbthat the key length was too shortbwas supported by the fact
that the reason given by the NSA for reducing the key length from 64 bits to 56
was that the other 8 bits could serve as parity bits, which seemed somewhat
specious. It was widely believed that NSA's decision was motivated by the
possibility that they would be able to brute force attack a 56 bit key several
years before the rest of the world would."

so forgive my lack of faith in the standard :).

the suggestion of using the crypto framework sounds like a good idea. it would
make for maximal generality in cipher selection.

nobody answered my question about the #ifdef DEBUG. i take it this => it's
really dumb.

cheers,
jake

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Ted Unangst-2
On 8/28/06, Jacob Yocom-Piatt <[hidden email]> wrote:
> "The other criticismbthat the key length was too shortbwas supported by the fact
> that the reason given by the NSA for reducing the key length from 64 bits to 56
> was that the other 8 bits could serve as parity bits, which seemed somewhat
> specious. It was widely believed that NSA's decision was motivated by the
> possibility that they would be able to brute force attack a 56 bit key several
> years before the rest of the world would."
>
> so forgive my lack of faith in the standard :).

well, how long a key does AES support?  besides, twofish was written
by an american team you can't trust, but rijndael came from some
foreigners so you know it's secure. :)

> nobody answered my question about the #ifdef DEBUG. i take it this => it's
> really dumb.

what did you set vnddebug to?

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Mark Reitblatt
In reply to this post by Jacob Yocom-Piatt
On 8/28/06, Jacob Yocom-Piatt <[hidden email]> wrote:

>
> i cannot help but be extremely skeptical of anything a US agency proclaims as a
> standard, even the NIST. as someone puts it on the DES wikipedia page:
>

I'm sorry, but this is beyond paranoid. DES and Rijndael have NOTHING
in common other than the fact that they were certified by the NIST.
DES was developed by IBM, and modified under secretive instruction
from the NSA (which actually strengthened it in the case of the
S-Boxes). Rijndael was developed by academics with NO NSA interference
and submitted to a competition, vetted by the top cryptanalysts in the
world, benchmarked ad nauseum and ended up beating a rather impressive
array of competitors. There is little contest that the best algorithm
won out. Even some of the co-inventors of Twofish have said as much.

> "The other criticismbthat the key length was too shortbwas supported by the fact
> that the reason given by the NSA for reducing the key length from 64 bits to 56
> was that the other 8 bits could serve as parity bits, which seemed somewhat
> specious. It was widely believed that NSA's decision was motivated by the
> possibility that they would be able to brute force attack a 56 bit key several
> years before the rest of the world would."

Nothing to do with Rijndael. Rijndel's available key-lengths are
widely accepted. Don't feel good about 128 bit keys for some reason?
Just use 192 or 256. The same could not be said of DES when it came
out.

>
> so forgive my lack of faith in the standard :).
>

Sorry, but these are not reasonable objections to AES. Questioning
it's unique algebraic structure is. Even pointing to the XSL (oy vey!)
attack is somewhat reasonable. Maybe even point to the side-channel
timing attacks that are all the rage these days. Simply mistrusting
the fact that the NIST said it is good isn't. There has been no lack
of public inspection of AES. Au contraire, Twofish has received far
less scrutiny, and as such, faith in its security is more
questionable. I'm not saying it isn't a good algorithm, I'm personally
partial to it (my number theory professor was a co-inventor).

--
Clothes make the man. Naked people have little or no influence in
society -- Mark Twain

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Girish Venkatachalam-2
In reply to this post by Angelos D. Keromytis
On 8/29/06, Angelos D. Keromytis <[hidden email]> wrote:
> Why? If you're going to replace blowfish with something, use AES.

I would like to second Angelos here since I have seen the algorithmic
properties of Rijndael and I am really very pleased with the
simplicity with which they have achieved security.

In fact as someone said AES has absolutely *nothing* whatsoever to do
with DES. DES is one of the lousiest algos out there that too with its
weak keys, S boxes and other secret nonsense thrown in.

OTOH, AES is so elegant, simple and secure. Remember that in security,
the more simple to understand something is, the better is the analysis
possible, easier it is to see its dark corners and vulnerabilities and
consequently we can make a reasonable guess about its security
properties.

I admit that I have absolutely no idea about Twofish and just
supporting twofish because it was an AES contender and that Bruce
Schneier developed it looks a little stupid to me.

My two cents.

regards,
Girish

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Darrin Chandler
In reply to this post by Jacob Yocom-Piatt
On Mon, Aug 28, 2006 at 08:48:31PM -0500, Jacob Yocom-Piatt wrote:

> ---- Original message ----
> >Date: Mon, 28 Aug 2006 17:13:19 -0700
> >From: Darrin Chandler <[hidden email]>  
> >Subject: Re: modifying vnd to use twofish and DEBUG  
> >To: "Angelos D. Keromytis" <[hidden email]>
> >Cc: [hidden email], [hidden email]
> >
> >On Mon, Aug 28, 2006 at 04:27:35PM -0400, Angelos D. Keromytis wrote:
> >> Why? If you're going to replace blowfish with something, use AES.
> >
> >That would be easier, but twofish is pretty nice. It almost *was* AES,
> >after all.
> >
>
> i cannot help but be extremely skeptical of anything a US agency proclaims as a
> standard, even the NIST. as someone puts it on the DES wikipedia page:

<snip>

Remember that DES had a long run under a *huge* amount of scrutiny from
all sides. I don't know that AES will live that long. Twofish is nice,
and it's fast. US agencies have their own agendas, but the crypto seems
pretty sound.

> the suggestion of using the crypto framework sounds like a good idea. it would
> make for maximal generality in cipher selection.

Makes a lot of sense.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Jacob Yocom-Piatt
In reply to this post by Jacob Yocom-Piatt
---- Original message ----
>Date: Tue, 29 Aug 2006 08:22:42 +0530
>From: "Girish Venkatachalam" <[hidden email]>  
>Subject: Re: modifying vnd to use twofish and DEBUG  
>To: "Angelos D. Keromytis" <[hidden email]>
>Cc: [hidden email], [hidden email]
>
>On 8/29/06, Angelos D. Keromytis <[hidden email]> wrote:
>> Why? If you're going to replace blowfish with something, use AES.

...

>
>OTOH, AES is so elegant, simple and secure. Remember that in security,
>the more simple to understand something is, the better is the analysis
>possible, easier it is to see its dark corners and vulnerabilities and
>consequently we can make a reasonable guess about its security
>properties.
>
>I admit that I have absolutely no idea about Twofish and just
>supporting twofish because it was an AES contender and that Bruce
>Schneier developed it looks a little stupid to me.
>

girish,

well, i can't un-code what i wrote, it's already done. AFAICT, it's ready to
roll and the work that remains to be done is hooking it into vnd.

angelo's suggestion of using the existing crypto framework (CF) to allow for
cipher selection amongst the ciphers that are already supported by CF is a much
better idea than what i originally suggested. not to mention a nice plug for his
code, ;).

cheers,
jake

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Damien Miller
On Tue, 29 Aug 2006, Jacob Yocom-Piatt wrote:

> angelo's suggestion of using the existing crypto framework (CF) to
> allow for cipher selection amongst the ciphers that are already
> supported by CF is a much better idea than what i originally
> suggested. not to mention a nice plug for his code, ;).

Better than being a nice idea, using the crypto framework would
allow hardware accelleration of crypto vnd mounts. On the Via CPUs
that support the crypto instruction set, crypto would add no noticable
overhead...

-d

Reply | Threaded
Open this post in threaded view
|

Re: modifying vnd to use twofish and DEBUG

Dries Schellekens
In reply to this post by Mark Reitblatt
Mark Reitblatt wrote:

> Sorry, but these are not reasonable objections to AES. Questioning
> it's unique algebraic structure is. Even pointing to the XSL (oy vey!)
> attack is somewhat reasonable. Maybe even point to the side-channel
> timing attacks that are all the rage these days.

To quote Vincent Rijmen: "XSL is a dream." Algebraic attacks work on
some stream cipher, but only a few hardheaded researcher claim it can
brake Rijndael.

 > Simply mistrusting the fact that the NIST said it is good isn't.
> There has been no lack of public inspection of AES. Au contraire,
 > Twofish has received far less scrutiny, and as such, faith in its
 > security is more questionable. I'm not saying it isn't a good
> algorithm, I'm personally partial to it (my number theory professor
 > was a co-inventor).

Since Rijndael got elected to as AES, all research about block ciphers
has focussed on Rijndael. Hardly any new proposals for block ciphers are
made and new attack are rare. Many researchers have given up and shifted
attention to stream cipher design and cryptanalysis and hash functions.
Block ciphers are a done deal. If you want to use a block cipher, use AES.


All very off topic of course.


Cheers,

Dries