Re: journaling file systems

[Olaf Titz <olaf@bigred.inka.de>]

> Certain countries -- most notably the US -- consider any software with a
> "crypto-shaped hole" in it to be equivalent to crypto software for
> purposes of export controls; the buzzword is "enabling technologies".  Any
> code that is there solely or primarily to support use of cryptography is
> covered.  Whether "actual cryptographic code" is included or not does not
> make much of a difference to export status.

As it looks now, "enabling technologies" are not only considered
equivalent but in fact "stronger" than actual encryption software. See
the reasoning in
<URL:http://java.sun.com/products/jce/jce121_faq.html#FewerRestrictions>

(Which matches technical reality. Unfortunately, one is tempted to
say.)

> The only way to avoid this is to provide a more general-purpose interface
> that clearly has other uses (i.e., other uses are actually implemented,
> not just talked about).  That's quite a bit harder to do.

Which is why I was about to write a RFC for a "general data transform
API" and provide a compression algorithm as an example some time ago.
I gave up on that when discovering that the existing crypto API _very_
closely matched my thoughts. Hmmm...

Olaf

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/