Use PGP and avoid encryption key knowledge

[Motorrat]

Make a receiver user side key generation browser widget to generate a private/public keypair on his system. Allow receiver to send the public key as encoded in the link to the sender. Sender side widget encodes the file using that link/key locally on sender system.

The private key is stored in a write-only cookie or downloaded to the receiver system. The Blindsend Server thus never gets to see it. Decryption happens entirely on the receiver side using the information stored in the cookie.

[m4rk055]

Thanks for your suggestion.
Private keys of both receiver and sender never leave their browsers. In order to generate a key pair, receiver provides a password which is used as a seed for the key pair generating algorithm. Server gets only the data needed for password stretching (salt etc.), various nonces and the public key of file sender.

Receiver's public key is already encoded in a URI fragment in form of {domain}/{link_uuid}#{public_key}. A key pair is then randomly generated on the sender's side and together with the public key retrieved from the URI, a shared symmetric secret key can be computed and used to encrypt a file.
We just published the docs describing the protocol.

If we were to implement a design with the widgets, need for password would be removed since the receiver's private key is available (file system or cookie). That also makes the protocol safer since it becomes resistant to weak passwords.
Disadvantage is - secret key must be manually transferred if a receiver want's to decrypt the file on another system.

Do you think there are any security advantages if widgets are used?
Also, this design can be achieved without the widgets but they are surely useful to avoid going to the web page to initiate a session.

[Motorrat]

The essence of the service for the Receiver is to receive a file from the Sender and save it on his local file system. It seems logical to assume saving a private key file on the Receiver’s file system is a lower burden than generating and storing a (strong) password elsewhere.

As a separate note it wasn’t clear to me from your project description that you employed a sophisticated encryption and key generation protocol already. It may or may not be a more secure solution overall compared to the simple keypair approach proposed in this ticket.

So given you already have a strong encryption scheme the ultimate judgement criterion might be a marketing study of two user scenarios:

1. saving and managing a private key or
2. generating and managing a password

by the Receiver.

[m4rk055]

For the web app, I prefer the password scenario. It's more intuitive and easier to use for non-technical users.

I like the idea of storing the private keys locally for non-web APIs and will consider adding it as one of the options.