4 ms·

This looks cool, but if the author is here, I wish they would actually explain the security rather than just citing AES-GCM, which doesn't really explain the se

by rsj_hn 5y ago

This looks cool, but if the author is here, I wish they would actually explain the security rather than just citing AES-GCM, which doesn't really explain the security design. How is the key material established, exactly? How is it rotated? How is it protected when stored? The answers to these questions are a lot more relevant to understanding the security of this application than citing which encryption mode is being used.

illuminated 5y ago
I'm not the author, but you have the encryption implementation here in the code: https://github.com/cs01/termpair/blob/master/termpair/encryption.py https://github.com/cs01/termpair/blob/master/termpair/encryp...
- rsj_hn 5y ago
  That's just an api to generate key and then wrap/unwrap. So OK, you generate the key in the server, and then have to get that over to someone who is using a web browser. How does that work? Then you have to store the key somewhere in the browser and in the server -- is it just in memory, in which case you have to get the key to the browsing user with each connection or if the browser is reloaded? Or is the key stored as a plaintext string on disk somewhere? Is it stored as a cookie in the browser? in gnome-keyring? and how is the key rotated? In other words, key management is the tricky part of all these protocols - is the author rolling their own authentication and key establishment protocol or using an existing one, and if the latter, which one and how are they using it? That's how you figure out the security of this cryptographic system. And remember that any secrets in the DOM loaded from origin X are exposed to code served from that origin, so what isolation guarantees are really being made when you want to make your terminal opaque to the webserver?
  - themgt 5y ago
    From a quick skim it looks like the key is base64 encoded into the URL in terminal_id param, so presumably you just share the URL and the collaborator stays on the URL with the key? If the key is ephemeral/regenerated for each session it seems to eliminate most of your concerns. https://github.com/cs01/termpair/blob/1d273fa306a543fefbf2cfa615f6b47eaadf49ea/termpair/share.py#L55-L57 https://github.com/cs01/termpair/blob/1d273fa306a543fefbf2cf...
    - tyingq 5y ago
      It does also put the key after a # mark in the url so that the browser isn't sending the key as part of the http request.
      - rsj_hn 5y ago
        that hash is still accesible to any javascript loaded from the server, right? And the hash is still sent in referer headers, IIRC (it's been a while since I looked at it)
        gruez 5y ago
        Hash isn't sent in the headers, but you're right, it doesn't protect against a malicious server stealing the secret via compromised javascript.
        rsj_hn 5y ago
        The server doesn't need to be compromised, as from the point of the user it is an independent security zone and loads whatever js it wants. Perhaps you could install a browser extension that would compute a hash of the js and only allow the load to proceed if it was verified, but apart from that your browser is going to execute whatever js the server loads. And that would be fine if the threat model was such that the server was trusted with the keys to the channel (because, for example, you control the server), but in that case what is the point of the end-to-end encryption, which is supposed to protect you from the server? If the server was trusted with the channel key, you can roll a much simpler system without end to end encryption. Again, this is why I was asking for an actual description of the security design. If you are trusting the server to handle the key, then you can really simplify this system. If you are not trusting the server to handle the key (which would be the case if it was not under your control), then this design doesn't appear adequate. I really wish these types of projects disclosed these types of design assumptions and operational details so that people could review the security efficiently instead of peering through code and trying to guess what the developer's intentions and assumptions are. It would also help the developers. If they are forced to write down: we don't trust the server to access the key but we must trust the server to not try to access the key, then such an exercise would hopefully trigger a moment of clarity that would lead to the creation of more secure systems. For example, they may want to include a browser extension under the control of the user as a part of the overall system, and have the browser extension touch the key in an origin not controlled by the server or have a key establishment protocol run between the browser extension and the ssh server with the webserver being just a transport layer.
- _nhynes 5y ago
  It could be made more resistant to birthday attacks by using the session message count as the IV, but I guess it wouldn't matter unless someone kept one of these terminals open for a really long time.
  - unscaled 5y ago
    I think it's important to clarify the statement above, for anymore who is not familiar with the issue and keeps misusing AES-GCM. AES-GCM has a relatively short IV (= nonce): only 96 bits (12 bytes). To make things worse, if an IV ever gets repeated GCM fails catastrophically[1]. The design document[2] explicitly point out that a FIPS 140-2 compliant GCM hardware[3], must take all possible precaution to ensure an IV never gets repeated, even if the device suffers a critical power loss. The safe way to use AES-GCM in software (for instance, the way it is used in TLS) is to just use a running counter and replace the key before the counter overflows and starts repeating itself. Random counters bad, since if enough messages are generated with the same key the chance of a message that repeats an IV under the same key increases. The statistic phenomenon behind the chance of something like that being repeated is called the "Birthday Problem"[4], so exploiting this kind of weakness is often referred to as a "Birthday Attack"[5]. tl;dr: If you want an easy life, just never use any form of AES at all. Most AES mode can be completely safe if used and implemented with care - but it is generally quite hard to do that. AES has too many knobs and there is too much bad advice on places like Stack Overflow and various blogs. Generally, for encrypting multiple messages with the same key, the solid advice is to use NaCl secretbox (XSalsa20-Ply1305) or libsodium aead_xchacha20poly1305_ietf[6]. But you probably need more than that when encrypting potentially long-lived bidirectional streams of data. --- [1]: It fails even worse than other authenticated counter mode ciphers due to the design of the GHASH function: https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf https://csrc.nist.gov/csrc/media/projects/block-cipher-techn... [2]: See section 9 here in NIST 800-38D: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli... [3] Keep in mind that like most 2000s vintage cipher specs, GCM was designed as a hardware cipher. Software was more or less an afterthought, if anything at all. [4]: https://en.wikipedia.org/wiki/Birthday_problem https://en.wikipedia.org/wiki/Birthday_problem [5]: https://en.wikipedia.org/wiki/Birthday_attack https://en.wikipedia.org/wiki/Birthday_attack [6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...
gruez 5y ago
>I wish they would actually explain the security rather than just citing AES-GCM Yeah, AFAIK there isn't really much difference between AES-GCM and any other AES + HMAC algorithm (eg. AES-SHA1) other than that AES-GCM is more performant. In this sort of use case, that's not really relevant, so it's strange to advertise it like it's some sort of feature.
- bawolff 5y ago
  I think you're confused on nomenclature here. GCM is both an authentication method and encryption mode. The big benefit is its all specified as one primitive because combining primitives is where people often screw up. HMAC-SHA1 is an authentication mechanism, there's various ways you can combine it with something like AES-CTR or AES-CBC to make something secure, but also plenty of ways to screw it up. Saying something like AES-SHA1 is meaningless because there's no standard way to combine those two, so you dont know what the person is doing, and you still dont know what the mode is.
  - rsj_hn 5y ago
    I don't believe they are confused about the nomenclature, as everything the parent said was correct. In terms of there not being standard ways to add an HMAC to an encrypted string, there are plenty of standard ways to do that. How do you think people implemented secure channels before Cisco released AES-GCM to speed up their VPNs? Just let attackers modify payloads? SSL/TLS, SSH, IPsec and many other widely used secure channel protocols were over a decade old before anyone standardized an authenticated encryption mode. But none of these widely used and well-standardized protocols require an authenticated encryption mode even though they all have both authentication and encryption as security properties. Authenticated encryption doesn't give you anything other than performance over the standard encrypt + tag approach (which is still widely used). And AES-GCM has some drawbacks that encrypt + tag do not (although the performance gains usually trump the drawbacks).
  - tptacek 5y ago
    AES+HMAC is harder to screw up than GCM, which is notoriously brittle. In particular: AES-CBC + HMAC doesn't fail catastrophically if randomness fails somehow, and GCM does.
fomine3 5y ago
Still a bit better than "Military grade encryption"

by rsj_hn 5y ago

illuminated 5y ago

I'm not the author, but you have the encryption implementation here in the code: https://github.com/cs01/termpair/blob/master/termpair/encryption.py https://github.com/cs01/termpair/blob/master/termpair/encryp...

rsj_hn 5y ago
That's just an api to generate key and then wrap/unwrap. So OK, you generate the key in the server, and then have to get that over to someone who is using a web browser. How does that work? Then you have to store the key somewhere in the browser and in the server -- is it just in memory, in which case you have to get the key to the browsing user with each connection or if the browser is reloaded? Or is the key stored as a plaintext string on disk somewhere? Is it stored as a cookie in the browser? in gnome-keyring? and how is the key rotated? In other words, key management is the tricky part of all these protocols - is the author rolling their own authentication and key establishment protocol or using an existing one, and if the latter, which one and how are they using it? That's how you figure out the security of this cryptographic system. And remember that any secrets in the DOM loaded from origin X are exposed to code served from that origin, so what isolation guarantees are really being made when you want to make your terminal opaque to the webserver?
- themgt 5y ago
  From a quick skim it looks like the key is base64 encoded into the URL in terminal_id param, so presumably you just share the URL and the collaborator stays on the URL with the key? If the key is ephemeral/regenerated for each session it seems to eliminate most of your concerns. https://github.com/cs01/termpair/blob/1d273fa306a543fefbf2cfa615f6b47eaadf49ea/termpair/share.py#L55-L57 https://github.com/cs01/termpair/blob/1d273fa306a543fefbf2cf...
  - tyingq 5y ago
    It does also put the key after a # mark in the url so that the browser isn't sending the key as part of the http request.
    - rsj_hn 5y ago
      that hash is still accesible to any javascript loaded from the server, right? And the hash is still sent in referer headers, IIRC (it's been a while since I looked at it)
      - gruez 5y ago
        Hash isn't sent in the headers, but you're right, it doesn't protect against a malicious server stealing the secret via compromised javascript.
        rsj_hn 5y ago
        The server doesn't need to be compromised, as from the point of the user it is an independent security zone and loads whatever js it wants. Perhaps you could install a browser extension that would compute a hash of the js and only allow the load to proceed if it was verified, but apart from that your browser is going to execute whatever js the server loads. And that would be fine if the threat model was such that the server was trusted with the keys to the channel (because, for example, you control the server), but in that case what is the point of the end-to-end encryption, which is supposed to protect you from the server? If the server was trusted with the channel key, you can roll a much simpler system without end to end encryption. Again, this is why I was asking for an actual description of the security design. If you are trusting the server to handle the key, then you can really simplify this system. If you are not trusting the server to handle the key (which would be the case if it was not under your control), then this design doesn't appear adequate. I really wish these types of projects disclosed these types of design assumptions and operational details so that people could review the security efficiently instead of peering through code and trying to guess what the developer's intentions and assumptions are. It would also help the developers. If they are forced to write down: we don't trust the server to access the key but we must trust the server to not try to access the key, then such an exercise would hopefully trigger a moment of clarity that would lead to the creation of more secure systems. For example, they may want to include a browser extension under the control of the user as a part of the overall system, and have the browser extension touch the key in an origin not controlled by the server or have a key establishment protocol run between the browser extension and the ssh server with the webserver being just a transport layer.
_nhynes 5y ago
It could be made more resistant to birthday attacks by using the session message count as the IV, but I guess it wouldn't matter unless someone kept one of these terminals open for a really long time.
- unscaled 5y ago
  I think it's important to clarify the statement above, for anymore who is not familiar with the issue and keeps misusing AES-GCM. AES-GCM has a relatively short IV (= nonce): only 96 bits (12 bytes). To make things worse, if an IV ever gets repeated GCM fails catastrophically[1]. The design document[2] explicitly point out that a FIPS 140-2 compliant GCM hardware[3], must take all possible precaution to ensure an IV never gets repeated, even if the device suffers a critical power loss. The safe way to use AES-GCM in software (for instance, the way it is used in TLS) is to just use a running counter and replace the key before the counter overflows and starts repeating itself. Random counters bad, since if enough messages are generated with the same key the chance of a message that repeats an IV under the same key increases. The statistic phenomenon behind the chance of something like that being repeated is called the "Birthday Problem"[4], so exploiting this kind of weakness is often referred to as a "Birthday Attack"[5]. tl;dr: If you want an easy life, just never use any form of AES at all. Most AES mode can be completely safe if used and implemented with care - but it is generally quite hard to do that. AES has too many knobs and there is too much bad advice on places like Stack Overflow and various blogs. Generally, for encrypting multiple messages with the same key, the solid advice is to use NaCl secretbox (XSalsa20-Ply1305) or libsodium aead_xchacha20poly1305_ietf[6]. But you probably need more than that when encrypting potentially long-lived bidirectional streams of data. --- [1]: It fails even worse than other authenticated counter mode ciphers due to the design of the GHASH function: https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf https://csrc.nist.gov/csrc/media/projects/block-cipher-techn... [2]: See section 9 here in NIST 800-38D: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli... [3] Keep in mind that like most 2000s vintage cipher specs, GCM was designed as a hardware cipher. Software was more or less an afterthought, if anything at all. [4]: https://en.wikipedia.org/wiki/Birthday_problem https://en.wikipedia.org/wiki/Birthday_problem [5]: https://en.wikipedia.org/wiki/Birthday_attack https://en.wikipedia.org/wiki/Birthday_attack [6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...

gruez 5y ago

>I wish they would actually explain the security rather than just citing AES-GCM Yeah, AFAIK there isn't really much difference between AES-GCM and any other AES + HMAC algorithm (eg. AES-SHA1) other than that AES-GCM is more performant. In this sort of use case, that's not really relevant, so it's strange to advertise it like it's some sort of feature.

bawolff 5y ago
I think you're confused on nomenclature here. GCM is both an authentication method and encryption mode. The big benefit is its all specified as one primitive because combining primitives is where people often screw up. HMAC-SHA1 is an authentication mechanism, there's various ways you can combine it with something like AES-CTR or AES-CBC to make something secure, but also plenty of ways to screw it up. Saying something like AES-SHA1 is meaningless because there's no standard way to combine those two, so you dont know what the person is doing, and you still dont know what the mode is.
- rsj_hn 5y ago
  I don't believe they are confused about the nomenclature, as everything the parent said was correct. In terms of there not being standard ways to add an HMAC to an encrypted string, there are plenty of standard ways to do that. How do you think people implemented secure channels before Cisco released AES-GCM to speed up their VPNs? Just let attackers modify payloads? SSL/TLS, SSH, IPsec and many other widely used secure channel protocols were over a decade old before anyone standardized an authenticated encryption mode. But none of these widely used and well-standardized protocols require an authenticated encryption mode even though they all have both authentication and encryption as security properties. Authenticated encryption doesn't give you anything other than performance over the standard encrypt + tag approach (which is still widely used). And AES-GCM has some drawbacks that encrypt + tag do not (although the performance gains usually trump the drawbacks).
- tptacek 5y ago
  AES+HMAC is harder to screw up than GCM, which is notoriously brittle. In particular: AES-CBC + HMAC doesn't fail catastrophically if randomness fails somehow, and GCM does.

fomine3 5y ago

Still a bit better than "Military grade encryption"