3 ms·

This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but: > If you could use KMS but encrypting is just a fun wee

This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but: > If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works. Paragraphs like this come across quite condescending, and the tone might have more to do with the lack of adoption of the ideas herein than the content does. Security Professionals seem to have an unfortunate habit of talking down to everybody else.

lvh 9y ago
Did you feel that entire graf was condescending or just parts of it? The "you don't have to understand how KMS works" perhaps? (It's definitely not meant that way :-))
- jstanley 9y ago
  I admit that I wrote that before I read the rest of the article. The rest of the article is great :). I don't know why that one paragraph stuck out at me so much, but it triggered the "screw you, don't tell me what to do" reflex.
  - eropple 9y ago
    When it comes to security, that reflex is almost categorically wrong. I say "almost" because the people who tell people like us what to do are also reading this thread. You don't get to have an ego when it comes to security or operational reliability (two separate fields, but ones with often similar resistance from developers). It just doesn't work that way.
AceJohnny2 9y ago
> Security Professionals seem to have an unfortunate habit of talking down to everybody else. I understand the feeling, and I have a related one, which is that the crypto field seems to be too "Rock-Star" focused. Unlike most other areas of software engineering, where a design flaw is unlikely to be business-threatening[1] and so engineers are comfortable rolling their own, crypto is very much of the "get it exactly right or don't do it at all" category. It's hard to get right, and it goes against many (most?) programmer's instinct of "I can code it up in a week(end)". Add to that the steady stream of news about some company's compromised security, and crypto experts who care to communicate to fix the software industry's happy-go-lucky culture are forced to become ever more strident and dumb-down the message to reach the widest possible audience. And then people think they're being condescending... It's a cultural issue based on a technical one, and I don't know how to fix it other than have software engineers be more careful. On the "rock-star" thing, it's because of how much we depend on a few recognized sources of authority (here, cperciva, tptacek) who we trust to point us in the right direction in the every-changing minefield of crypto practices. Other than have the field stop evolving and best practices become common-sense (which they absolutely aren't currently), I don't know how to fix that either. [1] they might cause bugs, they might cause downtime, they might cause frustration with users, but by themselves are unlikely to cost you [m/b]illions and kill your company
- tptacek 9y ago
  I want to be clear: LVH is a trained cryptographic engineer, but I'm a software security tester that just happens to have a sort of practice focus on crypto bugs. I try to be open with people that I am not qualified to design nontrivial cryptosystems; what I can do is spot problem areas in existing systems, and make predictions about what design choices are likely to lead to those kinds of problems.

lvh 9y ago

Did you feel that entire graf was condescending or just parts of it? The "you don't have to understand how KMS works" perhaps? (It's definitely not meant that way :-))

jstanley 9y ago
I admit that I wrote that before I read the rest of the article. The rest of the article is great :). I don't know why that one paragraph stuck out at me so much, but it triggered the "screw you, don't tell me what to do" reflex.
- eropple 9y ago
  When it comes to security, that reflex is almost categorically wrong. I say "almost" because the people who tell people like us what to do are also reading this thread. You don't get to have an ego when it comes to security or operational reliability (two separate fields, but ones with often similar resistance from developers). It just doesn't work that way.

AceJohnny2 9y ago

> Security Professionals seem to have an unfortunate habit of talking down to everybody else. I understand the feeling, and I have a related one, which is that the crypto field seems to be too "Rock-Star" focused. Unlike most other areas of software engineering, where a design flaw is unlikely to be business-threatening[1] and so engineers are comfortable rolling their own, crypto is very much of the "get it exactly right or don't do it at all" category. It's hard to get right, and it goes against many (most?) programmer's instinct of "I can code it up in a week(end)". Add to that the steady stream of news about some company's compromised security, and crypto experts who care to communicate to fix the software industry's happy-go-lucky culture are forced to become ever more strident and dumb-down the message to reach the widest possible audience. And then people think they're being condescending... It's a cultural issue based on a technical one, and I don't know how to fix it other than have software engineers be more careful. On the "rock-star" thing, it's because of how much we depend on a few recognized sources of authority (here, cperciva, tptacek) who we trust to point us in the right direction in the every-changing minefield of crypto practices. Other than have the field stop evolving and best practices become common-sense (which they absolutely aren't currently), I don't know how to fix that either. [1] they might cause bugs, they might cause downtime, they might cause frustration with users, but by themselves are unlikely to cost you [m/b]illions and kill your company

tptacek 9y ago
I want to be clear: LVH is a trained cryptographic engineer, but I'm a software security tester that just happens to have a sort of practice focus on crypto bugs. I try to be open with people that I am not qualified to design nontrivial cryptosystems; what I can do is spot problem areas in existing systems, and make predictions about what design choices are likely to lead to those kinds of problems.