4 expanded posts ยท every known parent and child
A problem with a c'punk-style encrypted fs with source code and wide
distribution is, of course, that attackers will KNOW that there is a
duress key.
Rob
---
No-frills sig.
Befriend my mail filter by sending a message with the subject "send help"
Key-ID: 5D3F2E99 1996/04/22 wlkngowl@unix.asb.com (root@magneto)
AB1F4831 1993/05/10 Deranged Mutant <wlkngowl@unix.asb.com>
Send a message with the subject "send pgp-key" for a copy of my key."Deranged Mutant" <WlkngOwl@unix.asb.com> writes: >A problem with a c'punk-style encrypted fs with source code and wide >distribution is, of course, that attackers will KNOW that there is a >duress key. Good point. This suggests a design desideratum for any such system should be that the user may choose not to have a duress key, maintaining semi-plausible deniability for those who choose to have one. Jim Gillogly 23 Afterlithe S.R. 1996, 20:29
Jim Gillogly <jim@acm.org> writes:
> "Deranged Mutant" <WlkngOwl@unix.asb.com> writes:
> >A problem with a c'punk-style encrypted fs with source code and wide
> >distribution is, of course, that attackers will KNOW that there is a
> >duress key.
>
> Good point. This suggests a design desideratum for any such system should
> be that the user may choose not to have a duress key, maintaining
> semi-plausible deniability for those who choose to have one.
For plausibility it would probably be best if very few people used the
duress key feature.
If PGP had an infrequently used duress key feature, it would provide
quite a bit of plausible deniability: lots of people have PGP.
This was the basis for comments earlier in this thread about it being
desirable to have a very popular file system with these features
included. The more users (mostly for it's normal features) the less
suspicious having the software on your system becomes.
One problem is that some of the additional requirements to do a good
job of obscuring whether or not there is data in the unused part of an
encrypted file system add overheads.
For example re-encrypting the unused data with random IVs so that it
doesn't appear stale even if the duress key feature was not requested.
If that overhead is too great it will be annoying for people who do
not wish to use the duress key feature. It might possibly be a good
idea to do re-encrypting of the blocks anyway as it would obscure
usage patterns. (eg I am thinking when the disk starts up it will be
cold, as it warms up the heads will be positioned fractionally
differently, and from this kind of analysis it might be possible to
make inferences about the amount of data used in the file system,
etc.)
Adam
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)-----BEGIN PGP SIGNED MESSAGE----- On Tue, 16 Jul 1996, Deranged Mutant wrote: > A problem with a c'punk-style encrypted fs with source code and wide > distribution is, of course, that attackers will KNOW that there is a > duress key. I don't see how this would effect the security of such a filesystem. There is absolutely nothing that an attacker can do to get the real key. An attacker would just ignore all computers that have duress key capability. - -- Mark =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= markm@voicenet.com | finger -l for PGP key 0xe3bf2169 http://www.voicenet.com/~markm/ | d61734f2800486ae6f79bfeb70f95348 "Freedom is the freedom to say that two plus two make four. If that is granted, all else follows." --George Orwell, _1984_ -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBMewkJLZc+sv5siulAQEXVwP/Rs78lEERnz2HdtMAwnuSgwM7Bb1UZhTq WWF439dp0NdyVRNw9HvV4vzX+HuES2sXZ2IIugsm7pCOQoUW6aAbY0AnPQ/38yt4 HbtwtWSH4BI9Fc/by7UXEwYY2rKmQYZw80ZPcsunNFNG19+PanjOlEulHZAH/3Q7 8wF1J7WO4WU= =Jkfn -----END PGP SIGNATURE-----