----- Forwarded message from Sašo Kiselkov <skiselkov...@gmail.com> -----
From: Sašo Kiselkov <skiselkov...@gmail.com>
Date: Wed, 13 Feb 2013 00:01:08 +0100
To: z...@lists.illumos.org
CC: Pawel Jakub Dawidek <p...@freebsd.org>,
Garrett D'Amore <garrett.dam...@gmail.com>,
Richard Elling <richard.ell...@gmail.com>
Subject: Re: [zfs] Edon-R hashing and dedup
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106
Thunderbird/17.0.2
Reply-To: z...@lists.illumos.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/12/2013 11:37 PM, Pawel Jakub Dawidek wrote:
> On Tue, Feb 12, 2013 at 08:26:34PM +0100, Sašo Kiselkov wrote:
>> Hi Garrett,
>>
>> On 02/12/2013 07:34 PM, Garrett D'Amore wrote:
>>> I think security could be important here.
>>
>> I don't dispute that, all I'm saying is that security isn't our
>> primary concern and all in all dedup doesn't really focus on it -
>> the hash isn't a security feature. I'll elaborate below.
>
> I'm sorry, but ZFS is general purpose file system and hash function
> used for dedup just has to be secure. You don't know how someone
> will use the file system.
By that logic, we should mandate verification with dedup, because the
chance of a random collision is just on the order of 2^128:1!
> Take UFS for example. When you create a file it has to write data,
> create an inode and point the inode at the data. The order is very
> important here. If you first create an inode then point an inode at
> the data and at the end write the data it is a security bug,
> because if you crash before writing the data, the inode will point
> at some previous data, who knows what kind of data was there before
> - maybe sshd private key?
And it's possible that cosmic rays will hit your SAS interface in just
the right manner so as to correctly recompute the fletcher checksum
and make the in-flight BP point to a block containing sshd's private
keys. Oh the horror!
>> There are basically two types of attacks that you could mount
>> against such a system:
>>
>> 1) Secret plaintext retrieval: you know the hash of the target,
>> but want to retrieve some secret plaintext from the target (e.g.
>> /etc/shadow).
>>
>> 2) Plaintext modification: you know the plaintext and the hash,
>> but want to induce data corruption or alteration of the
>> plaintext (e.g. modifying a known /etc/shadow to change the root
>> password).
>>
>> We can comfortably dismiss #1 - if you know the hash of the
>> secret plaintext, you've already broken into the storage system
>> so deeply that you can just go ahead and read or modify the file
>> anyway.
>
> We absolutely can not dismiss neither #1 nor #2. Only because you
> cannot come up with feasible an attack vector, doesn't mean there
> isn't one.
>
> #1 gives you ability to read file you have no permission to read.
> #2 gives you ability to modify file you have no permission to
> modify.
>
> How you get the hash in #1 or how do you trick someone to make #2
> possible is totally different story, but let me provide some
> examples.
>
> #1 attack. You have access to company's shared storage and you can
> sniff HTTP traffic. The shared storage is used to hold important
> documents that are also time-stamped using external service over
> HTTP. The company is happy to use this external service as TSA (and
> you) sees only hashes. Now you have document's hash without deeply
> breaking into storage system. If you can find collision you can get
> this important document as well. I know that's not the best example
> as time-stamping make sense only when hash is collision-resistant,
> but you get the idea - there is no need to break into storage
> system to get the hash.
Except that nobody uses Edon-R-512/256 is such a manner.
> #2 attack. Attend a key signing party that your victim is going to
> attend. Download victim's public key and create your key with the
> same weak ZFS hash as victim's public key. Fingerprint based on
> strong hash of course will be different. Give your fingerprint to
> the same people your victim is giving his fingerprint. Now if
> someone is running ZFS with dedup and weak checksum and will
> download your key first and then your victim's key your attack
> succeeded. He will now be encrypting messages to your victim using
> your public key.
>
> Another #2 attack. Certificate of some new CA is added to major
> browsers. Generate certificate that matches ZFS weak hash of this
> new CA cert. Start spamming or send e-mail to few selected targets.
> With maildirs it should be pretty easy to make the proper alignment
> so that if the new browser's version is installed and new CA cert
> stored dedup instead of writing it, will point at your cert
> instead.
I'm sorry, but these are just pure fantasy land. The attacks you
describe are so unbelievably contrived that you might as well resort
to rubber hose cryptanalysis and be done with: https://xkcd.com/538/
What you propose is akin to performing dental surgery through the anus.
This is exactly the sort of discussion I was hoping to avoid: armchair
experts making contriving up fantasies of attacks that can neither be
quantitatively assessed nor approach by any rational means.
Cheers,
- --
Saso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlEayasACgkQle4gLqwmJMfR+QCgn+1ohjckklfDbH24OYSXp4j8
KyAAn0Bi0fYKY03q+Q7d9+NAZB1MEwnY
=1fHP
-----END PGP SIGNATURE-----
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f
Modify Your Subscription:
https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3366
Powered by Listbox: http://www.listbox.com
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
