Blowfish encryption

Blowfish encryption

[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
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

Re: Blowfish encryption

[James Carlson]

Christopher Fowler writes:
> 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.

> 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.

>  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.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Blowfish encryption

[Bill Unruh]

On Wed, 9 Mar 2005, Christopher Fowler wrote:

> 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.

> 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?
>

Use ssh. 
> Thanks,
> Chris
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
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 |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: Blowfish encryption

[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.


On Thu, 2005-03-10 at 12:53, Bill Unruh wrote:
> On Wed, 9 Mar 2005, Christopher Fowler wrote:
> 
> > 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.
> 
> > 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?
> >
> 
> Use ssh. 
> > Thanks,
> > Chris
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

Re: Blowfish encryption

[James Carlson]

Christopher Fowler writes:
> 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.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Blowfish encryption

[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.


On Thu, 2005-03-10 at 13:17, James Carlson wrote:
> Christopher Fowler writes:
> > 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.

Re: Blowfish encryption

[James Carlson]

Christopher Fowler writes:
> 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

> 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.  :-/

>  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

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Blowfish encryption

[Christopher Fowler]

I think the thing I'll want to use is ECP.  Does pppd come with it?

On Thu, 2005-03-10 at 14:00, James Carlson wrote:
> Christopher Fowler writes:
> > 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
> 
> > 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.  :-/
> 
> >  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

Re: Blowfish encryption

[James Carlson]

Christopher Fowler writes:
> 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.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Blowfish encryption

[Bill Unruh]

On Thu, 10 Mar 2005, Christopher Fowler wrote:

> 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.

>
> 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?

>
> On Thu, 2005-03-10 at 12:53, Bill Unruh wrote:
>> On Wed, 9 Mar 2005, Christopher Fowler wrote:
>>
>>> 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.
>>
>>> 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?
>>>
>>
>> Use ssh.
>>> Thanks,
>>> Chris
>>>
>>>
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>

-- 
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 |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: Blowfish encryption

[Bill Unruh]

On Thu, 10 Mar 2005, Christopher Fowler wrote:

> 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?


>
> On Thu, 2005-03-10 at 13:17, James Carlson wrote:
>> Christopher Fowler writes:
>>> 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.
>

-- 
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 |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: Blowfish encryption

[John Hasler]

James Carlson writes:
> 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.
-- 
John Hasler 
john@dhh.gt.org
Elmwood, WI USA

Re: Blowfish encryption

[James Carlson]

John Hasler writes:
> James Carlson writes:
> > 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."

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Blowfish encryption

[Christopher Fowler]

In 99% of the cases the ppp is P-t-P only.  No packets are routed on
either side.

Re: Blowfish encryption

[Bill Unruh]

On Thu, 10 Mar 2005, John Hasler wrote:

> James Carlson writes:
>> 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.