9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Steve Simon" <steve@quintile.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] s3venti
Date: Tue, 12 Feb 2008 17:45:19 +0000	[thread overview]
Message-ID: <0f20f6df5964a0f1e5d57d07e538316d@quintile.net> (raw)
In-Reply-To: <676c3c4f0802111449h7f9e0ae7h421ea563441c7b92@mail.gmail.com>

> For the record, s3venti does encrypt blocks that it writes to S3. It
> uses a single key, making it rather vulnerable to dictionary attacks,
> but I haven't come up with a way to do better without changing the
> venti protocol. Suggestions are welcome.

Beware: I am no security expert, I know just enough to be dangerous.

Ensure you have plenty of entropy - insist on long pass phrases.
sha1 this with the block number to give you the key for a particular block.
This at least permutes the venti tree info blocks - its real purpose is
to ensure the duplicate blocks look different when encrypted but venti doesn't
have duplicate blocks as such.

you could repeat the sha1 as it may be possible to infer some
info given all the sha1s start with the same (or known) prefix -
the pass phrase (or block number).

If you are likely to have multiple ventis with the same password on the server
(one for work stuff and one for home) then stir a random string into the sha1,
and keep this in factotum; generate this string when the venti is initialised.

your venti blocks are compressed which gives you some obscurity, guessing
plaintext is not so easy but huffman tables and the like still stand out.

If you want to be obsessive you could generate a block of random data, say 64k
which you hold locally and xor this with your venti blocks before encryption.
offset your start position in the random data by a value generated from the
sha1(sha1(blocknumber, passphrase)) (eg the checksum), this would make cracking
your data much harder.

Note this block of random data needs to be really random, not a PRBS like rand()
which is predictable. you could slowly suck bytes from /dev/random on a busy machine.

as ever its a case of:

	how valuable is it?
	how long to you want to keep it secret?
	who are you trying to keep it secret from?

caveat emptor

-Steve


      parent reply	other threads:[~2008-02-12 17:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11  4:19 Richard Bilson
2008-02-11  7:11 ` Skip Tavakkolian
2008-02-11 14:49 ` erik quanstrom
2008-02-11 16:39   ` Richard Bilson
2008-02-11 20:44     ` Bakul Shah
2008-02-12 11:44       ` Alf
2008-02-12 12:43         ` erik quanstrom
2008-02-11 22:34   ` Skip Tavakkolian
2008-02-11 22:49     ` Richard Bilson
2008-02-12  9:26       ` Wilhelm B. Kloke
2008-02-12 17:45       ` Steve Simon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0f20f6df5964a0f1e5d57d07e538316d@quintile.net \
    --to=steve@quintile.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).