warning! spoilers! openbsd svnd is not safe for general use.
On 1/4/06, Ted Unangst <[EMAIL PROTECTED]> wrote:
> this is good idea. the first thing you need to do is identify your
> threat model. can you write it down? and if it starts with "somebody
> stealing", you lose. amidst all the yammering, i think people are
> just assuming that encrypting their data makes it "safe". but if you
> can't even say what the danger is, how can you know it's safe?
my threat model includes the follwing two cases. for both of then svnd
can't protect me really well
case 1) lets say someone can predict some blocks in my encrypted data,
then she can find every block (64bit) everywhere within the container
with the same data. dependend on the nature of the data, if some blocks
are known, more can be guessed. the license part of a source file is very
predictable. so if some software's source, which is no secret but its
possession illegal, can be proved to be on my disk without breaking my
key, this is bad. some illustration to prove, that every block of the same data
encrypted with the same user-key is the same in every svnd0 in the world:
# dd if=/dev/zero of=/tmp/img0 bs=1k count=1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000 secs (10666667 bytes/sec)
# dd if=/dev/zero of=/tmp/img1 bs=1k count=1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000 secs (12800000 bytes/sec)
# vnconfig -ckv svnd0 /tmp/img0
Encryption key: test
svnd0: 1024 bytes on /tmp/img0
# vnconfig -ckv svnd1 /tmp/img1
Encryption key: test
svnd1: 1024 bytes on /tmp/img1
# dd if=/usr/share/misc/license.template of=/dev/rsvnd0c bs=1k count=1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000 secs (12190476 bytes/sec)
# dd if=/usr/share/misc/license.template of=/dev/rsvnd1c bs=1k count=1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000 secs (11377778 bytes/sec)
# vnconfig -u svnd0
# vnconfig -u svnd1
# cmp /tmp/img0 /tmp/img1
#
user key==encryption key==Bad Thing(TM)
case 2) data integrity. I don't want, that a person can mess with my
data without knowing my key. the location of some data can be determined
on my disk, this data can be replicated everywhere else on the disk. either
by insertion or by overwriting other data. illustration continued:
# dd if=/tmp/img0 of=/tmp/img3 skip=1 bs=128 count=1
1+0 records in
1+0 records out
128 bytes transferred in 0.000 secs (1488372 bytes/sec)
# cat /tmp/img3 /tmp/img3 /tmp/img3 /tmp/img3 > /tmp/img6
# vnconfig -ckv svnd0 /tmp/img6
Encryption key: test
svnd0: 512 bytes on /tmp/img6
# cat /dev/rsvnd0c
dx
should be separated by a comma, e.g.
Copyright (c) 2003, 2004
p_h[he copyright. Additional years
should be separated by a comma, e.g.
Copyright (c) 2003, 2004
p_h[he copyright. Additional years
should be separated by a comma, e.g.
Copyright (c) 2003, 2004
p_h[he copyright. Additional years
should be separated by a comma, e.g.
Copyright (c) 2003, 2004
If you add extra text#
classical replay attack. I seem to have screwed some block boundary,
but you get the general idea. a good implementation would've produced
garbage only.
thanks a lot for your attention.
--knitti