RE: hard to ban 'crypto holes' (Re: Crypto export....)

New Message Reply About this list Date view Thread view Subject view Author view

Black Unicorn (unicorn@schloss.li)
Mon, 18 Jan 1999 13:11:44 -0600


Effectively none of this will work if they really want to stick it to you.

coder and cypherpunks seem to get caught up in this pattern of playing
definition games with the regulatory bodies. This is the wrong approach.

If it is actually used to hook crypto in, it is a crypto hook. It doesn't
matter that this means any old generic code structure can be used to hook
crypto in. It doesn't matter than any reasonable person who has done even a
little bit of coding recognizes that this definition encompasses any and all
software distributions which have source code attached. It's a crypto hook.
You can't win this definition battle.

It reminds me of one attorney who was arguing the point that a broom which
was used to batter someone who later died did not fit the definition of a
deadly weapon and therefore his client should have one of the underlying
charges (assault with a deadly weapon) dismissed. Court: "Counselor, if it
caused death, it's a deadly weapon. Period."

And so it was.

> From: owner-CodherPlunks@toad.com [mailto:owner-CodherPlunks@toad.com]On
> Behalf Of Adam Back
> Sent: Monday, January 18, 1999 11:54 AM
> Subject: hard to ban 'crypto holes' (Re: Crypto export....)
>
>
>
> Michael Graffam writes:
> > James Maitland wrote:
> >
> > > One solution to this is to abstract the crypto so far away
> from the program
> > > that the latter isn't even aware the crypto is there.
> >
> > Yeah, this goes along with 'general processing module' too .. or even
> > scripts that can pre/post process the data.
> >
> > That is, allow support for a plug-in module to work on some 'data.' This
> > module could do all sorts of useful things. One module could convert MS
> > Word files into the program's internal format, another could decrypt PGP
> > encrypted documents. Other modules could do compression/decompression.
>
> The other approach is the pipe / TCP/IP socket. If the clients can be
> configured to select server host name and port number, you can
> integrate crypto using a local proxy.
>
> A few examples of this are:
>
> Ian Brown's Enigma http://www.cs.ucl.ac.uk/staff/I.Brown/
> Ben "Quincy" Cabell's ByProxy http://www.besiex.org
> C2Net's SafePassage http://www.c2.net
>
> These do the following:
>
> Enigma is a POP3/SMTP local proxy which does PGP encryption,
> signatures and decryption/signature verification. It includes a pure
> java implementation of PGP based on systemics'
> (http://www.systemics.com) cryptix java crypto library.
>
> ByProxy is a generalised local proxy system, providing a proxylet
> framework where the user can plug in proxylets written in java. It
> can do proxying for nntp, smtp, pop3, html, etc. It includes a set of
> useful proxylets for filtering s**m, enigma reformulated as a
> proxylet, and a few others.
>
> SafePassage is a local proxy for converting 40 bit crypto into 128 bit
> crypto for SSL.
>
> They all work by configuring your client (mailreader, web browser,
> newsreader) to use a local proxy (at localhost:port or 127.0.0.1:port).
>
> > A general suite like that would be rather powerful. One suite
> of programs,
> > say a general office suite, with plug in ability for all sorts
> of things,
> > notably crypto. One may be better off here using a good
> scripting language
> > (Perl comes to mind) than compiled modules. In which case our
> whole thing
> > starts looking a little like Emacs.. which is a good thing, IMHO.
>
> The level of configurability possible with emacs is nice. The
> limitation of the proxy approach is that it does not allow buttons and
> dialogs to appear within the application.
>
> Java is a nice way to integrate into applications due to the late
> binding possible with it. Pure java applications such as for example
> netscape5 / mozilla allow one to plug in or overload classes to
> provide security enabled SMTP / POP3 based mail handler etc.
>
> Java together with good OO design and open source seems like a good
> way to go.
>
> > Then again, were I not in the middle of all this, I'd find it hard to
> > believe that crypto is restricted to begin with.
>
> Yup. Bizzarre. The reason it appears bizarre is because it is an
> area where governments are forced to reveal their intrusive desires in
> the form of export controls. The rest of things such as say databases
> of cell-phone users locations to the nearest few meters going back
> years, profiling, lack of financial privacy etc., are less in the
> lime-light.
>
> Adam
>


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04