6 ms·

I'm not a cryptographer, but I'm pretty sure that CBC (https://github.com/robinmoisson/staticrypt/blob/main/lib/cryptoEngine/cryptojsEngine.js#L13 https://githu

I'm not a cryptographer, but I'm pretty sure that CBC (https://github.com/robinmoisson/staticrypt/blob/main/lib/cryptoEngine/cryptojsEngine.js#L13 https://github.com/robinmoisson/staticrypt/blob/main/lib/cry...) should be replaced with GCM (https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt#aes-gcm_2 https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...) since this is not a stream. https://security.stackexchange.com/questions/184305/why-would-i-ever-use-aes-256-cbc-if-aes-256-gcm-is-more-secure https://security.stackexchange.com/questions/184305/why-woul... (also, use the built-in WebCrypto API instead of the crypto-js package)

pluc 4y ago
Leave it to full-stack devs to take care of cryptography
- bloqs 4y ago
  As a newer dev later in life, I love to learn about inter-disciplinary snobbery/riffing. I learned some of what I know from a full stack dev, who was convinced anyone who couldnt do everything "was shit" and "should be something easier like a web developer or IT guy" instead. I'm excited to learn that pure disciplines also look down on full stack devs
  - Smar 4y ago
    There is tons of different types of programming out there.
dragontamer 4y ago
CBC is far easier to implement than GCM mode. I bet that most programmers cannot implement a Galois Field in Javascript. Meanwhile, CBC is just "encrypt then xor".
- tptacek 4y ago
  Nobody implements GCM themselves; they get it from a library. CBC, implemented the way you're describing, is almost always insecure.
  - dragontamer 4y ago
    And the library they use doesn't have GCM mode. So now what? https://cryptojs.gitbook.io/docs/ https://cryptojs.gitbook.io/docs/ Because CBC mode is easier to implement, you'll find it in far more libraries. And honestly, if your underlying block-cipher is secure (that's the hard part: where your side-channels all exist), then CBC mode is really the easy part and can be safely implemented yourself. It really is that simple. ----------------- CBC doesn't have authentication. So add on an HMAC. Done. It takes up a few more bytes but that's not a big deal these days.
    - tptacek 4y ago
      So use WebCrypto, instead of the cabinet of curiosities that is crypto-js. (Or, better yet, don't do stuff like this at all, because a browser window is simply an awful setting for serious cryptography).
      - fifafu 4y ago
        WebCrypto only works in secure contexts which is a significant limitation (https origins only)
        tptacek 4y ago
        Your next best bet might be sjcl.
        d-z-m 4y ago
        If you're talking about sending these files around via email/messenger, most browsers treat localhost as a secure context, so this doesn't seem like that significant of a limitation. If you are serving out an encrypted HTML page insecurely, your users are already hosed, because someone on the path could inject a script that sends the password to evil[.]com when they type it in.
- password11 4y ago
  > CBC is far easier to implement... Never implement your own cryptography. Edit: In fact an incorrect implementation of CBC mode famously caused a vulnerability in Microsoft's ASP.NET in 2010 (https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-070 https://learn.microsoft.com/en-us/security-updates/securityb...). The margin for error is small and even subtle mistakes or incorrect design can cripple security. Even Microsoft got it wrong once (although they handled remediation very well).
  - dragontamer 4y ago
    Or... you can have a more nuanced viewpoint and note that CBC is really, really, really easy to implement, and _really_ doesn't fall into that category of discussion. The reason you don't implement your own block ciphers is because side-channel attacks are damn near impossible for normal programmers to understand. Especially timing attacks. But block-modes of operation? Some of them are really easy. I've ever heard of a bad implementation of CBC causing a security bug. ------- I'd say you shouldn't implement your own GCM mode. GCM is quite complex, and the Galois Field's authentication bits could be side-channeled if you don't know what you're doing. CBC? Where's the flaw? Its so stupid simple I don't think that even a novice would make a critical error.
    - tptacek 4y ago
      You keep saying "the Galois Field" as if that was a thing. It's GCM. The components of GCM are CTR mode and the GMAC authentication code, which is based on GHASH. If you're afraid of Galois fields, you don't get to use AES at all! Nobody should be implementing any of these primitives themselves, very much including CBC, which, as you saw downthread, left both you and the author of this project with an insecure cryptosystem. Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it!
      - dragontamer 4y ago
        > You keep saying "the Galois Field" as if that was a thing You're kidding, right? You've never looked at how GCM-mode works? The entire set of math is inside of the GF(2^128) field. That's why its called a Galois Counter Mode. I don't think anyone should be implementing their own GCM mode. Its very subtle and potentially full of traps. CBC on the other hand is pretty dumb and simple, and surprisingly secure and robust > Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it! If they're so common, you shouldn't have much of an issue naming one such vulnerability.
- ThePhysicist 4y ago
  AES-GCM is part of the Web Cryptography API and supported in all modern browsers, so no need to implement anything.
- IncRnd 4y ago
  You're misleading a lot of people with poor comments about implementation vs. design correctness. Design of systems that use crypto requires a specific kind of attention to detail.
tptacek 4y ago
I don't know what "being a stream" has to do with anything (you should virtually always use "stream" modes of AES); the meaningful distinction between CBC and GCM is that GCM authenticates the ciphertext, so you can't tamper with it.
- tialaramex 4y ago
  > so you can't tamper with it. ... if the API provided is correctly designed, and either the language made it practical to design the API in a misuse-resistant way /or/ the programmer was actually careful and used it properly. We both know it's way more likely the problem in your actual system is "Oops, we use the bogus plaintext here despite the validation error" than "Dastardly enemy cryptographers have made a breakthrough in cryptanalysis to attack our product".
  - tptacek 4y ago
    I'm not thinking very hard about it; there is just never a reason to use unauthenticated encryption modes. When I wrote that comment, I hadn't even looked to see if they'd manually authenticated their ciphertext (spoiler alert: you can guess).
  - ThePhysicist 4y ago
    SubtleCrypto (Web Cryptography API) will simply throw an exception if the authentication fails for AES-GCM, so there's no way to even get at the bogus plaintext.
- forty 4y ago
  Also I checked the code quickly, they do Cbc-hmac, and they check the Mac before decrypting so it seems fine. The 1000 rounds only of pbkdf2 on something that's essentially going to be available without any access control (since the encryption is the access control here) might be more annoying as the password can be human generated.
deleted 4y ago
[deleted]
411111111111111 4y ago
The readme links to this issue wrt that decision https://github.com/robinmoisson/staticrypt/issues/19 https://github.com/robinmoisson/staticrypt/issues/19 It seems that the hmac validation makes the GCM unnecessary in their thread model
IncRnd 4y ago
CBC is Cipher Block Chaining. I think you might be referencing that the incorrect use of CBC leads to chosen-plaintext attacks, chosen-ciphertext attacks, or padding oracle attacks. GCM is AEAD, providing ciphertext authentication. [1] For those reasons that you mention, use of encryption should always have a design review. [1] https://en.wikipedia.org/wiki/Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD) https://en.wikipedia.org/wiki/Authenticated_encryption#Authe...
yoble 4y ago
Thanks for the feedback! We had an issue opened around that topic where it seems to me that the weak points of CBC do not apply in the context of StatiCrypt. If you have more thoughts on this I'd love to hear them. Relevant comment here: https://github.com/robinmoisson/staticrypt/issues/19#issuecomment-1322389267 https://github.com/robinmoisson/staticrypt/issues/19#issueco...

pluc 4y ago

Leave it to full-stack devs to take care of cryptography

bloqs 4y ago
As a newer dev later in life, I love to learn about inter-disciplinary snobbery/riffing. I learned some of what I know from a full stack dev, who was convinced anyone who couldnt do everything "was shit" and "should be something easier like a web developer or IT guy" instead. I'm excited to learn that pure disciplines also look down on full stack devs
- Smar 4y ago
  There is tons of different types of programming out there.

dragontamer 4y ago

CBC is far easier to implement than GCM mode. I bet that most programmers cannot implement a Galois Field in Javascript. Meanwhile, CBC is just "encrypt then xor".

tptacek 4y ago
Nobody implements GCM themselves; they get it from a library. CBC, implemented the way you're describing, is almost always insecure.
- dragontamer 4y ago
  And the library they use doesn't have GCM mode. So now what? https://cryptojs.gitbook.io/docs/ https://cryptojs.gitbook.io/docs/ Because CBC mode is easier to implement, you'll find it in far more libraries. And honestly, if your underlying block-cipher is secure (that's the hard part: where your side-channels all exist), then CBC mode is really the easy part and can be safely implemented yourself. It really is that simple. ----------------- CBC doesn't have authentication. So add on an HMAC. Done. It takes up a few more bytes but that's not a big deal these days.
  - tptacek 4y ago
    So use WebCrypto, instead of the cabinet of curiosities that is crypto-js. (Or, better yet, don't do stuff like this at all, because a browser window is simply an awful setting for serious cryptography).
    - fifafu 4y ago
      WebCrypto only works in secure contexts which is a significant limitation (https origins only)
      - tptacek 4y ago
        Your next best bet might be sjcl.
      - d-z-m 4y ago
        If you're talking about sending these files around via email/messenger, most browsers treat localhost as a secure context, so this doesn't seem like that significant of a limitation. If you are serving out an encrypted HTML page insecurely, your users are already hosed, because someone on the path could inject a script that sends the password to evil[.]com when they type it in.
password11 4y ago
> CBC is far easier to implement... Never implement your own cryptography. Edit: In fact an incorrect implementation of CBC mode famously caused a vulnerability in Microsoft's ASP.NET in 2010 (https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-070 https://learn.microsoft.com/en-us/security-updates/securityb...). The margin for error is small and even subtle mistakes or incorrect design can cripple security. Even Microsoft got it wrong once (although they handled remediation very well).
- dragontamer 4y ago
  Or... you can have a more nuanced viewpoint and note that CBC is really, really, really easy to implement, and _really_ doesn't fall into that category of discussion. The reason you don't implement your own block ciphers is because side-channel attacks are damn near impossible for normal programmers to understand. Especially timing attacks. But block-modes of operation? Some of them are really easy. I've ever heard of a bad implementation of CBC causing a security bug. ------- I'd say you shouldn't implement your own GCM mode. GCM is quite complex, and the Galois Field's authentication bits could be side-channeled if you don't know what you're doing. CBC? Where's the flaw? Its so stupid simple I don't think that even a novice would make a critical error.
  - tptacek 4y ago
    You keep saying "the Galois Field" as if that was a thing. It's GCM. The components of GCM are CTR mode and the GMAC authentication code, which is based on GHASH. If you're afraid of Galois fields, you don't get to use AES at all! Nobody should be implementing any of these primitives themselves, very much including CBC, which, as you saw downthread, left both you and the author of this project with an insecure cryptosystem. Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it!
    - dragontamer 4y ago
      > You keep saying "the Galois Field" as if that was a thing You're kidding, right? You've never looked at how GCM-mode works? The entire set of math is inside of the GF(2^128) field. That's why its called a Galois Counter Mode. I don't think anyone should be implementing their own GCM mode. Its very subtle and potentially full of traps. CBC on the other hand is pretty dumb and simple, and surprisingly secure and robust > Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it! If they're so common, you shouldn't have much of an issue naming one such vulnerability.
ThePhysicist 4y ago
AES-GCM is part of the Web Cryptography API and supported in all modern browsers, so no need to implement anything.
IncRnd 4y ago
You're misleading a lot of people with poor comments about implementation vs. design correctness. Design of systems that use crypto requires a specific kind of attention to detail.

tptacek 4y ago

I don't know what "being a stream" has to do with anything (you should virtually always use "stream" modes of AES); the meaningful distinction between CBC and GCM is that GCM authenticates the ciphertext, so you can't tamper with it.

tialaramex 4y ago
> so you can't tamper with it. ... if the API provided is correctly designed, and either the language made it practical to design the API in a misuse-resistant way /or/ the programmer was actually careful and used it properly. We both know it's way more likely the problem in your actual system is "Oops, we use the bogus plaintext here despite the validation error" than "Dastardly enemy cryptographers have made a breakthrough in cryptanalysis to attack our product".
- tptacek 4y ago
  I'm not thinking very hard about it; there is just never a reason to use unauthenticated encryption modes. When I wrote that comment, I hadn't even looked to see if they'd manually authenticated their ciphertext (spoiler alert: you can guess).
- ThePhysicist 4y ago
  SubtleCrypto (Web Cryptography API) will simply throw an exception if the authentication fails for AES-GCM, so there's no way to even get at the bogus plaintext.
forty 4y ago
Also I checked the code quickly, they do Cbc-hmac, and they check the Mac before decrypting so it seems fine. The 1000 rounds only of pbkdf2 on something that's essentially going to be available without any access control (since the encryption is the access control here) might be more annoying as the password can be human generated.

deleted 4y ago

[deleted]

411111111111111 4y ago

The readme links to this issue wrt that decision https://github.com/robinmoisson/staticrypt/issues/19 https://github.com/robinmoisson/staticrypt/issues/19 It seems that the hmac validation makes the GCM unnecessary in their thread model

IncRnd 4y ago

CBC is Cipher Block Chaining. I think you might be referencing that the incorrect use of CBC leads to chosen-plaintext attacks, chosen-ciphertext attacks, or padding oracle attacks. GCM is AEAD, providing ciphertext authentication. [1] For those reasons that you mention, use of encryption should always have a design review. [1] https://en.wikipedia.org/wiki/Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD) https://en.wikipedia.org/wiki/Authenticated_encryption#Authe...

yoble 4y ago

Thanks for the feedback! We had an issue opened around that topic where it seems to me that the weak points of CBC do not apply in the context of StatiCrypt. If you have more thoughts on this I'd love to hear them. Relevant comment here: https://github.com/robinmoisson/staticrypt/issues/19#issuecomment-1322389267 https://github.com/robinmoisson/staticrypt/issues/19#issueco...