You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current implementation of warp-fs-ipfs does not support encrypting uploaded files. This is largely due to determining the best course on to take.
The thought on this would be to encrypt the file as a whole first with the generated key and process it into the block store. After it was created, we create a final dag that represents points to the content, but also have a field containing the private key that is encrypted with the uploader public key as well as another field with the signature of the file.
When sharing a file (eg in RayGun::attach), grab the reference of the dag from File::reference, modifying the field to reencrypt the field with shared key between the 2 users. This will create a new content id that can be attached to File that is transmitted as apart of the message, in which the recipient can later decrypt. In the matter #171, the same would apply, except that the private key apart of the sending user would be used would be reencrypted the field instead, which can then be decrypted later by recipients of the conversation upon retrieving it via bitswap.
Notes:
If the dag containing the links and references still remains in constellation after a recipient leaves, they would still have access to the file.
Encrypting the file, rather through the mentioned method above, or encrypting each individual blocks (not desirable, hence why not apart of this concept), would increase the overall size stored.
Should be a configuration flag that can allow files to be stored without being encrypted, though unsure on what impact this would have on sharing the file via RayGun.
Current implementation of warp-fs-ipfs does not support encrypting uploaded files. This is largely due to determining the best course on to take.
The thought on this would be to encrypt the file as a whole first with the generated key and process it into the block store. After it was created, we create a final dag that represents points to the content, but also have a field containing the private key that is encrypted with the uploader public key as well as another field with the signature of the file.
When sharing a file (eg in RayGun::attach), grab the reference of the dag from
File::reference
, modifying the field to reencrypt the field with shared key between the 2 users. This will create a new content id that can be attached toFile
that is transmitted as apart of the message, in which the recipient can later decrypt. In the matter #171, the same would apply, except that the private key apart of the sending user would be used would be reencrypted the field instead, which can then be decrypted later by recipients of the conversation upon retrieving it via bitswap.Notes:
The text was updated successfully, but these errors were encountered: