Mailing List Archive: idea: MAC level compression & crypto

idea: MAC level compression & crypto

elmer at ylenurme

Aug 28, 1999, 10:49 AM

Post #1 of 31 (888 views)

MAC level compression & crypto
Got here old wireless aironet devices.
They are in principle ethernet, but with multipoint Access Point topology
endnodes can not see each other. Sort of ethernet with broken-by-design
collision-detection. With long-distance links and multipoint together it
is quite a problem with old wireless - and could be reduced.
There are also security problems.
There was discussion about compression in cipe development list.
I guess, to make such general compression and encryption, that would make
sense in device queue level.
For example, to have the code and nice proc user interface for to lookup
which MAC addresses are capable of receiving those proprietary frames(i.e.
are linux routers).
That code could
1. collect - for aironet it would be good to collect about 30-80ms of tcp
acks and other small packets by which endnodes disturb central node RX.
For ordinary ethernet too for 10ms - I guess tcp ack of 1/15 maxmtu size
takes about 1/3 maxmtu packet transmit time when other stations are not
active.
2. compress - there was a report on cipe development list on some nice
short-text-dictionary compressing.
3. encrypt - that would allow much cleaner cryptotunnels for example here
for me - to get antisniffing protection in ethernet hub network. It is
quite pain to have double sets of firewall rules, IP point2point tunnels,
etc.
any ideas, suggestions expected.
elmer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

alan at lxorguk

Aug 28, 1999, 11:19 AM

Post #2 of 31 (883 views)

> I guess, to make such general compression and encryption, that would make
> sense in device queue level.
Note we can't put crypto hooks into a kernel because America is stupid (not
America not Americans). They can go in the kerneli patches. Thats one
reason for just using ssh 8)
> 1. collect - for aironet it would be good to collect about 30-80ms of tcp
> acks and other small packets by which endnodes disturb central node RX.
> For ordinary ethernet too for 10ms - I guess tcp ack of 1/15 maxmtu size
> takes about 1/3 maxmtu packet transmit time when other stations are not
> active.
Packet aggregation works. The scarab driver does this. On a slow link the
aggregation is a win. On a faster link balancing the rx/tx overhead with
the aggregation latency is probably harder to tune but clearly a good idea.
> 2. compress - there was a report on cipe development list on some nice
> short-text-dictionary compressing.
Most packet bodies don't compress. Packet headers can be squashed with care
but the standard VJ compressor assumes packet ordering is roughly maintained
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

elmer at ylenurme

Aug 28, 1999, 11:45 AM

Post #3 of 31 (879 views)

On Sat, 28 Aug 1999, Alan Cox wrote:
>
> Note we can't put crypto hooks into a kernel because America is stupid (not
> America not Americans). They can go in the kerneli patches. Thats one
> reason for just using ssh 8)
btw,
that question has been staying around for longer in my head:
why there can not be HOOKS in kernel ?
they arent crypto...
elmer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

alan at lxorguk

Aug 28, 1999, 11:51 AM

Post #4 of 31 (880 views)

> > Note we can't put crypto hooks into a kernel because America is stupid (not
> > America not Americans). They can go in the kerneli patches. Thats one
> > reason for just using ssh 8)
>
> btw,
> that question has been staying around for longer in my head:
> why there can not be HOOKS in kernel ?
> they arent crypto...
Tell that to the US government. It sucks basically.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

rjwalsh at durables

Aug 28, 1999, 12:24 PM

Post #5 of 31 (883 views)

> > why there can not be HOOKS in kernel ?
> > they arent crypto...
>
> Tell that to the US government. It sucks basically.
When I was working on security systems (back when I lived in Ireland)
we couldn't put hooks in our code either because the French government
would not accept the software if we did. You couldn't even put the
crypto stuff inside a shared library in case someone preloaded
something else... I guess it's not just the US government.
Regards,
Robert.
--
Robert Walsh
Amalgamated Durables
Email: rjwalsh@durables.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

Aug 28, 1999, 1:04 PM

Post #6 of 31 (882 views)

Does this apply even if they aren't "for" crypto, but just happen to be
good places for crypto code to latch on to? How is it decided? I mean,
couldn't a call to main() be considered a crypto hook?
what if it's just named frobnostigate_data? even if it has to be
considered a "debugging" hook, and a function written to strobe the caps
lock indicator each time it's called, to give it semblance of
legitimacy... then, two weeks later someone "notices" the potential and
releases a crypto module...
-Tymm
On Sat, 28 Aug 1999, Alan Cox wrote:
> > > Note we can't put crypto hooks into a kernel because America is stupid (not
> > > America not Americans). They can go in the kerneli patches. Thats one
> > > reason for just using ssh 8)
> >
> > btw,
> > that question has been staying around for longer in my head:
> > why there can not be HOOKS in kernel ?
> > they arent crypto...
>
> Tell that to the US government. It sucks basically.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

elmer at ylenurme

Aug 28, 1999, 2:10 PM

Post #7 of 31 (880 views)

On Sat, 28 Aug 1999, Tymm Twillman wrote:
> Does this apply even if they aren't "for" crypto, but just happen to be
> good places for crypto code to latch on to? How is it decided? I mean,
> couldn't a call to main() be considered a crypto hook?
good idea ...
general memory block transformation routines :)
just like C++ STL generic algorithm applying interface ...
struct transformation_module{
...
};
struct transformation_applying_point{
...
};
struct transformation_applying_ruleset{
...
};
...
transform(skb,transformation_algo,transformation_data);
...
if (device_output_queue->transformations_list)
apply_transformations (
TRANSFORM_SKB_AT_DEVICE_OUTPUT_QUEUE,
(void*)skb,
device_output_queue->transformations_list );
for justification, there could be an reference rot13 transformation
module :)
or even more innocent - byteorder swaping transformation :)
I feel I am been missing possibility for rot13 transformation of all IP
packets for longer.
elmer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

hpa at transmeta

Aug 28, 1999, 2:26 PM

Post #8 of 31 (894 views)

Followup to: <85iu5z7loc.fsf@lame.durables.org>
By author: Robert Walsh <rjwalsh@durables.org>
In newsgroup: linux.dev.kernel
>
> > > why there can not be HOOKS in kernel ?
> > > they arent crypto...
> >
> > Tell that to the US government. It sucks basically.
>
> When I was working on security systems (back when I lived in Ireland)
> we couldn't put hooks in our code either because the French government
> would not accept the software if we did. You couldn't even put the
> crypto stuff inside a shared library in case someone preloaded
> something else... I guess it's not just the US government.
>
The French government got a clue and dropped their crypto opposition.
The U.S. government is getting more clue-impaired the deeper they dig
themselves in.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

Aug 28, 1999, 3:22 PM

Post #9 of 31 (880 views)

Robert Walsh wrote:
>
> > > why there can not be HOOKS in kernel ?
> > > they arent crypto...
> >
> > Tell that to the US government. It sucks basically.
>
> When I was working on security systems (back when I lived in Ireland)
> we couldn't put hooks in our code either because the French government
> would not accept the software if we did. You couldn't even put the
> crypto stuff inside a shared library in case someone preloaded
> something else... I guess it's not just the US government.
>
So how do the 'hooks' for XOR and DES encryption in the util-linux
package (mount/lo{mount,setup}.c) fit into this picture? Is that not
considered a crypto hook?
Marc
--
Marc Mutz <Marc@Mutz.com> http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

rjwalsh at durables

Aug 28, 1999, 4:22 PM

Post #10 of 31 (887 views)

Marc Mutz <Marc@Mutz.com> writes:
> So how do the 'hooks' for XOR and DES encryption in the util-linux
> package (mount/lo{mount,setup}.c) fit into this picture? Is that not
> considered a crypto hook?
Probably, but according to H. Peter Anvin, it looks like the French
have dropped their opposition to this (it's been a while since I've
played around with crypto stuff so I lost track in the meantime.)
Regards,
Robert.
--
Robert Walsh
Amalgamated Durables
Email: rjwalsh@durables.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

sbenno at gardena

Aug 28, 1999, 5:27 PM

Post #11 of 31 (887 views)

On Sun, 29 Aug 1999, Helge Hafting wrote:
> > - The disk performance decreases by 10-25% when I increase the CPU load in
> > the "latencytest" bench.
> The server people certainly won't like that.
Nor I do.
But I'm still not convinced it this is really possible.
You have to check rescheduling during
kernel memcopy routines , or large mem blocks moves, since at 100MB/sec
1MB of data = 10msec latency.
It not an easy task to keep latencies down.
Maybe the checking generates some cache misses and decreases performance,
especially when copying many small blocks ?
>
> > I think most of us want to have these "low-latency" features in the upcoming
> > 2.4 kernel since it will make Linux a very good _MULTIMEDIA_OS_.
>
> Everybody wants low-latency. But Linus looked at the patches and said
> "If *that* helps then something is wrong. Those functions shouldn't
> take so much time!"
> He then refused to accept patches that "paper over" a bug. Instead he
> wanted the bug fixed (i.e. make the functions in question take less
> time - they way they should.)
Agreed, but the question is: is some kernel hacker motivated to do
implement this before 2.4 ?
> That would give the same low latency without hurting disk performance under
> load.
I'm not 100%sure about this ..
Nothing comes at zero cost..
regards,
Benno.
--
Benno Senoner
E-Mail: sbenno@gardena.net
Linux scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

hpa at transmeta

Aug 28, 1999, 5:38 PM

Post #12 of 31 (879 views)

Followup to: <37C86123.2CF49E43@Mutz.com>
By author: Marc Mutz <Marc@Mutz.com>
In newsgroup: linux.dev.kernel
>
> Robert Walsh wrote:
> >
> > > > why there can not be HOOKS in kernel ?
> > > > they arent crypto...
> > >
> > > Tell that to the US government. It sucks basically.
> >
> > When I was working on security systems (back when I lived in Ireland)
> > we couldn't put hooks in our code either because the French government
> > would not accept the software if we did. You couldn't even put the
> > crypto stuff inside a shared library in case someone preloaded
> > something else... I guess it's not just the US government.
> >
> So how do the 'hooks' for XOR and DES encryption in the util-linux
> package (mount/lo{mount,setup}.c) fit into this picture? Is that not
> considered a crypto hook?
>
It's a generic data-transformation interface. The distinction may
seem meaningless but that's just a reflection of how ridiculous the
regulations are.
-hpa
N.B. "I'm not a lawyer. This is not legal advice."
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

ralf at uni-koblenz

Aug 29, 1999, 1:32 AM

Post #13 of 31 (879 views)

On Sun, Aug 29, 1999 at 12:10:34AM +0300, Elmer Joandi wrote:
> I feel I am been missing possibility for rot13 transformation of all IP
> packets for longer.
Note that ROT13 so many years after it's invention it no longer secure.
The recommendation these days is tripple ROT13 ;-)
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

R.E.Wolff at BitWizard

Aug 29, 1999, 3:44 AM

Post #14 of 31 (884 views)

Elmer Joandi wrote:
> for justification, there could be an reference rot13 transformation
> module :)
> or even more innocent - byteorder swaping transformation :)
>
> I feel I am been missing possibility for rot13 transformation of all IP
> packets for longer.
I really recommend NOT hinting at encryption by including a "rot13"
example.
As said before in this thread, HOOKS for encryption are munitions, and
cannot be exported.
A hook for rot13 is a hook for a (weak) encryption algorithm. That
leaves no room to argue "But we didn't intend for it to get used for
encryption. Just for an optional byte-swap".
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

Aug 29, 1999, 8:04 AM

Post #15 of 31 (886 views)

Rogier Wolff wrote:
>
<snip>
>
> I really recommend NOT hinting at encryption by including a "rot13"
> example.
>
> As said before in this thread, HOOKS for encryption are munitions, and
> cannot be exported.
>
Hooks for _strong_ encryption are, weak crypto (as rot13 _very_ clearly
is) is exportable (see your netscape browser). The other question is
whether the prohibition of crypto in e.g. France and Russia
covers/covered rot13. I think not. Rot13 is nothing that can be
considered _encryption_ anymore...?
Marc
--
Marc Mutz <Marc@Mutz.com> http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

R.E.Wolff at BitWizard

Aug 29, 1999, 8:27 PM

Post #16 of 31 (880 views)

Marc Mutz wrote:
> Rogier Wolff wrote:
> >
> <snip>
> >
> > I really recommend NOT hinting at encryption by including a "rot13"
> > example.
> >
> > As said before in this thread, HOOKS for encryption are munitions, and
> > cannot be exported.
> >
> Hooks for _strong_ encryption are, weak crypto (as rot13 _very_ clearly
> is) is exportable (see your netscape browser). The other question is
> whether the prohibition of crypto in e.g. France and Russia
> covers/covered rot13. I think not. Rot13 is nothing that can be
> considered _encryption_ anymore...?
A hook is for "encryption" It can't be specific to strong/weak
encryption.
rot13 is exportable, because they too see that they can't get
anywhere. If they see hooks whith the intent to add stronger
encryption later, you're much more likely to leave the wrong
impression.
Roger.
>
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

Aug 29, 1999, 11:31 PM

Post #17 of 31 (884 views)

On Aug 29, Ralf Baechle wrote:
> On Sun, Aug 29, 1999 at 12:10:34AM +0300, Elmer Joandi wrote:
>
> > I feel I am been missing possibility for rot13 transformation of all IP
> > packets for longer.
>
> Note that ROT13 so many years after it's invention it no longer secure.
> The recommendation these days is tripple ROT13 ;-)
be carefull: tripple-ROT13 still might be considered a (nuclear?!) weapon
in some (very) western countries ;-))
we really have to stay with single-ROT13 for hooks...
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

David.Woodhouse at mvhi

Aug 30, 1999, 3:39 AM

Post #18 of 31 (887 views)

elmer@ylenurme.ee said:
> why there can not be HOOKS in kernel ?
> they arent crypto...
The US Government, in its wisdom, has decreed that crypto hooks aren't allowed
to be exported either.
Presumably that's because without the hooks, we foreigners aren't even clever
enough to link in the existing crypto we've already smuggled from the US, so
that rule will stop us from using crypto just as effectively.
However, I believe you're allowed to export hooks if they're for compression.
Apparently we're not clever enough to plug crypto modules into compression
hooks either :)
N.B. This is sarcasm. That's one thing we _are_ capable of.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

ralf at uni-koblenz

Aug 30, 1999, 3:47 AM

Post #19 of 31 (881 views)

On Sun, Aug 29, 1999 at 12:44:14PM +0200, Rogier Wolff wrote:
> Elmer Joandi wrote:
> > for justification, there could be an reference rot13 transformation
> > module :)
> > or even more innocent - byteorder swaping transformation :)
> >
> > I feel I am been missing possibility for rot13 transformation of all IP
> > packets for longer.
>
> I really recommend NOT hinting at encryption by including a "rot13"
> example.
>
> As said before in this thread, HOOKS for encryption are munitions, and
> cannot be exported.
>
> A hook for rot13 is a hook for a (weak) encryption algorithm. That
> leaves no room to argue "But we didn't intend for it to get used for
> encryption. Just for an optional byte-swap".
Unlike for a hook for serious crypto a hook for ROT13 doesn't need to
handle keys ...
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

jnance at nortelnetworks

Aug 30, 1999, 5:47 AM

Post #20 of 31 (888 views)

On Sat, Aug 28, 1999 at 03:04:59PM -0500, Tymm Twillman wrote:
> Does this apply even if they aren't "for" crypto, but just happen to be
> good places for crypto code to latch on to? How is it decided? I mean,
> couldn't a call to main() be considered a crypto hook?
It is certainly in the government's best interest to be vague about
exactly what is covered by crypto regs, and they are. The US crypto
regulations get their power because they can intimidate people into
not doing things that the courts would not let them outlaw. The more
precisly the regulations are defined the less intimidating they are.
If you want to know the answer to your question, basically you have to
go ahead and do it and see if they try to put you in jail. If you are
like me you don't want to do this. See why its vague?
Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

jnance at nortelnetworks

Aug 30, 1999, 5:53 AM

Post #21 of 31 (882 views)

On Sun, Aug 29, 1999 at 03:04:02PM +0000, Marc Mutz wrote:
> Hooks for _strong_ encryption are, weak crypto (as rot13 _very_ clearly
> is) is exportable (see your netscape browser). The other question is
> whether the prohibition of crypto in e.g. France and Russia
> covers/covered rot13. I think not. Rot13 is nothing that can be
> considered _encryption_ anymore...?
Netscape has to get a license to export their browsers because they
contain crypto code.
I read the regulations once to see what kind of crypto I could put into
a piece of software and not have to get an export license. I thought
there was some provision for being able to export things with less than
a 40 bit key. I was wrong. You have to get a license to export ANY
crypto code. If you use less than a 40 bit key your chances of getting
a license are improved, but you still have to get one.
Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

Jes.Sorensen at cern

Aug 30, 1999, 8:45 AM

Post #22 of 31 (880 views)

>>>>> "Jim" == Jim Nance <jnance@nortelnetworks.com> writes:
Jim> It is certainly in the government's best interest to be vague
Jim> about exactly what is covered by crypto regs, and they are. The
Jim> US crypto regulations get their power because they can intimidate
Jim> people into not doing things that the courts would not let them
Jim> outlaw. The more precisly the regulations are defined the less
Jim> intimidating they are.
Jim> If you want to know the answer to your question, basically you
Jim> have to go ahead and do it and see if they try to put you in
Jim> jail. If you are like me you don't want to do this. See why its
Jim> vague?
It sounds more to me like you have been reading too much government
propaganda instead of thinking about what it actually means.
The US crypto laws are naiive and only hurts US businesses since the
crypto is already out there. It's like saying we are the only ones
smart enough to do crypto, but hey the rest of the world proved them
wrong again. Maybe they'll learn one day, the current laws are so
naiive it is unbelievable, it's hard to decide whether to laugh or
cry over it.
Anyway this is off topic for linux-kernel, if you want to reply do it
to me in private email please - I'll probably just ignore it anyway.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

uixjjji1 at umail

Aug 30, 1999, 9:59 PM

Post #23 of 31 (879 views)

>On Sun, Aug 29, 1999 at 03:04:02PM +0000, Marc Mutz wrote:
>> Hooks for _strong_ encryption are, weak crypto (as rot13 _very_ clearly
>> is) is exportable (see your netscape browser). The other question is
>> whether the prohibition of crypto in e.g. France and Russia
>> covers/covered rot13. I think not. Rot13 is nothing that can be
>> considered _encryption_ anymore...?
>
>Netscape has to get a license to export their browsers because they
>contain crypto code.
I find it difficult to agree that Netscape is an example for anything
interesting to this discussion.
There is no ROT13.DLL, no ROT13 API, and you cannot trivially replace
the ROT13 algorithm in Netscape with a significantly better one.
There's nothing hook-like about the way Netscape does ROT13. It's very
firmly hard-coded, and due to the tiny size of the algorithm, probably
very difficult to actually _find_ in the code unless there's actually
something like "rot13_decrypt()" in the symbol table.
ROT13 (in Netscape) has no key management API, or parameters of any kind.
It's difficult to see how it could be used for practical cryptography
given a key length of zero bits. You can get export licenses for
cryptosystems that only support one key that is already known to
the general public fairly easily; easily enough that I suspect even
U.S. bureaucrats will simply waive the usual paperwork, as long as you
don't advertise your product as a cryptosystem. If this were not true,
error-correcting codes and data compression would be cryptography too, as
would an ASCII-to-EBCDIC translator.
--
I don't speak for Corel, I just work for them. Use zygob@corel.ca for work,
zblaxell@furryterror.org for play, and zblaxell@feedme.hungrycats.org for PGP.
PGP fingerprint: 01 94 0F B3 46 B7 71 C3 D4 98 39 99 1B 34 45 A1
PGP public key: http://www.hungrycats.org/~zblaxell/pgp-public.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

uixjjji1 at umail

Aug 30, 1999, 10:06 PM

Post #24 of 31 (881 views)

>On Aug 29, Ralf Baechle wrote:
>> On Sun, Aug 29, 1999 at 12:10:34AM +0300, Elmer Joandi wrote:
>> > I feel I am been missing possibility for rot13 transformation of all IP
>> > packets for longer.
>>
>> Note that ROT13 so many years after it's invention it no longer secure.
>> The recommendation these days is tripple ROT13 ;-)
>
>be carefull: tripple-ROT13 still might be considered a (nuclear?!) weapon
>in some (very) western countries ;-))
>we really have to stay with single-ROT13 for hooks...
Hmmm...now is that triple-encrypt, or encrypt-decrypt-encrypt?
ROT39(x) == ROT13(ROT-13(ROT13(x))) == ROT13(x)
How about ROT13 with double the number of key bits? That would be...
ROT169(x) == ROT(169%26)(x) == ROT13(x)
This encryption algorithm resists all attempts to strengthen it!
It must be Clipper-ROT13!
;-)
--
I don't speak for Corel, I just work for them. Use zygob@corel.ca for work,
zblaxell@furryterror.org for play, and zblaxell@feedme.hungrycats.org for PGP.
PGP fingerprint: 01 94 0F B3 46 B7 71 C3 D4 98 39 99 1B 34 45 A1
PGP public key: http://www.hungrycats.org/~zblaxell/pgp-public.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: idea: MAC level compression & crypto [ In reply to ]

R.E.Wolff at BitWizard

Aug 30, 1999, 10:38 PM

Post #25 of 31 (905 views)

Ralf Baechle wrote:
> On Sun, Aug 29, 1999 at 12:44:14PM +0200, Rogier Wolff wrote:
> > A hook for rot13 is a hook for a (weak) encryption algorithm. That
> > leaves no room to argue "But we didn't intend for it to get used for
> > encryption. Just for an optional byte-swap".
>
> Unlike for a hook for serious crypto a hook for ROT13 doesn't need to
> handle keys ...
Unlike the requirements for ROT13, I recommend giving the compression
routine access to a pointer of "compression-parameters". For example,
you can agree with your communications partner on a precomputed
huffman table.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/