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
James Maitland (jabba@jcp.co.uk)
Mon, 18 Jan 1999 11:40:12 +0000
The DoC regulations are very broad, and include conditions for "crypto-shaped
holes" in software.
The end result is that to ship binaries, you're stuffed if there's even a
mention of crypto in your API (say).
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.
One version of this is to embed crypto functionality into an abstract
'transport/storage' layer- so the software thinks it's working with plaintext,
yet the actual data is protected with full-strength crypto. If the software can
be shown to be utterly ignorant of the crypto that (some) clients (may choose
to) use, then it would have a good chance of escaping the crypto-shaped hole
regulations.
Essentially, we need more things like linux's /dev/random, providing security
in the operating system.
Yrs,
jabba.
At 18:32 13/01/99 , James Nerlinger, Jr. wrote:
>>Any export of _executable_ crypto code has to be registered. "Computer
>>readable" crypto code is supposed to be registered to certain countries,
>>it is considered "technology transfer" (i.e. you may be teaching the bad
>>guys how to do it them selves). Exporting a book has no restrictions.
>
>
>I suppose I should have clarified that statement -- thanks for the
>correction, Mike.
>
>>AFAIK Bersteine's (sp?) case is still pending, so it isn't clear yet that
>>code can be posted to a web page. This is both human and machine
>>readable. The government would prefer it isn't possible, but so far they
>>have lost every time. AS far as I'm concerned, posting C code on a web
>>page is the same as writing a book. So that's what I do.
>
>
>This is more along the lines of what I was referring to as far as the actual
>code is concerned.
>
>Another thought I referenced was designing a program that would load
>external modules for its encryption routines. This would allow a fully
>compiled program to be distributed generally, then the crypto libraries
>would be distributed separately. Shouldn't be too difficult to design I
>would think and it would allow for a maximum amount of configurability and
>growth for the product as whenever a new crypto library came out, it could
>simply be appended to the program -- a sort of crypto plug-in so to speak.
>
>James
>
Jim 'jabba' Maitland ( mailto:jabba@jcp.co.uk )
SSD, security products group, JCP.
PGP5 fingerprint "1DB3 D93B 1E57 5516 DDAF 5445 8ED6 CBBA 9E57 57D8"
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04