Blowfish encryption
Hello,
I've been thinking about encryption in pppd. By reading my emails you've probably have an idea of what we do with pppd. Since I don't use pppd to attach a windows desktop to a Linux server I was thinking about maybe an implementation of Blowfish type encryption between two pppd processes. There could be a command line argument that runs on encryption and the two processes could determine in the LCP phase that
they are to encrypt all data between them. This is mainly for those
individuals who think that the phone company will tap their line and see their data. Not very useful in tunnels since programs like vtun do the encryption for pppd.
Is this something that might be feasible? I'm not looking to add certificate based encryption like SSL but encryption like SSH, Vtun and others. Would a windows connection croak if it dialed into my box and my box wanted to use encryption? Would the windows ppp process be smart enough to reject that request? Has anything like this been tried yet?
Thanks,
Chris
Quoted 10 lines · Christopher Fowler
I've been thinking about encryption in pppd. By reading my emails you've probably have an idea of what we do with pppd. Since I don't use pppd to attach a windows desktop to a Linux server I was thinking about maybe an implementation of Blowfish type encryption between two pppd processes. There could be a command line argument that runs on encryption and the two processes could determine in the LCP phase that
they are to encrypt all data between them. This is mainly for those
individuals who think that the phone company will tap their line and see their data. Not very useful in tunnels since programs like vtun do the encryption for pppd.
Not LCP, as peer identity isn't known at that time -- see the standards-based ECP (RFC 1968) and Microsoft's ugly hacks to CCP (RFC 3078) instead.
Quoted 3 lines
Is this something that might be feasible? I'm not looking to add certificate based encryption like SSL but encryption like SSH, Vtun and others.
Before spending a lot of time on the low-level details, I'd suggest considering what the threat model is, and what security associations are necessary.
For feasibility, there are a few issues to consider:
- You can't (or at least should not) just steal an option number to negotiate some new feature. The risk is that someone else will use the same number to mean something else, and the result will be an unpredictable interoperability problem. Instead, go through the IETF and IANA to do the proper allocation if you want to create a new protocol.
- Other implementations are required to reject things they don't understand, so it's reasonable to assume that they will do the right thing with any new option. However, it's unfortunately very well known that there are a pile of truly horrid implementations out there. Some don't pay attention to rejects correctly. Some reject things that were never offered. Some get confused and just crash. So, it's likely that you'll need some sort of option to enable this new behavior; it shouldn't be the default.
- Deployment is a consideration for any new protocol. If it's just for your own use, I guess you can do anything you want. But the goal of IETF protocols is to produce interoperable implementations. Thus, it'd be wise to study the existing solutions carefully to see if any can be coerced into doing what you need. Only if all of the existing solutions are unacceptable should you try to create a new one -- and even then, you face the problem that everyone in the world will need to implement your new feature in order for the feature to be useful. It's not a short path.
Quoted 3 lines
Would a windows connection croak if it dialed into my box and
my box wanted to use encryption? Would the windows ppp process be smart enough to reject that request? Has anything like this been tried yet?
I'm not sure those questions make sense. If your system requires encryption, why would *you* ever accept a connection that wasn't encrypted? In that case, why would you care that Windows flies to pieces when you ask it to encrypt? That's exactly what I think you would *want* to have it do.
Signature · 1 line
James Carlson <[email protected]>
Quoted 4 lines · Christopher Fowler
Hello,
I've been thinking about encryption in pppd. By reading my emails you've probably have an idea of what we do with pppd. Since I don't use
Bad idea. There is already a well accepted throughly tested way of doing this. It is called ssh. Use it.
Trying to overload ppp is not the way to do it ( and yes I know it is done).
Note that tapping a modem comjunication is hard at the best of times due to cross training refections etc.
Quoted 9 lines
pppd to attach a windows desktop to a Linux server I was thinking about maybe an implementation of Blowfish type encryption between two pppd processes. There could be a command line argument that runs on encryption and the two processes could determine in the LCP phase that
they are to encrypt all data between them. This is mainly for those
individuals who think that the phone company will tap their line and see their data. Not very useful in tunnels since programs like vtun do the encryption for pppd.
Quoted 6 lines
Is this something that might be feasible? I'm not looking to add certificate based encryption like SSL but encryption like SSH, Vtun and others. Would a windows connection croak if it dialed into my box and my box wanted to use encryption? Would the windows ppp process be smart enough to reject that request? Has anything like this been tried yet?
Use ssh.
Quoted 9 lines
Thanks,
Chris-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 4 lines
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [email protected] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
The only problem with ssh is that it is one protocol. There are many protocols that travel across the ppp link. Some fo them not encryted and can not be encrypted.
I stopped using telnet a long time ago. Also with these devices there are protocols that are routed across that link we have no control over so doing encryption inside of ppp would cover all the bases.
Quoted 40 lines · Bill Unruh
Quoted 4 lines · Christopher Fowler
Hello,
I've been thinking about encryption in pppd. By reading my emails you've probably have an idea of what we do with pppd. Since I don't use
Bad idea. There is already a well accepted throughly tested way of doing this. It is called ssh. Use it.
Trying to overload ppp is not the way to do it ( and yes I know it is done).Note that tapping a modem comjunication is hard at the best of times due to cross training refections etc.
Quoted 9 lines
pppd to attach a windows desktop to a Linux server I was thinking about maybe an implementation of Blowfish type encryption between two pppd processes. There could be a command line argument that runs on encryption and the two processes could determine in the LCP phase that
they are to encrypt all data between them. This is mainly for those
individuals who think that the phone company will tap their line and see their data. Not very useful in tunnels since programs like vtun do the encryption for pppd.Quoted 6 lines
Is this something that might be feasible? I'm not looking to add certificate based encryption like SSL but encryption like SSH, Vtun and others. Would a windows connection croak if it dialed into my box and my box wanted to use encryption? Would the windows ppp process be smart enough to reject that request? Has anything like this been tried yet?
Use ssh.
Quoted 9 lines
Thanks,
Chris-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Christopher Fowler
The only problem with ssh is that it is one protocol. There are many protocols that travel across the ppp link. Some fo them not encryted and can not be encrypted.
I stopped using telnet a long time ago. Also with these devices there are protocols that are routed across that link we have no control over so doing encryption inside of ppp would cover all the bases.
As I mentioned, if it's really a PPP issue (not clear that it is, as the threat model isn't clear), then ECP is likely to be the right answer.
If it's an IP issue (are you worried about non-IP protocols?), then I'd certainly recommend the use of IPsec. It defends against things that ssh (and, for that matter, SSL/TLS) cannot, works whether or not you use PPP, works on an end-to-end basis, and doesn't require changing everyone's implementations.
Signature · 1 line
James Carlson <[email protected]>
Some of these tin-hat people I tell them to simply buy encrypted modems that do the encryption between the. Are there anyone out there selling good ones anymore?
Th issue is that there are two boxes connected via a modem and using PPP for IP traffic. The customer wants to be sure all traffic across that phone line is encrypted. Since they use so many network product some old those protocol may be plain-text. By having ppp encrypt what it sends that would cover any data that travels across.
Quoted 18 lines · James Carlson
Quoted 7 lines · Christopher Fowler
The only problem with ssh is that it is one protocol. There are many protocols that travel across the ppp link. Some fo them not encryted and can not be encrypted.
I stopped using telnet a long time ago. Also with these devices there are protocols that are routed across that link we have no control over so doing encryption inside of ppp would cover all the bases.
As I mentioned, if it's really a PPP issue (not clear that it is, as the threat model isn't clear), then ECP is likely to be the right answer.
If it's an IP issue (are you worried about non-IP protocols?), then I'd certainly recommend the use of IPsec. It defends against things that ssh (and, for that matter, SSL/TLS) cannot, works whether or not you use PPP, works on an end-to-end basis, and doesn't require changing everyone's implementations.
Quoted 3 lines · Christopher Fowler
Some of these tin-hat people I tell them to simply buy encrypted modems that do the encryption between the. Are there anyone out there selling good ones anymore?
Dunno. Google seems to think so:
http://www.securtelecom.com/Products/Corporate/EncryptionSolutions/encryptionsolutions.htm
Quoted 3 lines
Th issue is that there are two boxes connected via a modem and using PPP for IP traffic. The customer wants to be sure all traffic across that phone line is encrypted.
That's just baffling. So, they are concerned that someone will tap the telephone line and manage to decode a V.90 data stream, but they're unconcerned whether the next hop itself (the modem at the other end) is itself "secure," or that hazards may exist between that modem and the ultimate packet destination, which may be many hops away.
How does that work?
That's why I was asking about the threat model. It doesn't sound rational. In the particular case of irrational requests, it tends to be difficult to design sufficient technical solutions. :-/
Quoted 3 lines
Since they use so many network product some
old those protocol may be plain-text. By having ppp encrypt what it sends that would cover any data that travels across.
Again, ECP and IPsec are likely the best ways to deal with this, though they solve very different problems.
ECP solves the PPP link encryption problem. It does *not* help with any traffic once it's forwarded past that single link. It's therefore of very limited utility in providing real security.
IPsec solves the end-to-end problem. It does *not* help if the peer you're talking to is compromised, but, then, likely nothing other than scissors will.
http://www.physics.usyd.edu.au/~matthewa/scissors.pdf
Signature · 1 line
James Carlson <[email protected]>
I think the thing I'll want to use is ECP. Does pppd come with it?
Quoted 42 lines · James Carlson
Quoted 3 lines · Christopher Fowler
Some of these tin-hat people I tell them to simply buy encrypted modems that do the encryption between the. Are there anyone out there selling good ones anymore?
Dunno. Google seems to think so:
http://www.securtelecom.com/Products/Corporate/EncryptionSolutions/encryptionsolutions.htm
Quoted 3 lines
Th issue is that there are two boxes connected via a modem and using PPP for IP traffic. The customer wants to be sure all traffic across that phone line is encrypted.
That's just baffling. So, they are concerned that someone will tap the telephone line and manage to decode a V.90 data stream, but they're unconcerned whether the next hop itself (the modem at the other end) is itself "secure," or that hazards may exist between that modem and the ultimate packet destination, which may be many hops away.
How does that work?
That's why I was asking about the threat model. It doesn't sound rational. In the particular case of irrational requests, it tends to be difficult to design sufficient technical solutions. :-/
Quoted 3 lines
Since they use so many network product some
old those protocol may be plain-text. By having ppp encrypt what it sends that would cover any data that travels across.Again, ECP and IPsec are likely the best ways to deal with this, though they solve very different problems.
ECP solves the PPP link encryption problem. It does *not* help with any traffic once it's forwarded past that single link. It's therefore of very limited utility in providing real security.
IPsec solves the end-to-end problem. It does *not* help if the peer you're talking to is compromised, but, then, likely nothing other than scissors will.
Quoted 1 line · Christopher Fowler
I think the thing I'll want to use is ECP. Does pppd come with it?
Nope. But I thought you were looking for new things to write. ;-}
There is an implementation of Microsoft's proprietary CCP hack called "MPPE" in pppd, and this does do the same sort of encryption, though you're limited to RC4 instead of Blowfish. It's negotiated using CCP rather than ECP by mistake and misdesign.
Signature · 1 line
James Carlson <[email protected]>
Quoted 3 lines · Christopher Fowler
The only problem with ssh is that it is one protocol. There are many protocols that travel across the ppp link. Some fo them not encryted and can not be encrypted.
I think you have to be much clearer on what you want to do, and whee you think your threat is coming from.
Quoted 5 lines
I stopped using telnet a long time ago. Also with these devices there are protocols that are routed across that link we have no control over so doing encryption inside of ppp would cover all the bases.
Which ones are you worried about?
Quoted 43 lines · Bill Unruh
Quoted 40 lines · Christopher Fowler
Quoted 5 lines
Hello,
I've been thinking about encryption in pppd. By reading my emails you've probably have an idea of what we do with pppd. Since I don't use
Bad idea. There is already a well accepted throughly tested way of doing this. It is called ssh. Use it.
Trying to overload ppp is not the way to do it ( and yes I know it is done).Note that tapping a modem comjunication is hard at the best of times due to cross training refections etc.
Quoted 9 lines
pppd to attach a windows desktop to a Linux server I was thinking about maybe an implementation of Blowfish type encryption between two pppd processes. There could be a command line argument that runs on encryption and the two processes could determine in the LCP phase that
they are to encrypt all data between them. This is mainly for those
individuals who think that the phone company will tap their line and see their data. Not very useful in tunnels since programs like vtun do the encryption for pppd.Quoted 6 lines
Is this something that might be feasible? I'm not looking to add certificate based encryption like SSL but encryption like SSH, Vtun and others. Would a windows connection croak if it dialed into my box and my box wanted to use encryption? Would the windows ppp process be smart enough to reject that request? Has anything like this been tried yet?
Use ssh.
Quoted 9 lines
Thanks,
Chris-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 4 lines
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [email protected] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
Quoted 10 lines · Christopher Fowler
Some of these tin-hat people I tell them to simply buy encrypted modems that do the encryption between the. Are there anyone out there selling good ones anymore?
Th issue is that there are two boxes connected via a modem and using PPP for IP traffic. The customer wants to be sure all traffic across that phone line is encrypted. Since they use so many network product some old those protocol may be plain-text. By having ppp encrypt what it sends that would cover any data that travels across.
What are the systems you use? If it is Linux systems and James says use ECP. If they are windows machines you may be more limited ( and you sure cannot rewrite ppp for them either).
Are these two machines stand alone machines whcihyou want to connect? Are they connected to the net? Are they really worried about wiretapping?
Quoted 21 lines · James Carlson
Quoted 18 lines
Quoted 7 lines · Christopher Fowler
The only problem with ssh is that it is one protocol. There are many protocols that travel across the ppp link. Some fo them not encryted and can not be encrypted.
I stopped using telnet a long time ago. Also with these devices there are protocols that are routed across that link we have no control over so doing encryption inside of ppp would cover all the bases.
As I mentioned, if it's really a PPP issue (not clear that it is, as the threat model isn't clear), then ECP is likely to be the right answer.
If it's an IP issue (are you worried about non-IP protocols?), then I'd certainly recommend the use of IPsec. It defends against things that ssh (and, for that matter, SSL/TLS) cannot, works whether or not you use PPP, works on an end-to-end basis, and doesn't require changing everyone's implementations.
Signature · 4 lines
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [email protected] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
Quoted 5 lines · James Carlson
So, they are concerned that someone will tap the telephone line and manage to decode a V.90 data stream, but they're unconcerned whether the next hop itself (the modem at the other end) is itself "secure," or that hazards may exist between that modem and the ultimate packet destination, which may be many hops away.
What makes you think that there is another hop? Not everything goes out over the Internet. This could be a simple point to point link.
Signature · 3 lines
John Hasler [email protected] Elmwood, WI USA
Quoted 9 lines · John Hasler
Quoted 5 lines · James Carlson
So, they are concerned that someone will tap the telephone line and manage to decode a V.90 data stream, but they're unconcerned whether the next hop itself (the modem at the other end) is itself "secure," or that hazards may exist between that modem and the ultimate packet destination, which may be many hops away.
What makes you think that there is another hop? Not everything goes out over the Internet. This could be a simple point to point link.
I'm pointing out that the threat model is incomplete.
Sure; it's possible that the only nodes communicating over that link are the endpoints, and no packets are ever forwarded through the link, nor forwarded by either endpoint to any other system.
That's certainly one scenario. However, since we don't have a threat model to work from, it's hard to say that it's really the right one -- hence the "may" in my statement. There's no way to tell. The only information given (wanting to encrypt packets over the link) is too scant to come up with solid answers except for one: I don't think the customer requesting this has really thought the problem through or, if he has, he's not revealing enough to explain the problem to be solved.
It's just way too easy to give a customer exactly what he asked for but not what he wanted. That's probably bad news if what he's asking for is "security."
Signature · 1 line
James Carlson <[email protected]>
In 99% of the cases the ppp is P-t-P only. No packets are routed on either side.
Quoted 9 lines · John Hasler
Quoted 5 lines · James Carlson
So, they are concerned that someone will tap the telephone line and manage to decode a V.90 data stream, but they're unconcerned whether the next hop itself (the modem at the other end) is itself "secure," or that hazards may exist between that modem and the ultimate packet destination, which may be many hops away.
What makes you think that there is another hop? Not everything goes out over the Internet. This could be a simple point to point link.
It could be, but the OP seems strongly reluctant to tell us anything about his system-- why he wants encryption what the setup is, what his threat model is, etc. Security is not something that can be done in a vacuum.