5 ms·

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 x

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.
  - bawolff 4y ago
    > CBC doesn't have authentication. So add on an HMAC. Done Literally one of the most common things to fuck up when doing crypto yourself.
  - l33t233372 4y ago
    It’s unclear why you’re being so flippant about “adding on HMAC.” The things you are describing are difficult and dangerous for developers to build.
    - dragontamer 4y ago
      Mostly because we have a bloody simple use case in this topic. HTML uses some Javascript to encrypt a file. Then later, the Javascript decrypts the file and returns it to normal. This is a "beginner level" cryptography situation. Yes, I know there's all sorts of traps all around the field of cryptography. But I also know that this particular use case is simple enough that beginners can try their hand at it, and probably make something useful. And with low-probability of a critical error. ------------- Don't write your own AES-GCM implementation. Don't write your own TLS1.2 implementation. Etc. etc. There's all kinds of subtle errors involved. IVs, Padding, side-channels, man-in-the-middle... more than I can count and very subtle to think about. The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ to the use-case discussed in this github is proof enough. The community is a bit rabid over its "advice" on this subject.
      - l33t233372 4y ago
        > The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ I see what you’re saying, but the fact is that these hypotheticals are not irrelevant. They’re important intricacies and potential trip mines associated with implementing your own encryption.
        dragontamer 4y ago
        There are a myriad of encryption libraries that have been implemented, reimplemented, and redesigned by various hackers. In any case, I think reimplementing CBC is absolutely beginner level as far as implementation is concerned. Yes, you can be tripped up by various _uses_ of CBC, but the failure modes are extremely well studied at this point. Of course, a proper AEAD implementation would avoid that. But AEAD is commonly established today with GCM, which is not beginner level. So now we're trapped. What am I supposed to tell a young programmer who is interested in playing around with encryption on their own? Perhaps you wish to stop anyone from studying that subject. But on the contrary, I think the only way a programmer can truly learn this stuff is to implement the easiest stuff and try it out themselves from the ground up. -------- The _proper_ advice, is... don't write your own production encryption. But... if you have to, stick with the simplest implementation that avoids the most common errors (side channels, timing attacks, etc. etc.), and focus on the simplest use cases that have the largest amount of history. Of course, there's an entire class of crypto-bugs these days are found at the higher levels, in the "use of encryption" (ex: SSL3.0, TLS1.0, TLS1.1, etc. etc.). Nonce reuse, IV generation, in-advertent side channels due to padding oracles, etc. etc. Even a "perfect" implementation of CBC will come across these crypto-bugs (and is why modern algorithms do focus on AEAD from the ground up these days, which largely avoids the problem). So yes, there are a lot of traps and footguns in the world of encryption. But that's true of programming in general. Eventually, someone will want to make their own encryption, maybe the library doesn't work out just right (as is in this case: the Crypto-library doesn't have GCM mode implemented), and other modes need to be used. The use of CBC seems to be done properly here for static-HTML encryption.
- int0x2e 4y ago
  As the old quote goes - "if you are typing "AES" into your code at any point, and you are not a world-renowned crypto expert - you will get this wrong, guaranteed". There are so few cases of people who are not seasoned crypto engineers getting everything 100% correct that it's basically a myth, and in crypto, getting things "almost right" is the same as getting them wrong... I too loved playing with crypto - read a ton of books, attended some crypto classes in University, implemented some crypto systems which I thought were secure, etc. - but nowadays I wouldn't dare use anything that isn't considered secure by a large audience unless I had extremely good reason to do so.
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.

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.
- bawolff 4y ago
  > CBC doesn't have authentication. So add on an HMAC. Done Literally one of the most common things to fuck up when doing crypto yourself.
- l33t233372 4y ago
  It’s unclear why you’re being so flippant about “adding on HMAC.” The things you are describing are difficult and dangerous for developers to build.
  - dragontamer 4y ago
    Mostly because we have a bloody simple use case in this topic. HTML uses some Javascript to encrypt a file. Then later, the Javascript decrypts the file and returns it to normal. This is a "beginner level" cryptography situation. Yes, I know there's all sorts of traps all around the field of cryptography. But I also know that this particular use case is simple enough that beginners can try their hand at it, and probably make something useful. And with low-probability of a critical error. ------------- Don't write your own AES-GCM implementation. Don't write your own TLS1.2 implementation. Etc. etc. There's all kinds of subtle errors involved. IVs, Padding, side-channels, man-in-the-middle... more than I can count and very subtle to think about. The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ to the use-case discussed in this github is proof enough. The community is a bit rabid over its "advice" on this subject.
    - l33t233372 4y ago
      > The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ I see what you’re saying, but the fact is that these hypotheticals are not irrelevant. They’re important intricacies and potential trip mines associated with implementing your own encryption.
      - dragontamer 4y ago
        There are a myriad of encryption libraries that have been implemented, reimplemented, and redesigned by various hackers. In any case, I think reimplementing CBC is absolutely beginner level as far as implementation is concerned. Yes, you can be tripped up by various _uses_ of CBC, but the failure modes are extremely well studied at this point. Of course, a proper AEAD implementation would avoid that. But AEAD is commonly established today with GCM, which is not beginner level. So now we're trapped. What am I supposed to tell a young programmer who is interested in playing around with encryption on their own? Perhaps you wish to stop anyone from studying that subject. But on the contrary, I think the only way a programmer can truly learn this stuff is to implement the easiest stuff and try it out themselves from the ground up. -------- The _proper_ advice, is... don't write your own production encryption. But... if you have to, stick with the simplest implementation that avoids the most common errors (side channels, timing attacks, etc. etc.), and focus on the simplest use cases that have the largest amount of history. Of course, there's an entire class of crypto-bugs these days are found at the higher levels, in the "use of encryption" (ex: SSL3.0, TLS1.0, TLS1.1, etc. etc.). Nonce reuse, IV generation, in-advertent side channels due to padding oracles, etc. etc. Even a "perfect" implementation of CBC will come across these crypto-bugs (and is why modern algorithms do focus on AEAD from the ground up these days, which largely avoids the problem). So yes, there are a lot of traps and footguns in the world of encryption. But that's true of programming in general. Eventually, someone will want to make their own encryption, maybe the library doesn't work out just right (as is in this case: the Crypto-library doesn't have GCM mode implemented), and other modes need to be used. The use of CBC seems to be done properly here for static-HTML encryption.
int0x2e 4y ago
As the old quote goes - "if you are typing "AES" into your code at any point, and you are not a world-renowned crypto expert - you will get this wrong, guaranteed". There are so few cases of people who are not seasoned crypto engineers getting everything 100% correct that it's basically a myth, and in crypto, getting things "almost right" is the same as getting them wrong... I too loved playing with crypto - read a ton of books, attended some crypto classes in University, implemented some crypto systems which I thought were secure, etc. - but nowadays I wouldn't dare use anything that isn't considered secure by a large audience unless I had extremely good reason to do so.

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.