how-we-share-secrets-at-a-fully-remote-startup

[giscus[bot]]

how-we-share-secrets-at-a-fully-remote-startup

Here’s the situation: a small, fully-remote software team works on a service (let’s say Grist), and to run it, they need a secret key...

https://mill.plainopen.com/how-we-share-secrets-at-a-fully-remote-startup

[dsagal]

Given a fairly lively discussion on lobste.rs and even a blog post bashing this one for unacceptable weaknesses, there are some improvements coming here, which happen to shorten the script further. Also:

💰$100 to the first 5 people who decrypt the following:

• encrypted with the original code:

  JUcA+ybEvRJzJXkjRFD21ZLoyr1sjhatotENEQzsGoXBa48IiNnuYEvdlJICccfaipiVbhM+qeYqHyfJmpA6DCUGPHp2LOyJ/f6WSZMfEUl8jOUaaJn/GjfWwhUNRw2tG3O1vYbuOiglXvxchckm1v/LZymM16KPfDSoXgmohLSB28lTYkGRiukeITZFzTNnzmoldAb6ah1lIXHdpUjBM+J2JDCdeXS7oysnVa3/W3sPbuUvgHayUzLt6gi4v6TIww8kd+ACakOHRoPHcxqAj2L4zTPB2A0X07vyVCg83zGRL8nXrHrCX86shm8njF6P2zo2yRFMWTOhJ91v52rUCnB5A8+hIvtVVjhz3atmDGuK39l/4c2t2pOi98gtICjuw/yCyzJcgziGWoI1DfbgxYvXCXgMbbMHMP5husnq3gEdocifT8vvlJH4gnBHSCTk/BrofgNfTy/qBxfdDjLB6Petl2WIlU+giT0mk4W+eVDrUPDvRcAqWGbjiQnY8g1uq1O/wHu38ANUS005n8uMgIsN9PDXoXMsNvdU04UPgh0mQJ+Lkic6UPFLpk81HckN05iH3w0ovZEUkcYYCTJSCrMya0RkBiMuMhYyrV5/7/qyD347RsLm3n7xZlh2FPZLTy7/TMV/HGKH4knfWwYfoh/MKcQYmzJDi4Dfz2awXaQ=
  

• encrypted with the code in https://github.com/gristlabs/secrets.js/blob/authenticated-mode/secrets.js:

  $rYiC7KDCeZCPI7Im2tcLfw==$SC2l1WZiU2fGcM4800AxBNUmT0JPBZYMKnTkVa1i48In9jAQcaY02TnAafDqlZSdPHx8Kytpy48gHyAKWSx0HfvK+5Ojm0XRevErIMNXD/XnEZAouUPr9nUIdLctVbMvqdLH1HM81IkRjNXR96qRqG4MydCZKl3GMFPbE+rOh+dDkKd9bqDPgGXGzrW6nyd+R3Yge0oLBLPaU9AcZ0tR2tpq9T8bfwr1ElAeiI/MHQ9wJaU2NauVfhKxKwTOJbujjKdMIS8bb7eAXELZ4Uju69N8vyg/bZFUKu+UEcAI+QxnXN1HSX4F8quRZLvZLYoJX2Pu+cUrVpiD50c19hoqmNpicC7GwJT1e06Enwl9emoF/76wLWa5eFw6jguYmAiNH9U3Q+BrcfAs/R6OO+y9x8Y8Wkdkxz806jVqFSfuCvNZDegSpJIzYougt4elGgkf0rT63z4glybE8wvkMQ2sPXxMQSoGX2gCT2+xpXOc8ZQNxk5k8FB83P2dUC2q7pdUzPMCalspbYamYESxSVtHQpbmfK3odtOEu761BYDyyjV1uUeuarB4tjqUrFYMVN2rNv/YEjFAoL2lKg3Q7kaHtudLbdw4bgvd/VeAmqZbFrIynB5NGWjV8IsRhInwBKDQE+dWUoQh26n3PUjhDtJDRgO8DBhBu7fY7RPBRXgPLUY=$WdU+dmJOVAXxHA+4bz2BO4ehLYMKGgOAqsUrgHifb07DozYN9GbLF0Ggkk8U1gAgAMlOiJNjMgmKGZyZsGt06LaivAb6EwI7w8OCwxVJSg==$baVoE3xOP1HHoCIBxJxyAQ==
  

• Public key (used for both):

  -----BEGIN PUBLIC KEY-----
  MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAmdQpA/ihZ4SuV7bHZcvG
  7QxETk88mDQ0Y2hDmGq3NSLlM1LigHoGkyQATFAChAJcz5H1eaoPc4zpst1+P9f7
  UYL3HDjJEPQlO3tISWtAnmBDnWc5d/kPLzwxhl6C/8whuLNRdE8JGdYQoc/fKzt+
  y5DsATBErdOxwGGtdsU2WrZC2IREm8Y2Y0TmbLb644W+8lSeQKlXJF3tk4+9y3/6
  6EM415U6khEzI4THqe6DoWDF6iLEc1hD4T4FKE3WmW8J9DTp/GBkFjIybL2r96TV
  DxrEs1Gkdd131mYMZ2Fe6jBqvYwe5KU+PeYBlFGcevLFpRhyHKzl0A05Vhy2T0v1
  TRybSzGON7wG6YiBpbqpJyJG76MiIlH36O95YTm2OeFYVATHnvPAW2nA5z+o7R70
  Qmtl3qDriIqAK0fJy96Bln864lf8mCi6rrFdZi+pCISajq+VtvIdCI4BU2pCwHKo
  81js3Le5nl+FH1cUdkbd3S+d9V24ffSEEE6WjqA1byIxY/OhvDKDixHjSFUVm1Zk
  6rIvZDfu3eqOIcwoVaj1y9upHPFJzn2UQd4tpnII+oGzyzaHlM3qkCqnakGN21OZ
  ywcFq3+Y7lWW5zskIhY9MSq+JI72+30rYiue2qJWOow3j9mYOvzBqEj/2qcW/6a+
  xvY7lXOpfFkg/w4hNZDnrdcCAwEAAQ==
  -----END PUBLIC KEY-----
  

If posting a claim publicly, only post the first two words of the decrypted text (email to report to in full is in decrypted text).

[strugee]

This contest does not provide the reassurance you think it does. While there's some differences due to the use case, it reminds me strongly of when Telegram ran a contest for people to break their garbage encryption. Here's a great post (since taken down both from the live internet and the Wayback Machine for some reason...) on why Telegram's contest - and this one - prove nothing about the security of the cryptography. Borrowing stealing from that blog post, this contest is missing: no MITM perspective, no known plaintext, no chosen plaintext, no chosen ciphertext, no tampering, no replay access (maybe this one isn't relevant side it's not a messenger, but the rest are), etc.

You might argue that some of these are unfair. For example, in the use case the blog post describes (two humans manually encrypting blobs to each other), an attacker probably won't get a chosen plaintext because that would require some social engineering. To which I say: do you really think it is a good idea to have the security of the cryptography rely on nobody ever building some kind of automation wrapper around this to make it a little more convenient to use? Not just anybody, a software engineer?

What you really want is a password manager. So just pay for Bitwarden or 1Password and get on with it. But okay, no, the blog post wants something that can be easily understood and audited. So just use age instead. It isn't as small as this script, sure, but my guess is it's not too hard to audit. And meanwhile, it's actually secure and peer-reviewed (plus now you don't have to maintain it).

Using this code is a gamble, and a bad one. This contest does nothing to demonstrate otherwise.

[dsagal]

The contest is useful to me if someone were to break it, as it would be a super-valuable lesson, and I'd be excited for that outcome. But mainly it's to highlight what the use case is about, and what most critics are missing: as you said, the use case has no server, no active attacker, no known plaintext, no tampering, no replay. The only security property sought is confidentiality, and the main social property sought is being simple enough to use that we don't just skip it and share the secret in plain text.

Is the post really encouraging the reader to build an automation wrapper around it? I don't think so.

There is clearly a problem though, and it is interesting. I think the root of the problem is that it doesn't matter what the code does, which library it uses, or how long or short it is. What matters is that most people aren't qualified to decide on the basis of the code whether to trust it. So the advice is: don't trust it. I agree. I'd trust such code if I really reviewed it carefully enough myself, or if I trusted sufficiently its author or another reviewer. But otherwise, all our trust comes from social validation. We can trust tool X if we see enough blog posts, or articles in media we trust, which recommend it, or enough stars and activity in the github repo with the code that X is said to be built from, or believing X to be used by many others. Such trust is still possible to manipulate, but we have to live with this.

As for this blog post, my conclusion is: I personally think it's correct and works for me, because I understand its properties and limitations; but I am not recommending it to others. Fair?

[avnr]

I'd just send the key over Signal, if one wants to feel extra covert then there's BitMessage