5 ms·

So... you've pointed out the problems, what are the solutions? What am I allowed to use as primitives to compose systems that require cryptographic functionali

by umvi 2y ago

So... you've pointed out the problems, what are the solutions? What am I allowed to use as primitives to compose systems that require cryptographic functionality? If I'm writing medical device software and the hospitals I'm selling to say I can't store files in plaintext on disk, but also some security expert on HN says I shouldn't use AES as a piece of the solution because that's "rolling my own crypto" and too dangerous, what should I do? Mandate that postgres configured with encryption be used (even if the application is simple and doesn't require a full db)? That will almost certainly harm the prospect of the sale because having to get hospital IT involved introduces a lot of friction. Or are you saying "use sodium to encrypt the file, don't try to do it yourself with AES"?

some_furry 2y ago
> What am I allowed to use as primitives to compose systems that require cryptographic functionality? The problem isn't the primitives, it's the act of a custom composition. The problem isn't whether AES is used. The problem is whether you're writing code that interfaces at the level of 128-bit blocks. Want a canned solution for generic problems? https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ Want a specific solution for your specific use case? Talk to an expert to guide you through the design and/or implementation of a tool for solving your specific problem. But don't expect everyone writing for a general audience (read: Hacker News comments) to roll out a bespoke solution for your specific use case.
tptacek 2y ago
There's a subtext here of "what do I do when the high-level libraries like Sodium don't do exactly what I need", and the frank answer to that is: "well, you're in trouble, because consulting expertise for this work is extraordinarily expensive". We have an SCW episode coming out† next week about cryptographic remote filesystems (think: Dropbox, but E2E) with a research team that reviewed 6 different projects, several of them with substantial resources. The vulnerabilities were pretty surprising, and in some cases pretty dire. Complaining that it's hard to solve these problems is a little like being irritated that brain surgery is expensive. I mean, it's good to want things. † https://securitycryptographywhatever.com/ https://securitycryptographywhatever.com/
- umvi 2y ago
  > There's a subtext here of "what do I do when the high-level libraries like Sodium don't do exactly what I need", and the frank answer to that is: "well, you're in trouble, because consulting expertise for this work is extraordinarily expensive". ...which is exactly why people roll their own crypto. Security folks don't seem to realize/care that money is a real constraint at most companies (esp. startups) and security can easily become a money furnace. When the only two options are: "use sodium" and "extraordinarily expensive consultant" then devs turn to the third option: https://pkg.go.dev/crypto/aes https://pkg.go.dev/crypto/aes Boom, file encrypted, requirement fulfilled, money saved, sale made. Perfectly secure? Probably not. The docs even say "The AES operations in this package are not implemented using constant-time algorithms". But maybe that's an acceptable tradeoff for your target risk profile.
  - akerl_ 2y ago
    If what you need is filed stored encrypted on disk... why is "use sodium" not a viable option for you?
    - umvi 2y ago
      It might be in many cases, but not every language it seems has explicit sodium support. Golang for example, has this not-widely-used wrapper (https://github.com/jamesruan/sodium https://github.com/jamesruan/sodium) maintained by some random guy which might not be desirable to use for a variety of reasons.
      - loup-vaillant 2y ago
        Foreign function interfaces aren't that scary. Any competent $lang developer ought to be able to read the docs and roll their own wrapper.
  - Dylan16807 2y ago
    I bet more than 90% of the devs turning to a third option could in fact use sodium or an equivalent. Especially if the goal is "boom, file encrypted".

by umvi 2y ago

some_furry 2y ago

> What am I allowed to use as primitives to compose systems that require cryptographic functionality? The problem isn't the primitives, it's the act of a custom composition. The problem isn't whether AES is used. The problem is whether you're writing code that interfaces at the level of 128-bit blocks. Want a canned solution for generic problems? https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ Want a specific solution for your specific use case? Talk to an expert to guide you through the design and/or implementation of a tool for solving your specific problem. But don't expect everyone writing for a general audience (read: Hacker News comments) to roll out a bespoke solution for your specific use case.

tptacek 2y ago

There's a subtext here of "what do I do when the high-level libraries like Sodium don't do exactly what I need", and the frank answer to that is: "well, you're in trouble, because consulting expertise for this work is extraordinarily expensive". We have an SCW episode coming out† next week about cryptographic remote filesystems (think: Dropbox, but E2E) with a research team that reviewed 6 different projects, several of them with substantial resources. The vulnerabilities were pretty surprising, and in some cases pretty dire. Complaining that it's hard to solve these problems is a little like being irritated that brain surgery is expensive. I mean, it's good to want things. † https://securitycryptographywhatever.com/ https://securitycryptographywhatever.com/

umvi 2y ago
> There's a subtext here of "what do I do when the high-level libraries like Sodium don't do exactly what I need", and the frank answer to that is: "well, you're in trouble, because consulting expertise for this work is extraordinarily expensive". ...which is exactly why people roll their own crypto. Security folks don't seem to realize/care that money is a real constraint at most companies (esp. startups) and security can easily become a money furnace. When the only two options are: "use sodium" and "extraordinarily expensive consultant" then devs turn to the third option: https://pkg.go.dev/crypto/aes https://pkg.go.dev/crypto/aes Boom, file encrypted, requirement fulfilled, money saved, sale made. Perfectly secure? Probably not. The docs even say "The AES operations in this package are not implemented using constant-time algorithms". But maybe that's an acceptable tradeoff for your target risk profile.
- akerl_ 2y ago
  If what you need is filed stored encrypted on disk... why is "use sodium" not a viable option for you?
  - umvi 2y ago
    It might be in many cases, but not every language it seems has explicit sodium support. Golang for example, has this not-widely-used wrapper (https://github.com/jamesruan/sodium https://github.com/jamesruan/sodium) maintained by some random guy which might not be desirable to use for a variety of reasons.
    - loup-vaillant 2y ago
      Foreign function interfaces aren't that scary. Any competent $lang developer ought to be able to read the docs and roll their own wrapper.
- Dylan16807 2y ago
  I bet more than 90% of the devs turning to a third option could in fact use sodium or an equivalent. Especially if the goal is "boom, file encrypted".