8

Alice: I need the file

Bob: Sure, and I want to encrypt it first. Please put the strong PGP symmetric key with the copy&paste method to https://onetimesecret.com/ and send me the link.

Alice. Done, the URL is xxxxxxxx

Bob: Very funny, the link is empty.

Alice: I know, it was only a test if i can trust you ... Here the correct one, xxxxxxxx

Bob: Thank you very much. Did you have seen in the last Big Brother UK episode, the scene with the haircut?

Alice: I have what?

Bob: Malika has used a clipper in a comfortable way ...

Alice: Hmm.

Bob: Forget it, here the e-mail attachment, strongly encrypted with the AES128 algorithm. Have fun.

Alice: Thanks, too. You're welcome. Bye

Alice and Bob have used a service between them to exchange a password. The first look is, that they have done all right. But they have to trust the website onetimesecret. If the attacker owns the website, he knows the PGP symmetric key too. What is the better alternative to exchange a key?

3
  • This might help. How do you know you are talking to google when you visit their website and not a fake attacker google? A CA of course, a third party. You trust that the certificate given to you is actually googles public key because you trust a third party certificate authority (CA) has signed it
    – pm1391
    Apr 27, 2018 at 4:43
  • 1
    What exactly is your goal? To simply encrypt and transmit a file using public key encryption?
    – forest
    Apr 27, 2018 at 4:52
  • Specifically onetimesecret.com sends the raw secret value to their server, so it does not look trustworthy at all.
    – Yaegor
    Apr 30, 2020 at 17:26

5 Answers 5

7

Key exchange is routinely done without using external services, by using cryptography. The most popular key exchange algorithm is Diffie-Hellman.

Quoting Wikipedia:

The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.

If you use Diffie-Hellman, don't use the anonymous version, but either fixed or ephemeral DH. See this answer.

Clearly, don't roll your own cryptography for anything real (i.e. outside of self study). Use something like OpenSSL for that.

1
  • You're right. First, Bob has to send a random-key to Alice with onetimesecret, and Alice has to answer also with a random key. Both combined is PGP symmetric key. Thanks for the hint with Diffie-Hellman key exchange. Apr 27, 2018 at 18:08
5

What is the better alternative to exchange a key?

Better in what way? Security? Simplicity?

In the case of security, have multple methods of key transmission.

For example, give 10 characters through phone, 10 characters through text, some more through onetimesecret, some more through another website (for example, https://read-once.info).

This way, even if one of the website/method of transmission is untrusted, they do not have the full key, but only a small part of it.

Of course, instead of plain text, you can also encrypt it first with Alice's public key. If you'd like, you can also give useless (or not enough) information for Alice to easily find the right key.

For example, give Alice "ABC", "123", "!@#" and "XYZ" through different methods of transmission when the full key is "XYZ123ABC" ("!@#" not used).

That is, have Alice permute all the given pieces.

1
3

I wouldn't trust a third party for storing secrets, however I do like the convenience of being able to share via a URL link.

To try to get the best of both worlds, I wrote self-destruct-o (https://self-destruct-o.control-alt-del.org/).

It's similar in concept to onetimesecret but with a few advantages:

  • It's trivial to run your own instance, code and instructions here: https://github.com/marksteele/self-destruct-o
  • No servers required! (although you will need an Amazon AWS account). The backend can run in the free tier!
  • When providing a passphrase for the secret, it derives an encryption key from the passphrase and then encrypts the value using AES-256 in CBC mode in your browser prior to sending it to the backend service.

You can email the link, and share the passphase over a second channel (eg: phone, sms) and can be sure nobody can intercept the secret.

More details here: https://www.control-alt-del.org/post/one-time-password-sharing-securely/

1
  • Obligatory: "Schneier's Law": "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." Don't do it.
    – zaph
    Sep 26, 2018 at 2:32
1

There are many way, how to properly share keys. For example if you managed to verify a PGP public key, you can use that to encrypt. This would always however require some amount of verification in person to be perfectly safe.

However, if you want a solution that would be closest to your example and "secure enough", there is a nice service called privatebin. It is open source and you can host it your self. More importantly the paste is encrypted in your browser using a symmetric key, which is part of the link. It is decrypted in the recipients browser. So the owner of the Privatebin site can't read your paste without being also able to see your conversation and getting the link.

Another option is Social Cryptography, for example using Deamonsaw. The way social cryptography works is, that you use shared knowledge to make layers of passwords. So for example you ask the other person to use the place you met for the first time as a password for the first layer. Then you ask them something else for the second one and so on, until you are confident only the correct person could know all the answers.

-1

I will change your scenario a little bit to show why you do not need to worry:

Bob: Very funny, the link is empty

Alice: Ho! so, somebody else read the key, I am encoding with new key and send you again the new one

Conclusion:

On one hand, if the link fails we know the password was read by a stranger, on the other hand, if Bob read the link it will fail for the next reader. That is why the data is safe. That is the main point of this mechanism.

Regarding Asymmetric keys, you do not need to hide a public key so Alice and Bob do not need to use onetimesecret services at all, so, it is irrelevant to the question.

*** UPDATE ***

In the original message i mentioned two options: Bob read the link or a stranger read the link.

Thanks to Schroeder (see notes) whom puts light on third option: The owner of the site read the key from the back-office, so, the link would not fail.

To make this option actual and dangerous to the data, we need the following conditions exist:

  1. The owner listened to the conversation between Bob and Alice.
  2. The owner have access to the inbox of Bob or Alice.
  3. The owner knows to point on the right message and data that are associated to the key

The chance that the conditions will take place is not real

Actualy, all the owner can see is just string of characters with out connection to purpose - is it a flight number? Solution for riddle? Place on the map? ...

So, yes - the owner see the string but the data is still safe

(*) If the owners of onetimesecret are the attackers they need to find the one who use the link and then figure out the purpose of the string and than start break the inbox ... come on

3
  • 1
    The stated concern is the owner of onetimesecret knowing the secret... They run the service. The link would still work in that case.
    – schroeder
    Apr 13, 2021 at 13:53
  • Thanks @Schroeder, I update my answer
    – Udi
    Apr 14, 2021 at 16:09
  • You are dismissing the threat because you can't imagine a bigger threat scenario. Here's the more likely scenario: the owner of the site keeps all secrets and sells access. Then threat actors who do end up getting access to the encrypted message request access to the key. The fact of the matter is that the secret is exposed. What happens after that is an unbounded problem.
    – schroeder
    Apr 14, 2021 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.