5 ms·

(googler, opinions are my own) For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encr

by kyrra 7y ago

(googler, opinions are my own) For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encrypting payloads, PGP is well tested and most of the bugs have been worked out. JWS/JWE continues to have implementation bugs (likely due to being too flexible). [0] https://developers.google.com/standard-payments/reference/best-practices https://developers.google.com/standard-payments/reference/be...

CiPHPerCoder 7y ago
PGP isn't great either: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html Better options for PGP use cases: - AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html https://docs.aws.amazon.com/encryption-sdk/latest/developer-... - age https://age-encryption.org https://age-encryption.org - Magic Wormhole https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole - NaCl/libsodium (and/or usability wrappers) https://libsodium.gitbook.io/doc/ https://libsodium.gitbook.io/doc/ Better options for JWE use cases: - PASETO: https://paseto.io https://paseto.io - Branca: https://branca.io https://branca.io
- kyrra 7y ago
  PGP definitely has it's issues. It is a good tool for dealing with files, but yeah, it has it's problems. It looks like Google's security team prefers the use of Tink[0] when having to encrypt things. [0] https://github.com/google/tink https://github.com/google/tink
  - CiPHPerCoder 7y ago
    Yes, Tink is acceptable too. :)
  - cordite 7y ago
    Tink is great! I wish there were more supported languages. AEAD and AWS KMS to decrypt the key set is perfect for our needs.
  - tptacek 7y ago
    Tink is fantastic.
- stock_toaster 7y ago
  What are the main differences between Branca and PASETO? Based on my brief reading of both, it seems like the main differences are: * Branca has no signing mode, just authenticated encryption (eg. only "local" mode) * Branca's payload is just arbitrary bytes, whereas PASETO has a defined payload format * Seems like the same ciphers are used for Branca and PASETO v2/local. Is that a fair assessment?
  - CiPHPerCoder 7y ago
    Yep, that's a fair assessment. If you want ultra-simplicity and don't need clearsigned tokens (i.e. signed by a third party), you can get away with just using Branca. PASETO covers both use cases.
    - e12e 7y ago
      Hm, I think I prefer branca from a quick look (simpler is better). I'm a little worried that both seem to hide away datestamp/validity though. Branca notes checking the timestamp as optional - I couldn't tell what paseto does by default - other than a reference to a timestamp in the implentor's readme (and then only as an example parameter to the php code). Paseto does helpfully state that there's no replay protection - so don't use it for stateless (serveless) session tokens. But to both/either default to some kind of timeout? I don't really see any use cases where I'd want infinite validity - so in addition to sane algorithms, sane/required exipery seems like it should be part of such things? I think I might want a serial and a black-list too.. But maybe there are cases where invalidation aren't ever needed? I can't think of one right now.
      - CiPHPerCoder 7y ago
        PASETO has the same "claims" as JWT, except they're ISO 8601 timestamps rather than integers (UNIX timestamps). They're not required (as they weren't in JWT). If you want to use them, use them. The parser will validate them if you want it to. https://github.com/paragonie/paseto/blob/master/src/Rules/NotExpired.php https://github.com/paragonie/paseto/blob/master/src/Rules/No... https://github.com/paragonie/paseto/tree/master/docs/02-PHP-Library#decoding-tokens https://github.com/paragonie/paseto/tree/master/docs/02-PHP-...
- kyrra 7y ago
  To come back to one other point. Why Google payments uses PGP: because all other payment companies in the world do too. We work with many different companies, and when dealing with files, they all figured out how to use PGP 20+ years ago and probably won't change unless they are forced to. :) (googler opinions are my own)
XMPPwocky 7y ago
> PGP is well tested and most of the bugs have been worked out. Most of them. You're either using gnupg or you're using some custom PGP implementation. A custom PGP implementation has far more footguns than a restricted JWT implementation. Gnupg is a deeply terrifying codebase- for example, did you know you're not supposed to use the exit code of gpg --verify? You must parse statusfd, too, or many bugs will let you spoof signatures. (Bugs found as recently as this year). I'd encourage anybody considering using gnupg for anything to read mainproc.c and see if they understand what's going on.
- XMPPwocky 7y ago
  And to be clear, these are not "oh, an adaptive chosen plaintext attack and 2^56 compute may be able to forge signatures" bugs. These are real, exploitable, and many of the fixes probably won't be backported.

by kyrra 7y ago

CiPHPerCoder 7y ago

PGP isn't great either: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html Better options for PGP use cases: - AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html https://docs.aws.amazon.com/encryption-sdk/latest/developer-... - age https://age-encryption.org https://age-encryption.org - Magic Wormhole https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole - NaCl/libsodium (and/or usability wrappers) https://libsodium.gitbook.io/doc/ https://libsodium.gitbook.io/doc/ Better options for JWE use cases: - PASETO: https://paseto.io https://paseto.io - Branca: https://branca.io https://branca.io

kyrra 7y ago
PGP definitely has it's issues. It is a good tool for dealing with files, but yeah, it has it's problems. It looks like Google's security team prefers the use of Tink[0] when having to encrypt things. [0] https://github.com/google/tink https://github.com/google/tink
- CiPHPerCoder 7y ago
  Yes, Tink is acceptable too. :)
- cordite 7y ago
  Tink is great! I wish there were more supported languages. AEAD and AWS KMS to decrypt the key set is perfect for our needs.
- tptacek 7y ago
  Tink is fantastic.
stock_toaster 7y ago
What are the main differences between Branca and PASETO? Based on my brief reading of both, it seems like the main differences are: * Branca has no signing mode, just authenticated encryption (eg. only "local" mode) * Branca's payload is just arbitrary bytes, whereas PASETO has a defined payload format * Seems like the same ciphers are used for Branca and PASETO v2/local. Is that a fair assessment?
- CiPHPerCoder 7y ago
  Yep, that's a fair assessment. If you want ultra-simplicity and don't need clearsigned tokens (i.e. signed by a third party), you can get away with just using Branca. PASETO covers both use cases.
  - e12e 7y ago
    Hm, I think I prefer branca from a quick look (simpler is better). I'm a little worried that both seem to hide away datestamp/validity though. Branca notes checking the timestamp as optional - I couldn't tell what paseto does by default - other than a reference to a timestamp in the implentor's readme (and then only as an example parameter to the php code). Paseto does helpfully state that there's no replay protection - so don't use it for stateless (serveless) session tokens. But to both/either default to some kind of timeout? I don't really see any use cases where I'd want infinite validity - so in addition to sane algorithms, sane/required exipery seems like it should be part of such things? I think I might want a serial and a black-list too.. But maybe there are cases where invalidation aren't ever needed? I can't think of one right now.
    - CiPHPerCoder 7y ago
      PASETO has the same "claims" as JWT, except they're ISO 8601 timestamps rather than integers (UNIX timestamps). They're not required (as they weren't in JWT). If you want to use them, use them. The parser will validate them if you want it to. https://github.com/paragonie/paseto/blob/master/src/Rules/NotExpired.php https://github.com/paragonie/paseto/blob/master/src/Rules/No... https://github.com/paragonie/paseto/tree/master/docs/02-PHP-Library#decoding-tokens https://github.com/paragonie/paseto/tree/master/docs/02-PHP-...
kyrra 7y ago
To come back to one other point. Why Google payments uses PGP: because all other payment companies in the world do too. We work with many different companies, and when dealing with files, they all figured out how to use PGP 20+ years ago and probably won't change unless they are forced to. :) (googler opinions are my own)

XMPPwocky 7y ago

> PGP is well tested and most of the bugs have been worked out. Most of them. You're either using gnupg or you're using some custom PGP implementation. A custom PGP implementation has far more footguns than a restricted JWT implementation. Gnupg is a deeply terrifying codebase- for example, did you know you're not supposed to use the exit code of gpg --verify? You must parse statusfd, too, or many bugs will let you spoof signatures. (Bugs found as recently as this year). I'd encourage anybody considering using gnupg for anything to read mainproc.c and see if they understand what's going on.

XMPPwocky 7y ago
And to be clear, these are not "oh, an adaptive chosen plaintext attack and 2^56 compute may be able to forge signatures" bugs. These are real, exploitable, and many of the fixes probably won't be backported.