[119364] in cryptography@c2.net mail archive
Re: [p2p-hackers] convergent encryption reconsidered -- salting and key-strengthening
daemon@ATHENA.MIT.EDU (zooko)
Wed Apr 2 11:13:39 2008
In-Reply-To: <938CF967-28CF-4331-A787-E9C5CCFBE0DB@solarsail.hcs.harvard.edu>
Cc: tahoe-dev@allmydata.org,
Cryptography <cryptography@metzdowd.com>
From: zooko <zooko@zooko.com>
Date: Mon, 31 Mar 2008 13:19:02 -0600
To: theory and practice of decentralized computer networks <p2p-hackers@lists.zooko.com>
On Mar 31, 2008, at 4:47 AM, Ivan Krsti=C4=87 wrote:
>
> Tahoe doesn't run this service either. I can't use it to make guesses
> at any of the values you mentioned. I can use it to make guesses at
> whole documents incorporating such values, which is in most cases a
> highly non-trivial distinction.
The way that I would phrase this is that convergent encryption =20
exposes whatever data is put into it, in whatever batch-size is put =20
into it, to brute-force/dictionary attacks.
If the data that you put in is unguessable, then you needn't worry =20
about these attacks. (Likewise, as Ben Laurie reminds us, using =20
strong passwords is a sufficient defense against these attacks on =20
passwords.)
You correctly emphasize that typical convergent encryption services =20
(which operate on "files", or, in the case of GNUnet, on 32 KiB =20
blocks), and typical uses of those services (which typically store =20
"files" as produced by apps written for traditional filesystems), =20
batch together data in such a way that the aggregate is more likely =20
to be unguessable than if each field were stored separately. I don't =20=
disagree with this observation.
I am often reminded of Niels Ferguson's and Bruce Schneier's dictum, =20
in the excellent _Practical_Cryptography_, that security needs to be =20
a *local* property. They argue that one should be able to tell =20
whether a component is secure by inspecting that component itself, =20
rather than by reasoning about interactions between that component =20
and other components.
Concretely, convergent encryption with a per-user added secret, as =20
currently implemented in Tahoe, can be shown to guarantee =20
confidentiality of the data, regardless of what the data is.
Traditional convergent encryption can be shown to offer =20
confidentiality only with the proviso that the data put into it =20
conform to certain criteria -- criteria that cannot be verified by a =20
computer nor by a user who is not a skilled security expert.
You may argue that the chance that a user would put non-comformant =20
data into it is small. I don't necessarily disagree, although before =20=
I became willing to bet on it I would require more quantitative =20
investigation.
However, arguing that component A is secure as long as component B =20
behaves a certain way, and that component B is very likely to behave =20
that way, is a different sort of argument than arguing that component =20=
A is secure regardless of the behavior of component B.
For one thing, the behavior of component B may change in the future. =20=
Concretely, people may write apps that store data in Tahoe in a way =20
that previous apps didn't. Those people will almost certainly be =20
completely unaware of the nature of convergent encryption and brute-=20
force/dictionary attacks.
Now obviously making the security properties of a system modular in =20
this way might impose a performance cost. In the case of Tahoe, that =20=
cost is the loss of universal convergence. Allmydata.com analyzed =20
the space savings due to convergence among our current customers and =20
found that it was around 1% savings. We (allmydata.com) intend to =20
monitor the potential savings of universal convergence in an on-going =20=
way, and if it turns out that there are substantial benefits to be =20
gained then I will revisit this issue and perhaps I will be forced to =20=
rely on an argument of the other form -- that users are unlikely to =20
use it in an unsafe way.
Thank you again for your thoughtful comments on this issue.
Regards,
Zooko O'Whielacronx
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
