Re: 3 step hashing for decomposition: feedback needed.
On Sat, February 25, 2012 19:18, David Barbour wrote:
> I have a few thoughts on the subject. I've sketched out a similar design
> in
> the past, for distributed state:
>
> First, use HMAC instead of the raw hash. The HMAC will provide a lot of
> extra protection when SHA256 is eventually (and inevitably) compromised.
Sounds like a good idea, so this is basically chaining two hashing
algoritms in case one gets compromised?
> Second, get rid of the private salt. Authority is provided by the keys,
> right? I think the salt is just obfuscating analysis. Where you use the
> salt currently, you could use some artificial directory names of the
> form "#ReadOnly" or "#Location".
>
> So you'll end up with:
> key2 = HMAC(SHA256,key1,"#ReadOnly")
> key3 = HMAC(SHA256,key2,"#Location")
Yes, so I should use the secret salt only for getting key1' ?:
key1' = HMAC(SHA256,key2,name')
I'll need the secret salt there to prevent the holder of key2 to be able
to get at key1'. That is, the holder of key1 has the authority to derive
key2, key1' and key2' but the holder of key2 should only have the
authority to derive key2'.
> Anyhow, I do see a potential problem with the direction you're
> considering.
> Whether you use private salts or my suggestion, you'll have a set of
> sparse
> keys generated from human-meaningful `paths`:
>
> key1 = /foo/bar
> key2 = /foo/bar#ReadOnly
> key3 = /foo/bar#ReadOnly#Location
>
> But some of these paths will be redundant in meaning.
> key2 = /foo/bar#ReadOnly
> key2alt = /foo#ReadOnly/bar
>
> But you cannot generate key2alt from key1. This would not be a problem if
> you weren't doubling the read-only key for encryption/decryption.
Basically if we take:
key1 = /foo
key2 = /foo#ReadOnly
Than for sub node 'bar':
key1' = /foo/bar
key2' = /foo/bar/#ReadOnly
Since in my design key1' is derived from key2, both /foo/bar#ReadOnly and
/foo#ReadOnly/bar will resolve to the same.
> But I
> think this would mean you need to provide key2alt alongside key1. And if
> you're going to provide multiple keys anyway, you might as well favor
> split
> capabilities. That is:
>
> key1 = (key1Read,key1Write).
>
> In many cases we'd want to split these anyway, e.g. the writer to a
> channel
> is not generally authorized to read from it.
In the old MinorFs1, all files and directories were read/write. Providing
read-only as an attenuation pattern made a lot of sense. I really didn't
think of also considering write only as an attenuation for files and
directories. I would have to consider if there are any non contrived
use-cases for write-only attenuation.
> Regards,
>
> Dave
>
> On Sat, Feb 25, 2012 at 7:08 AM, Rob Meijer <capibara@...> wrote:
>
>> A while ago I made a design for a database free version of the
>> sparse-capability part of the upcoming MinorFs2. MinorFs2 is meant as a
>> retrofitting suitable replacement for the old MinorFs that basically
>> demanded a good fit of the 'pseudo persistent process' concept that
>> arguably for most existing is a bad fit.
>>
>> Although I asked a few people with more cartographic knowledge than me
>> for
>> a review in the past, until now I haven't had any feedback from people
>> with a sufficiently solid background to be able to spot cryptographic
>> weaknesses in my design.
>>
>> The base idea is that we have a loop-back file-system where the top
>> file-system directory is accessible (read/write) with a randomly
>> generated
>> sparse key (key1). The file-system has a private salt that it uses to
>> derive other keys with. In order to , for a node, derive a read-only key
>> (key2) from a read/write key (key1) we say that:
>>
>> key2 = sha256(key1,salt)
>>
>> Now comes the scary part, in order to derive a sparse capability key for
>> a
>> sub directory or file within a given directory, lets call this sub node
>> node', I use :
>>
>> key1' = sha256(name',key2,salt)
>>
>> In my file-system I won't expose key1' to the holder of key2, only the
>> holder of key1 is allowed to extract key1' from the file-system, and the
>> security of this design thus depends on the file-system being able to
>> keep
>> its salt secret.
>>
>> In my design I let key2 double as the encryption/decryption key for the
>> file in the underlying file-system. Than in order to locate the
>> representation of the node in the underlying file-system, I use a third
>> hash to determine the relative storage location in the underlying
>> file-system:
>>
>> key3 = sha256(key2,salt)
>>
>> So basically anyone with read access to the underlying file-system (in
>> case of failure of the systems access control) should be unable to
>> extract
>> either the file-system structure or any data without access to a valid
>> sparse key.
>>
>>
>> I've put a graphical representation on the wiki:
>> http://minorfs.polacanthus.net/wiki/Minorfs2_cap_fs
>>
>> I would really appreciate if someone more into cryptography than me
>> could
>> either confirm that this design does not have a cryptographic weakness
>> or
>> if it does, help me to address it.
>>
>>
>>
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk@...
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
On Fri, February 24, 2012 03:12, Mark Miller wrote:
> This started a promising thread at <
> 
RSS Feed