CRYPT target patch for newer kernel ?

CRYPT target patch for newer kernel ?

[Arif Hossain]

Hi,

I've come across many "CRYPT" or similar target patches will encrypt UDP
or TCP traffic.

Examples are :

1. A simple XOR target(-j XOR --key)

http://lists.netfilter.org/pipermail/netfilter-devel/2003-May/011532.html

2. A more robust ENCRYPT/DECRYPT target which will use full crypto api
of linux kernel:

http://0pointer.de/lennart/projects/seppl/

3. A generic CRYPT target

http://lwn.net/Articles/184670/

The last one i couldn't found any code. I've found the corresponding
mail in archive but the developer didn't submit it by a patch, but
submitted a download link which is a dead link anyway.

The first and second extensions are way out of date. 

I need these extensions. So i can develop one of my own, or port those
old ones. 

Before doing so, any newer extensions there which performs this? So that
i can modify that directly without porting it first?


-- 
Cheers

aft
aftnix@gmail.com

Re: CRYPT target patch for newer kernel ?

[Jan Engelhardt]

On Wednesday 2012-08-08 14:25, Arif Hossain wrote:
>
>I've come across many "CRYPT" or similar target patches will encrypt UDP
>or TCP traffic.

And they are mostly pointless..

>1. A simple XOR target(-j XOR --key)
>http://lists.netfilter.org/pipermail/netfilter-devel/2003-May/011532.html

XOR is not really an encryption.

>2. A more robust ENCRYPT/DECRYPT target which will use full crypto api
>of linux kernel:
>http://0pointer.de/lennart/projects/seppl/
>"IPSEC/FreeSwan is extremely complicated to use. Due to its strange routing
>scheme it is nearly impossible to use together with routing daemons. IPSEC is
>heavyweight."

Complicated? No, not at all. http://inai.de/2008/02/24
Heavyweight? Neither. The RSS is ~5 MB, most of which is pretty much
glibc anyway.

Re: CRYPT target patch for newer kernel ?

[Arif Hossain]

On Wed, 2012-08-08 at 15:41 +0200, Jan Engelhardt wrote:
> On Wednesday 2012-08-08 14:25, Arif Hossain wrote:
<snip>
> Complicated? No, not at all. http://inai.de/2008/02/24
> Heavyweight? Neither. The RSS is ~5 MB, most of which is pretty much
> glibc anyway.
> 

If clients are mainly embedded devices, and most of the time, all we can
do is to install a software on them, then is it feasible to use IPSEC? 

At this moment we are including the cryptography in the software we
provide for them, and many low end mobile devices has severe memory
limitation. 

Just for an example, we used tls for only the initial session
establishment, not the original data, and it proved very inefficient so
we had to abandon the thing completely.

The limitations of clinet devices forces us to use a very lightweight
and easy to implement (so that we can implement it in the limited
environment present in client devices) algorithms.

> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CRYPT target patch for newer kernel ?

[Jan Engelhardt]

On Wednesday 2012-08-08 15:53, Arif Hossain wrote:
>On Wed, 2012-08-08 at 15:41 +0200, Jan Engelhardt wrote:
>> On Wednesday 2012-08-08 14:25, Arif Hossain wrote:
><snip>
>> Complicated? No, not at all. http://inai.de/2008/02/24
>> Heavyweight? Neither. The RSS is ~5 MB, most of which is pretty much
>> glibc anyway.
>
>If clients are mainly embedded devices, and most of the time, all we can
>do is to install a software on them, then is it feasible to use IPSEC?

You can probably even use IPsec without StrongSWAN, if you manage to 
knit together the pieces using `ip xfrm state` and `ip xfrm policy`.


>Just for an example, we used tls for only the initial session
>establishment, not the original data, and it proved very inefficient so
>we had to abandon the thing completely.

So perhaps you did something really wrong?

Re: CRYPT target patch for newer kernel ?

[Arif Hossain]

On Wed, 2012-08-08 at 16:15 +0200, Jan Engelhardt wrote:
<snip>
> You can probably even use IPsec without StrongSWAN, if you manage to 
> knit together the pieces using `ip xfrm state` and `ip xfrm policy`.
> 

I guess i'm not clarifying my issue transparently. The client device is
far from linux or POSIX etc. Its ip stack does not have IPSEC either.
And its a vendor locked thing. We can install userland stuff. nothing
else. And to if i'm not wrong ,to enable IPSEC, we need to first port it
to the client machine. And its not possible and not feasible. We just
want to encrypt the UDP traffic. 

> 
> >Just for an example, we used tls for only the initial session
> >establishment, not the original data, and it proved very inefficient so
> >we had to abandon the thing completely.
> 
> So perhaps you did something really wrong?

Not actually, we did standard stuff. But the the poor and brain dead
processor could not handle it. The speed is ok if you want to surf web,
but its inadequate for real time data. Again i'm talking about a retard
processor with retard amount of memory. 

  
-- 
Cheers

aft
aftnix@gmail.com

Re: CRYPT target patch for newer kernel ?

[Jan Engelhardt]

On Wednesday 2012-08-08 16:15, Arif Hossain wrote:

>On Wed, 2012-08-08 at 16:15 +0200, Jan Engelhardt wrote:
><snip>
>> You can probably even use IPsec without StrongSWAN, if you manage to 
>> knit together the pieces using `ip xfrm state` and `ip xfrm policy`.
>> 
>
>I guess i'm not clarifying my issue transparently. The client device is
>far from linux or POSIX etc. Its ip stack does not have IPSEC either.
>And its a vendor locked thing. We can install userland stuff. nothing
>else. And to if i'm not wrong ,to enable IPSEC, we need to first port it
>to the client machine. And its not possible and not feasible. We just
>want to encrypt the UDP traffic. 

If it is not linux, it's pretty much irrelevant for this discussion 
group.

Re: CRYPT target patch for newer kernel ?

[Arif Hossain]

On Wed, 2012-08-08 at 17:34 +0200, Jan Engelhardt wrote:
<snip>
> If it is not linux, it's pretty much irrelevant for this discussion 
> group.

How so :)

the client is not linux does not mean the the server (for which i'm
developing) is not linux :)


client(simple encryption)------------------>(server equipped with
ENCRYPT extension which will do decryption for client to server path and
encryption for server to client path) ----> encryption agnostic local
process

I'm developing for server, which runs on linux, so i don't see how its
irrelevant here:)
-- 
Cheers

aft
aftnix@gmail.com

Re: CRYPT target patch for newer kernel ?

[Jan Engelhardt]

On Wednesday 2012-08-08 17:41, Arif Hossain wrote:
>
>client(simple encryption)------------------>(server equipped with
>ENCRYPT extension which will do decryption for client to server path and
>encryption for server to client path) ----> encryption agnostic local
>process

If your client cannot handle a workload like TLS, it is likely also too 
weak for any other, reasonable, implementation.