Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:28 ADT
Anonymous (nobody@replay.com)
Thu, 16 Jul 1998 20:14:49 +0200
Oskar Pearson alleged:
>I am planning on making the linux-kernel cryptography stuff easy to use
>and secure. Currently the stuff that comes with the kernel is messed (see
>the mail below).
Now that you've made the crucial mistake of admitting that you're going to
do actual coding, I'm going to hit you with a wish list, albeit a somewhat
protracted one (the whole message isn't this bad -- persevere :)
* Allow quickly-destructible volumes: The option of making a
"quick-destruct" volume with its key randomly generated and stored only in
memory would be useful for many applications, especially if the volume
were cryptodeniable -- i.e., as soon as the administrator hits the power
button, it's as if the volume never existed, and can't nobody nowhere
prove it did. :D
A more versatile, if harder to implement, approach to this would be to
allow multiple sources for keys (i.e., hash of passphrase/"passdisk"
contents/HD sector, or random number generator for quick-destruct
temporary volumes), all of which are XORed to form the final encryption
key. That way, you could use secret-splitting on only some of the keys.
For example, imagine a setup where you could still recover the data if the
passdisk were lost, but the data would remain secret as long as you didn't
leak the passphrase.
* Be careful with your modes of application. Remember that a
moderately-rich adversary can recover the recent history of the contents
of the hard drive. Using CFB mode, for example, is a bad idea.
(more)
>
>Questions:
>
>2) I have read a few web pages about filesystem cryptography. One of them
> spoke about 'RAM chip burn-in'... when the password stayed in
> a static section of ram for an extended period of time the simm
> developed a permanent 'burn in' of the password.
> Is this really a problem? Has anyone got any references on this?
Yes and yes, but I'm not the one with the reference.
(more)
> What if we were to simply reverse all ON bits with OFF bits
> periodically? Very straight forward to do, and since the time periods
> of on and off would be equal, there shouldn't be a problem... right?
> we would just have to keep a single bit that said 'we are in the
> original state' or 'we are not in the original state - xor before
> using'.
Something very similar to this has been suggested, but one list member
raised the issue of it being a TEMPEST vulnerability.
(more)
>
>3) Has anyone got a Gnu assembler version of twofish? I know absolutely
> no assembler, but I would like to put twofish (in optimized
> form) into the kernel... Anyone think this is a bad idea? (Bruce - you
> aren't allowed to comment, ok? :)
Twofish is a well-designed, conservative cipher, but it's young enough
that a break is still a big risk. Therefore, I'd reccomend using a
more-analyzed cipher like CAST-128 for now, or at least something which
can't be less secure than it (i.e., use CAST-OFB on zeroes to generate
from the XORed-together keys a CAST key and a Twofish key, then use
Twofish-over-CAST for encryption).
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:28 ADT