Question about Up1's ident generation

[RedKage]

Hi there,

Sent an email first to Andre who replied that I should post this here.

I just looked at the source code of the Up1 project. Very interesting stuff.

Something however is bothering me: the client generates the file's ID (ident) from the seed which generates (what I will call) 'the decryption key'. Then it sends this ID to the server which will return encrypted data for this ID.

This is stated in the readme:

The seed is then run through SHA512, giving the AES key in bytes 0-256, the CCM IV in bytes 256-384, and the server's file identifier in bytes 384-512

Even though this ident is only a part of the seed used to generate the AES key, isn't there a possible future security concern? Because in the end, the server does have a piece of information to potentially decrypt the file -- or to speed up a brute force I guess.

So why not just generate a safe random ID server-side?

--save 1) Like, the client sends the encrypted data without the ident 2) Server generates the delete key + returns a GUID of the file it just created 3) Client receives deletion key + id key 4) Client creates image URL using decryption key + id key Like a JSON in base64

{
    key: "abc1234def",
    id: "1234-4567-....."
}

--load 5) Someone else gets this URL 6) This client will convert the anchor from base64 to JSON 7) This client gets both the decryption key + server ID 8) This client GETs the encrypted file from the server using this ID (which was the GUID generated from the server described in 2. ) 9) This client now decrypts the data using the decryption key

In this scenario, the ident is safely created and no part of it is related in any way to the decryption key. Wouldn't this be better?

Bonus: Ident collisions (even if unlikely) would also be handled server-side which is better I think. The server could retry and regenerate another Ident, which I'm not sure how it's handled right now (I haven't paid attention to that part); but I suspect the server would return an error code to the client. In which case, the client has to do a new upload to generate a new seed.

Anyway, I know there is almost zero chance to get the decryption key from a little piece of the seed in the current implementation. But, as I am uneducated in encryption in general, part of me just want to take no chance. At all. 'Cause I'm like... "you never know."

Or maybe I missed something reading the source code? I'm just curious.

Peace guys!

[ultramancool]

The idents and keys are generated in this way in order to provide shorter and simpler URLs without a loss of security. Your proposed solution here increases the length of URLs greatly and doesn't improve security in any practical way.

Because in the end, the server does have a piece of information to potentially decrypt the file -- or to speed up a brute force I guess.

There is no way to run SHA512 backwards and recover this. Speeding up a bruteforce may be possible, but an attacker could already just try to decrypt the first block of the AES result, which would result in roughly the same performance just outright bruting the AES key. No real improvement in bruteforce speed and both are infeasibly large.

Yes, if you had a way to break SHA512 using this part of the hash result to recover other parts of the hash result, this would be a problem, but no one has demonstrated this or any similar attack in SHA2.

Ident collision is a non-issue, 1 / 2^128 is essentially impossible to collide and this would simply cause a failure to upload, we do not handle this as the likelihood of collision is cryptographically low.

[RedKage]

Understood, that's pretty much what I thought. Thanks for these clarifications :)

[k3d3]

Since this has been clarified, I'm going to close this issue.