Keyed file headers

[super3]

Problem

Currently you must have the object_id and the decryption_key to access a file stored on the network through bridge. For the renter that uploaded the file, this paring is stored locally in a key ring. The bridge does not store this pairing and the user is solely responsible for the management of their keys. This presents for usability and security issues for the renter.

Lets assume that device 1 is the original device that is uploading the data, and device 2 is another device that is allowed to receive the data.

1. The user must maintain a continuous backup of the keying. If the device 1 is lost, damaged, or stolen all keys not backed up would be inaccessible.
2. Data stored via device 1 would be inaccessible to device 2 without key sharing.
3. If this data need to be accessed by multiple systems say 500, the key sharing would be quite chatty and expose much to an attacker about who has access to the data.
4. If device 1 was offline, device 2 would not be able to access the data unless they exchanged keys prior.

Solution

Each device should have a keyring of public keys of devices it would like to share the data with. Most likely these should be tied to a bucket. These public keys can be added manually(recommend), or retrieved from bridge.

Lets say a user wants to upload cat.jpg, into the "Cat Picture Bucket" with 5 public keys attached to the bucket. On upload preparation, the user would encrypt the files decryption_key with each of the public keys listed on that bucket (using PGP like keys). These encrypted blobs could be stored multiple ways:

1. Pre-pended to all file shards.
2. Pre-pended to all file shares with same Reed-Solomon scheme as the file.
3. Stored as a file itself on the network.
4. Stored on the bridge.

This would solve the above problems as follows:

1. User would only have to backup their private key.
2. Device 1 would not have to transmit the key to device 2.
3. The file originator would not have to communicate with any of the devices
4. Device 2 could access the data if device 1 was offline. .

Revocable Keys

Using this scheme if device 2 was compromised, all data shared with it might also be compromised because the keys are contained in the header. We can't remove data that the attacker has, but we would like to keep them from accessing more data that they don't have with the compromised keys. We can solve this in two ways:

• decryption_key is encrypted with the public subkey, so the the master private key is never used for normal operations.
• decryption_key is encrypted with nested keys. So the data stored in the header would be device1(device2(decryption_key)). Device 2 must ask device 1 to decrypt and pass him the encrypted blob. If device 1 knows that device 2 is compromised he will not pass him the encrypted blob.

[super3]

@littleskunk @gordonwritescode Feedback on my solution?

[littleskunk]

@super3 As renter I would prefer a solution that doesn't transfer the 'decryption_key' all the time. I have to pay for the traffic.

1. and 2. would force me to pay more.
2. sounds good. I could download and store the 'decryption_key' localy.
3. No way. I am paranoid. Bridge should not have my 'decryption_key'.

[tacticalchihuahua]

I still feel pretty strongly that we shouldn't be trying to do key management. We aren't a sync and share product and so any application built on top of storj should be the interface responsible for handling syncing keys.

In general a "bucket" is for an "app". The app that has access to the bucket should manage keys between devices, not bridge.

To skunk's point, I agree that bridge should never hold anything that could be used to access data. As far as adding keys to the data itself, we'd have to enforce that in the protocol and I'm not sure that's the right way to go. As for storing the decryption key as a file in the network, well that becomes circular: where do you store the key that decrypts the key to the file?

I think that neither bridge, nor the CLI should try to be too clever about key management. The simple keyring built in now should be sufficient. Furthermore the use of the local keyring is only in the CLI and not baked into the library itself so that developers using the library can choose how data gets encrypted and how keys are managed.

I think there are some good ideas here and we should maybe publish a document on best practices for key management when building apps on the storj network, but I don't think solving the problem to any extent outside of what's been done so far is an effective use of our time and resources.

Just my 3¢.

[super3]

Will respond to @littleskunk first.

1 and 2) You are only storing encrypted versions of a 256 bit key per
device. Should have negligible amount of storage. Maximum impact on your
bill would be $0.01-0.03 over tens of thousands of files.
3) Yes somewhat like a recursive backup. The new frame mechanism would work
well for this. Then you would only have to store one key.
4) The plaintext decryption key should never be stored on bridge. What I'm
advocating is that bridge store the encrypted cyphertext containing the
key. You should be the only one able to read that because it's only
encrypted with your pub key.
On May 16, 2016 5:02 PM, "littleskunk" notifications@github.com wrote:

@super3 https://github.com/super3 As renter I would prefer a solution
that doesn't transfer the 'decryption_key' all the time. I have to pay for
the traffic.

1. and 2. would force me to pay more.
2. sounds good. I could download and store the 'decryption_key' localy.
3. No way. I am paranoid. Bridge should not have my 'decryption_key'.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#64 (comment)

[super3]

I agree that we should not be doing key management at the bridge level, and
but we do need to give users options. Maybe this is something that can be
bumped down to a client library and bridge is just not aware of what is
going on.

Define anything. Bridge should never store plantext keys, but I think
bridge could handle an blob encrypted with device 1s pub key. Only device 1
can read this, not bridge. I'm of then opinion that this should look like a
regular file to bridge. Again I'm only advocating the storing encrypted
keys.

This came up when I was building a sample app. Our core value prop is that
we are simple. If a user spends 1 hour getting upload and downloading
working and 5 hours trying to figure out a key scheme then we just eroded
our core values prop.

I am starting to agree with you @gordonwritescode and @littleskunk, but I
think should be at least bumped down to the client lib. I fear that if we
just have a keyring approach on launch we will have a large washout rate
due the the issues I mentioned above. What do you think?
On May 16, 2016 5:53 PM, "Gordon Hall" notifications@github.com wrote:

I still feel pretty strongly that we shouldn't be trying to do key
management. We aren't a sync and share product and so any application built
on top of storj should be the interface responsible for handling syncing
keys.

In general a "bucket" is for an "app". The app that has access to the
bucket should manage keys between devices, not bridge.

To skunk's point, I agree that bridge should never hold anything that
could be used to access data. As far as adding keys to the data itself,
we'd have to enforce that in the protocol and I'm not sure that's the right
way to go. As for storing the decryption key as a file in the network, well
that becomes circular: where do you store the key that decrypts the key to
the file?

I think that neither bridge, nor the CLI should try to be too clever about
key management. The simple keyring built in now should be sufficient.
Furthermore the use of the local keyring is only in the CLI and not baked
into the library itself so that developers using the library can choose how
data gets encrypted and how keys are managed.

I think there are some good ideas here and we should maybe publish a
document on best practices for key management when building apps on the
storj network, but I don't think solving the problem to any extent outside
of what's been done so far is an effective use of our time and resources.

Just my 3¢.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#64 (comment)

[littleskunk]

@super3
Lets say I am a paranoid company and I allow my 100 employees home office. Lets share a little textfile, pdf or something like that. The file itself is only 1KB. 100 keys are 20KB overhead on each file and each file will be downloaded ~ 100 times every day. A good reason to prefer solution 3 or 4.

I have to agree that most renter will lose there keys sooner or later. They will use there mobile phone to upload some pictures and don't think about a key backup. We need a solution for them. Something like uploading one keyfile and do a paper backup to restore it if needed.

[super3]

Would be approx 1 GB in that case for the year under that use case. Same overhead if the file is 10 GB.

Not only backup, just anyone who wants to build applications if going to have issues with this.

[super3]

We need better solutions, but closing this for now.