Thread: [Vtun-devel] BF_ecb_encrypt vs. BF_cbc_encrypt
Status: Inactive
Brought to you by:
mtbishop
Menu
▾
▴
vtun-devel
|
From: James Y. <ji...@nt...> - 2002-01-09 06:11:12
Attachments:
vtun-cbc.patch
|
Given that we're talking about 2.5.0, I'd like to throw out a concern about vtun's chosen encryption algorithm, BF_ecb_encrypt. My problem with this algorithm is that it is basically a stright substitution cipher on 8-octet blocks, carrying forward no state information as a stream cipher would do, and therefore making it vulnerable to certain kinds of attacks. I would like to see vtun use a cipher that is more stream-like such as BF_cbc_encrypt. I've attached a patch that does just that. It affects only a few lines in lfd_encrypt.c. My testing indicates that speed differences are negligible. I would like to propose that it be included in 2.5.0 as an option. If there is interest in inclusion in 2.5.0, I will recode it to be either a compile-time switch or a config-file option, and disabled by default so as to not break compatibility. Thanks, James Yonan Boulder, Colorado, USA |
|
From: bishop <bi...@pl...> - 2002-01-09 08:10:22
|
James, Are you thinking a global config option or an option in a particular connection profile? I think that we should wait on it, too. I'd like to, if I may, concentrate on a stable 2.5.0 before adding anything else in. I know that this can make things a bit less secure for those who're using the 2.5.0, but it's nothing that's not been around for a while now. What I think we should do for the 2.5.0 is just the packaging stuff, as the impact is very small. I've been listening to a little voice telling me No New Code, and it's making me rethink the attraction of Leo's keepalive_reuse patch. As soon as Leo gets active again, I'll ask him to add in the debian and RH/COL packaging bits, to mark that there as 2.5, and open up 2.5.1 for patches. I'm expecting a very short window between 2.5 and 2.5 1, but I'd like to get that all marked. I've not heard any objections, either, but that was before I suggested not having Leo's patch in there. I'd like a yea or nay on this plan: 2.5.0: ---- - debian packaging mods - rh/col packaging mods 2.5.1 ---- - Leo's Patch - James' crypto patch 2.5.2 ----- - much new things. Much talk. Much time (a month or more, even!) That's what I'm thinking, and unless I get Dictatorial Privilege, I need some assurance that I'm not stepping on toes in these new shoes I'm filling. - bish James Yonan wrote: >Given that we're talking about 2.5.0, I'd like to throw out a concern about >vtun's chosen encryption algorithm, BF_ecb_encrypt. My problem with this >algorithm is that it is basically a stright substitution cipher on 8-octet >blocks, carrying forward no state information as a stream cipher would do, >and therefore making it vulnerable to certain kinds of attacks. I would >like to see vtun use a cipher that is more stream-like such as >BF_cbc_encrypt. > >I've attached a patch that does just that. It affects only a few lines in >lfd_encrypt.c. My testing indicates that speed differences are negligible. >I would like to propose that it be included in 2.5.0 as an option. > >If there is interest in inclusion in 2.5.0, I will recode it to be either a >compile-time switch or a config-file option, and disabled by default so as >to not break compatibility. > >Thanks, > >James Yonan >Boulder, Colorado, USA > |
|
From: Janne J. <jan...@bi...> - 2002-01-09 08:23:48
|
> Are you thinking a global config option or an option in a particular=20 > connection profile? >=20 > I think that we should wait on it, too. I'd like to, if I may,=20 > concentrate on a stable 2.5.0 before adding anything else in. I know=20 > that this can make things a bit less secure for those who're using the=20 > 2.5.0, but it's nothing that's not been around for a while now. I'm a bit of a lurker here, but I looked at the patch, and it doesn't seem to be very dangerous, as far as stability goes. The concerns he has on using ecb are valid, it makes vtun far more vulnerable, when it doesn't have to be like that. Also, if you start it out as a #ifdef/configure-option then the impact for other users should be minimal whereas those, like me, that doesn't like ecb as it is now can go for more secure connections as soon as possible. Then for later versions, you can add code to let the vtun.conf select which version to use. My .02 euros. |
|
From: James Y. <ji...@nt...> - 2002-01-09 11:07:53
|
> Are you thinking a global config option or an option in a particular
> connection profile?
It could certainly be either of those choices or simply an #ifdef, though
probably a connection profile option would make the most sense. Something
such as:
default {
type tun;
proto udp;
cbc_encrypt yes;
}
As far as stability is concerned, I have been running this patch for almost
a year without any problems or noticable performance degradation. I think
the small footprint of the patch and the fact that it will be disabled by
default makes it a pretty safe bet, even for a stable release.
Though personally I'm in no hurry to see it integrated (it takes me about 5
seconds to apply the patch to any new release of vtun), I thought it might
be useful to others.
James Yonan
>
> I think that we should wait on it, too. I'd like to, if I may,
> concentrate on a stable 2.5.0 before adding anything else in. I know
> that this can make things a bit less secure for those who're using the
> 2.5.0, but it's nothing that's not been around for a while now.
>
> What I think we should do for the 2.5.0 is just the packaging stuff, as
> the impact is very small. I've been listening to a little voice telling
> me No New Code, and it's making me rethink the attraction of Leo's
> keepalive_reuse patch.
>
> As soon as Leo gets active again, I'll ask him to add in the debian and
> RH/COL packaging bits, to mark that there as 2.5, and open up 2.5.1 for
> patches. I'm expecting a very short window between 2.5 and 2.5 1, but
> I'd like to get that all marked.
>
> I've not heard any objections, either, but that was before I suggested
> not having Leo's patch in there. I'd like a yea or nay on this plan:
>
> 2.5.0:
> ----
> - debian packaging mods
> - rh/col packaging mods
>
> 2.5.1
> ----
> - Leo's Patch
> - James' crypto patch
>
> 2.5.2
> -----
> - much new things. Much talk. Much time (a month or more, even!)
>
> That's what I'm thinking, and unless I get Dictatorial Privilege, I need
> some assurance that I'm not stepping on toes in these new shoes I'm
filling.
>
> - bish
>
> James Yonan wrote:
>
> >Given that we're talking about 2.5.0, I'd like to throw out a concern
about
> >vtun's chosen encryption algorithm, BF_ecb_encrypt. My problem with this
> >algorithm is that it is basically a stright substitution cipher on
8-octet
> >blocks, carrying forward no state information as a stream cipher would
do,
> >and therefore making it vulnerable to certain kinds of attacks. I would
> >like to see vtun use a cipher that is more stream-like such as
> >BF_cbc_encrypt.
> >
> >I've attached a patch that does just that. It affects only a few lines
in
> >lfd_encrypt.c. My testing indicates that speed differences are
negligible.
> >I would like to propose that it be included in 2.5.0 as an option.
> >
> >If there is interest in inclusion in 2.5.0, I will recode it to be either
a
> >compile-time switch or a config-file option, and disabled by default so
as
> >to not break compatibility.
> >
> >Thanks,
> >
> >James Yonan
> >Boulder, Colorado, USA
> >
>
>
|
|
From: Michael T. <mj...@tl...> - 2002-01-09 11:50:59
|
James Yonan wrote:
>
> > Are you thinking a global config option or an option in a particular
> > connection profile?
>
> It could certainly be either of those choices or simply an #ifdef, though
> probably a connection profile option would make the most sense. Something
> such as:
>
> default {
> type tun;
> proto udp;
> cbc_encrypt yes;
> }
I think vtund should have more general way to specify such a things --
think of e.g. ssh. It may be e.g. `encrypt blowfish' vs `encrypt blowfish_cbc'
(just an example of config *syntax*). The point is important -- once
config changes are made, the syntax should be supported in next versions,
so this sort of things should be done right from the beginning.
Regards,
Michael.
|
|
From: Maksim K. <ma...@qu...> - 2002-01-09 21:16:25
|
Hey Michael, Where is your SF.net id ??? You were supposed to be on the very first core team. Or may be you're too lazy to register there ;-) >> default { >> type tun; >> proto udp; >> cbc_encrypt yes; >> } > >I think vtund should have more general way to specify such a things -- >think of e.g. ssh. It may be e.g. `encrypt blowfish' vs `encrypt blowfish_cbc' >(just an example of config *syntax*). The point is important -- once >config changes are made, the syntax should be supported in next versions, >so this sort of things should be done right from the beginning. Exactly. It should be: encrypt yes; # default encryption (ie ecb) encrypt cbc; # cbc encryption etc, etc, just like we have: compress lzo; compress zlib; Max |
|
From: Maksim K. <ma...@qu...> - 2002-01-09 21:06:20
|
Hey Guys, First, from now on please treat all my comments as *suggestions* and *advices* not as commands and orders :). I think we should keep versioning scheme for 2.x release. ie final release should be 2.5 not 2.5.0. In 3.x it's fine to do 3.x.x but in 2.x it kinda confuses users isn't it. But obviously not a big deal. >Are you thinking a global config option or an option in a particular connection profile ? It should definitely be per connection thing. >I think that we should wait on it, too. I'd like to, if I may, concentrate on a stable 2.5.0 before adding anything else in. I know that this can make things >a bit less secure for those who're using the 2.5.0, but it's nothing that's not been around for a while now. Good point. >I've not heard any objections, either, but that was before I suggested not having Leo's patch in there. I'd like a yea or nay on this plan: > >2.5.0: >---- >- debian packaging mods >- rh/col packaging mods > >2.5.1 >---- >- Leo's Patch >- James' crypto patch > >2.5.2 >----- >- much new things. Much talk. Much time (a month or more, even!) Looks ok. But I'd go with 2.5, 2.6, 2.7, etc. Max |
|
From: Maksim K. <ma...@qu...> - 2002-01-09 21:08:29
|
>I'm a bit of a lurker here, but I looked at the patch, and it doesn't >seem to be very dangerous, as far as stability goes. >The concerns he has on using ecb are valid, it makes vtun >far more vulnerable, when it doesn't have to be like that. Does cbc patch support UDP with packet loss though ? If I remember correctly there are some sync issues. >Also, if you start it out as a #ifdef/configure-option then the >impact for other users should be minimal whereas those, like me, >that doesn't like ecb as it is now can go for more secure connections >as soon as possible. Ifdefs is not a good solution. VTun already has modules so just a new lfd_cbc.c or something and new encrypt config option would be much better. If cbc requires more then that it should be 3.x thing. Max |
|
From: Janne J. <jan...@bi...> - 2002-01-10 08:41:06
|
On Wed, 2002-01-09 at 22:08, Maksim Krasnyanskiy wrote: >=20 > >I'm a bit of a lurker here, but I looked at the patch, and it doesn't > >seem to be very dangerous, as far as stability goes. > >The concerns he has on using ecb are valid, it makes vtun > >far more vulnerable, when it doesn't have to be like that. > Does cbc patch support UDP with packet loss though ? > If I remember correctly there are some sync issues. As far as I can see (and I am no blowfish expert for sure) it would be as "compress", it needs reliable connections. The point of using cbc instead of ecb is to prevent someone that catches packets number 20-30 to not be able to (easily) find out the key using those packets, since the keying material and IV changes depending on what was sent in packets 1-19. Unless I'm completetly off here, that means no udp+cbc. > >Also, if you start it out as a #ifdef/configure-option then the > >impact for other users should be minimal whereas those, like me, > >that doesn't like ecb as it is now can go for more secure connections > >as soon as possible. > Ifdefs is not a good solution. VTun already has modules so just a new lf= d_cbc.c or > something and new encrypt config option would be much better. If cbc requ= ires more=20 > then that it should be 3.x thing. I was trying to make the point that adding parsing for blowfish_cbc options in the config-file and other code to separate the different blowfish methods might introduce potential bugs whereas the small patch sent by James probably wont, but instead makes ecb-mode go away completetly. |
|
From: Maksim K. <ma...@qu...> - 2002-01-09 21:12:07
|
Hey James, Why don't you send me you SF.net user id. You seems to have time and you definitely have ideas. I'd be good to have you on the team. Bish will certainly have a hard time coordinating several developers ;-) btw We have to come up with common CVS commit strategy otherwise it's gonna be a mess. I'll start new thread regarding that. Max >I hope this fix makes it into 2.5.0 (Alexander Bergolth put it in the CVS >post 2.5b1) -- I think it solved a problem I was having where vtund didn't >properly come back up after network outages (when using persist/keepalive). > >diff -ur vtun-2.5b1/server.c vtun-2.5b1-jy/server.c >--- vtun-2.5b1/server.c Thu Jun 7 09:38:36 2001 >+++ vtun-2.5b1-jy/server.c Tue Dec 4 05:03:20 2001 >@@ -140,6 +140,7 @@ > > switch( fork() ){ > case 0: >+ close(s); > connection(s1); > break; > case -1: |
|
From: bishop <bi...@pl...> - 2002-01-10 23:35:49
|
Max Said: > Bish will certainly have a hard time coordinating several developers ;-) Heh. > btw We have to come up with common CVS commit strategy otherwise it's gonna > be a mess. I'll start new thread regarding that. Agreed. I didn't see the thread start, so here's my start: Not sure what they do for Apache CVS, but it seems to be: - everyone gets read access. yay! - one guy is in charge of rolling the CVS versions. - reduced set of people can CI patches into it. They review for policy conformity, version and indent style, then CO-patch-CI the code. - patches for future versions cannot be submitted until CVSGuy rolls version. Then it's a freakin' avalanche. I'm okay with that one - Leo's the CVS Guy, pick a few people through which patches are sent (Jim and Leo?), call it a policy and we're done. Thoughts? - bish |
|
From: James Y. <ji...@nt...> - 2002-01-10 10:26:36
|
Janne said: >As far as I can see (and I am no blowfish expert for sure) >it would be as "compress", it needs reliable connections. >The point of using cbc instead of ecb is to prevent someone >that catches packets number 20-30 to not be able to (easily) >find out the key using those packets, since the keying material >and IV changes depending on what was sent in packets 1-19. >Unless I'm completely off here, that means no udp+cbc. Well actually you can use cbc fine over udp if you init ivec to 0 for every packet as my patch does (I've run vtun this way for months through many network outages so I know it is robust wrt to lost packets). Since we need to be able to work over unreliable protocols (such as udp), it's not feasible to use a true stream implemenation of cbc where ivec is initialized once at the start of the session. But initializing once per packet still gives benefits, for example ciphertext in the middle of the packet will be dependent on what got encrypted at the beginning of the packet. If you'd like to "experience" the difference between ecb and cbc, try pinging over a vtun link, and then use tcpdump to watch the ciphertext fly by. With ecb mode you will see most ciphertext packets as 90% duplicates of the previous packets, if the plaintext is similarly duplicated. Most of the icmp header info + the ping payload itself is invariant across multiple pings, and ecb mode does nothing to scramble this invariance. Now try in cbc mode, with ivec initialized to 0 at the start of every packet. Tcpdump will now show a great deal of randomness and variability in each packet, even though the plaintext payload is largely the same. The randomness occurs because even slight variations in the packet header such as a tcp sequence number will act as a kind of seed, randomizing the rest of the message. To exploit this behavior more fully, vtun might insert a small random block at the head of every packet to randomly seed the ivec state. That block would then be discarded by the decryption function. If you do this (see last years archives for a patch), the resulting ciphertext stream will appear to be completely random, even for repeated packets with identical payloads. A bigger problem in my view is that since vtun is currently a static key system, there is the vulnerability inherent in reusing the same key for every packet. The solution is dynamic rekeying and patches to do this based on diffie-hellman have been submitted to this list over the last few months. Hopefully we will see them in beta in the near future. Jim Yonan Boulder, Colorado, USA |
|
From: Guus S. <gu...@sl...> - 2002-01-10 13:16:36
|
On Thu, Jan 10, 2002 at 03:26:05AM -0700, James Yonan wrote: > message. To exploit this behavior more fully, vtun might insert a small > random block at the head of every packet to randomly seed the ivec state. > That block would then be discarded by the decryption function. If you do > this (see last years archives for a patch), the resulting ciphertext stre= am > will appear to be completely random, even for repeated packets with > identical payloads. As pointed out to me by Jerome Etienne (see http://www.off.net/~jme/tinc_secu.html, replace tinc by vtun for another interesting read), a truly random IV is subjective to a birthday attack. You can use a simple counter instead, since the IV doesn't need to be random or secret at all (see Bruce Schneier, Applied Cryptography 2nd edition, page 194), it merely is there to prevent dictionaries from being generated based on the repeated occurence of the same ciphertext. > A bigger problem in my view is that since vtun is currently a static key > system, there is the vulnerability inherent in reusing the same key for > every packet. The solution is dynamic rekeying and patches to do this ba= sed Once you add an IV to every packet the problem will be less significant, but rekeying is a good idea anyway. --=20 Met vriendelijke groet / with kind regards, Guus Sliepen <gu...@sl...> |
|
From: Maksim K. <ma...@qu...> - 2002-01-10 18:10:34
|
>even though the plaintext payload is largely the same. The randomness >occurs because even slight variations in the packet header such as a tcp >sequence number will act as a kind of seed, randomizing the rest of the >message. I don't think that IP header can be considered random. If tunnel happened to transport a single TCP session all headers are very well predictable (sequence, etc). I'd still say that initializing ivec to 0 for every packet pretty much defeats the purpose of the ivec and brings you back to ecb level even though it sorta improve things. >To exploit this behavior more fully, vtun might insert a small >random block at the head of every packet to randomly seed the ivec state. >That block would then be discarded by the decryption function. If you do >this (see last years archives for a patch), the resulting ciphertext stream >will appear to be completely random, even for repeated packets with >identical payloads. Let's ask Tim. He did a some cool stuff with UDP. Tim, comments ? Max |
|
From: James Y. <ji...@nt...> - 2002-01-09 11:25:45
|
I hope this fix makes it into 2.5.0 (Alexander Bergolth put it in the CVS
post 2.5b1) -- I think it solved a problem I was having where vtund didn't
properly come back up after network outages (when using persist/keepalive).
diff -ur vtun-2.5b1/server.c vtun-2.5b1-jy/server.c
--- vtun-2.5b1/server.c Thu Jun 7 09:38:36 2001
+++ vtun-2.5b1-jy/server.c Tue Dec 4 05:03:20 2001
@@ -140,6 +140,7 @@
switch( fork() ){
case 0:
+ close(s);
connection(s1);
break;
case -1:
|
|
From: Michael T. <mj...@tl...> - 2002-01-09 21:41:12
|
Maksim Krasnyanskiy wrote: > > Hey Michael, > > Where is your SF.net id ??? You were supposed to be on the very first core team. > Or may be you're too lazy to register there ;-) I'm not lazy in this case. Something stopped me from registering. My preferred name (mjt) is in use already, for quite some time... ;) Well, I just registered @sf, to be "mjtsf" -- nothing more interesting comes to mind... ;) > >> default { > >> type tun; > >> proto udp; > >> cbc_encrypt yes; > >> } > > > >I think vtund should have more general way to specify such a things -- > >think of e.g. ssh. It may be e.g. `encrypt blowfish' vs `encrypt blowfish_cbc' > >(just an example of config *syntax*). The point is important -- once > >config changes are made, the syntax should be supported in next versions, > >so this sort of things should be done right from the beginning. > Exactly. > > It should be: > encrypt yes; # default encryption (ie ecb) > encrypt cbc; # cbc encryption > etc, etc, Not quite this. For now, vtun have support for blowfish only, so blowfish_cbc *may* be called just cbc. But if vtun will eventually support another algorithm(s), bare "cbc" will be confusing at least. I don't speak about 2.x here, you know... ;) Well, the name doesn't looks well to me, maybe "blowfish-cbc" or "bf-cbc" or "bfcbc" (and obviously the other way around, e.g. blowfish_ecb). Regards, Michael. |
|
From: Maksim K. <ma...@qu...> - 2002-01-09 23:03:10
|
> I'm not lazy in this case. Something stopped me from registering. My > preferred name (mjt) is in use already, for quite some time... ;) Well, > I just registered @sf, to be "mjtsf" -- nothing more interesting comes > to mind... ;) Ok. Welcome to the team :). > > It should be: > > encrypt yes; # default encryption (ie ecb) > > encrypt cbc; # cbc encryption > > etc, etc, > > Not quite this. For now, vtun have support for blowfish only, so > blowfish_cbc *may* be called just cbc. But if vtun will eventually > support another algorithm(s), bare "cbc" will be confusing at least. > I don't speak about 2.x here, you know... ;) Well, the name doesn't > looks well to me, maybe "blowfish-cbc" or "bf-cbc" or "bfcbc" (and > obviously the other way around, e.g. blowfish_ecb). Sure. It was just an example. Max |
|
From: James Y. <ji...@nt...> - 2002-01-10 10:28:47
|
> Hey James, > > Why don't you send me you SF.net user id. You seems to have time and you definitely have ideas. > I'd be good to have you on the team. > > Bish will certainly have a hard time coordinating several developers ;-) Hey thanks... My SF id is jimyonan. James |
|
From: Maksim K. <ma...@qu...> - 2002-01-10 17:56:59
|
>> Why don't you send me you SF.net user id. You seems to have time and you >definitely have ideas. >> I'd be good to have you on the team. >> >> Bish will certainly have a hard time coordinating several developers ;-) > >Hey thanks... My SF id is jimyonan. Welcome to the team. Max |
|
From: James Y. <ji...@nt...> - 2002-01-10 13:00:53
|
> I think vtund should have more general way to specify such a things -- > think of e.g. ssh. It may be e.g. `encrypt blowfish' vs `encrypt blowfish_cbc' > (just an example of config *syntax*). The point is important -- once > config changes are made, the syntax should be supported in next versions, > so this sort of things should be done right from the beginning. I completely agree. 'encrypt yes' is retained for compatibility but really means 'encrypt blowfish_ecb'. 'encrypt blowfish_cbc' is added as an option. A question on implementation: Should each blowfish mode get its own module, or should ecb/cbc mode be a parameter passed to a single blowfish module? Jim |
|
From: Maksim K. <ma...@qu...> - 2002-01-10 18:12:24
|
>A question on implementation: > >Should each blowfish mode get its own module, or should ecb/cbc mode be a >parameter passed to a single blowfish module? I'd say separate module. But I guess it depends on how different two modules are. If it's just couple of lines that it make sense to just patch current one. Max |
Thanks for helping keep SourceForge clean.
X