2

I have searched for related topics, but found other existing answers to not be satisfactory, because they require installing special tools.

This is a very common use case. For example, I want to share sensitive login credentials with other members of my team so that we can administer servers.

Plaintext must be encrypted, and then both the password and the ciphertext have to be transferred to the friendly party over the insecure channel that is the internet.

The catch? I don't want to have to guide my associate through (or burden myself with having to go through) installing PGP or generating a 2048bit RSA keypair and host an SFTP server or something like that.

That means the only option left is the web browser.

Here's my solution so far. Consider onetimesecret.com to be a generalized web-accessible service that actually does what it promises to do. My question is, can this be further improved?

  1. Alice runs cat /dev/urandom | base64, grabs some part of the stream, long enough to be a good password, and not too long for the next step
  2. Alice sends this string to Bob via https://onetimesecret.com/
  3. Alice waits for Bob to report that the string has been successfully retrieved. If we trust onetimesecret.com, this means that only Alice and Bob are in possession of the string. If Bob reports that the link is dead and has been accessed, Alice throws away and generates a new password.
  4. Alice encrypts plaintext with the password that Bob has successfully received. For example, AES encryption using a 7z or RAR archive.
  5. Alice sends Bob another https://onetimesecret.com/ link with the contents. There is a bit of a flaw here, which is that the actual onetimesecret.com service doesnt appear to support file attachments. A workaround may be to Base64-encode the encrypted payload and send that. Or, less desirably, Alice can simply email it -- In this case, an adversary can obtain a copy of the encrypted file but would still need to decrypt it. Step 1 takes care of making this sufficiently hard.

The weakest link in this is likely to be step #3. I believe the correct terminology here is "Authentication".

The adversary's options are, as far as I can tell,

  • be onetimesecret.com or have internal access to it (we handwave this and say it's fine, they're secure)
  • break TLS or HTTPS. (we also handwave this and say it's fine, our OS is patched, our browser is patched)
  • impersonate Bob until Alice performs step 5. (Alice demands Bob stay on the phone to verify step 3)

And I might be stating the obvious here but just to clarify, the need for all these 5 steps is to add a sort of "manual" handshake step independently, in an effort to prevent data leakage -- this still means we have to trust the onetimesecret.com webservice to actually destroy the messages that we send to it that it promises are delivered only once.

The third item in the second list is the one relevant to the authentication part of our custom handshake. Traditional/standard secure authentication is not possible without the involvement of having extra steps to generate secure keys. I'm trying to streamline things to the point where they become practical. Which means not requiring users to be generating keys.

  • If you need a secure channel for Bob and Alice to mutually authenticate and share a secret, you might as well use that one. In other words I have the feeling you're just displacing the problem rather than solving it. – Steve Dodier-Lazaro May 27 '15 at 16:26
  • Well, I take it you mean Alice stands up an HTTPS/SFTP webserver so that the transfer can happen over TLS. Yes, but I want to do it without installing such a webserver anywhere. Isn't it true that Alice would have to obtain an SSL cert? – Steven Lu May 27 '15 at 16:27
  • 1
    I haven't mentioned HTTPS. What I meant was that "3. Alice waits for Bob to report that the string has been successfully retrieved." requires Alice to know that it is Bob talking, and some method for Bob to convince Alice that it was the right string being received. It would help to have a threat model to answer that question: who's attacking? Does it include people likely to break a CA or an ISP? How motivated are they (targeted vs indiscriminate attacks)? What's the lifetime and sensitivity of the secret? – Steve Dodier-Lazaro May 27 '15 at 16:30
  • Well, those are great questions but their answers are not well-defined. If I had the expertise, I would approach answering the question along those lines! Obviously if CA or ISP breakage happens then all bets are off considering the approach that I proposed. As for how motivated, well, I'm basically looking for a practical solution that resists the maximum amount of "motivation", if that makes sense. And let's just say that lifetime is pretty long (see example of server login credentials -- i suppose it's months at minimum given reasonable IT practices). Just pick reasonable values. – Steven Lu May 27 '15 at 16:38
  • Ok, so you'd be interested in protecting yourself against opportunistic hackers rather than a government doing mass collection of Internet traffic? I don't know the service at all so I don't know how it works, but an arbitrary private repository should be fine, yes. You could even share an email account and just write the temporary encryption key in the drafts, then have it deleted by the other party for what it's worth. – Steve Dodier-Lazaro May 27 '15 at 16:41

Your Answer

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

Browse other questions tagged or ask your own question.