5 ms·

Salt starts off with negative marks because they decided to type the letters A-E-S in their codebase: https://github.com/saltstack/salt/blob/develop/salt/crypt.

by lvh 14y ago

Salt starts off with negative marks because they decided to type the letters A-E-S in their codebase: https://github.com/saltstack/salt/blob/develop/salt/crypt.py#L281 https://github.com/saltstack/salt/blob/develop/salt/crypt.py... Specifically, they appear to be doing AES-CBC with HMAC-SHA256. There's nothing obviously wrong with it (randomized IVs from os.urandom, both authentication and encryption and with distinct keys...) but I would hope the standard for cryptography is higher than "nothing obviously wrong with it". Specifically, I would hope that the standard for cryptography is somewhere along the lines of using a peer-reviewed cryptosystem that has stood the test of time such as TLS, OpenPGP or even NaCl (given the name, particularly the latter would be pretty good). I'm not saying TLS doesn't have flaws; I'm saying appropriately configured TLS is better than rolling your own crypto. I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.

Orva 14y ago
> I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS. Yup, ZeroMQ doesn't support TLS.
- jacques_chester 14y ago
  You know it's weird, I've been noodling with ZeroMQ for about a year now and I just never connected those mental dots myself. Bugger.
  - Nrsolis 14y ago
    It's worth noting that 0MQ was developed as a library for HFT/algorithmic trading applications. In those environments, TLS isn't necessarily a requirement because it's a closed network. If you need TLS so your trading app can talk to the ticker-plant securely, you have bigger problems than you think.
    - lucian1900 14y ago
      Then it should not be used anywhere else. Since it is, it really should have TLS support.
kbutler 14y ago
http://docs.saltstack.org/en/latest/topics/index.html http://docs.saltstack.org/en/latest/topics/index.html """ Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic. """
- lvh 14y ago
  That explains the feature set, but it doesn't quite explain why it doesn't use TLS; TLS also starts with public key cryptosystems and then generates signing and symmetric encryption keys, oftentimes using precisely the same base algorithms (AES-256 and HMAC-SHA256). (Also, msgpack seems completely orthogonal to this issue.)
  - e12e 14y ago
    It's not really as easy as "use X library". As another commenter mentioned - using stunnel might be better than "rolling your own" based on well tested primitives, but "just using openssl" isn't necessarily a good solution, see eg this recent discussion: http://lists.randombit.net/pipermail/cryptography/2012-October/003376.html http://lists.randombit.net/pipermail/cryptography/2012-Octob...
mathrawka 14y ago
Yes, ZeroMQ doesn't have TLS support... you should use stunnel with it if you need an encrypted tunnel.
23david 14y ago
Seems like you're essentially saying that you don't trust it because it's not a peer-reviewed crypto system using TLS. Can you see that it's flawed in its specific implementation? This is a real community project. If you can see a way to improve something, just open a pull request on github.
dsl 14y ago
> I would hope the standard for cryptography is higher than "nothing obviously wrong with it" Can you please show me where that was the design decision that selected AES? Or are you just making an assumption that the code was not written by professional cryptographers and extensively peer reviewed? AES-CBC is still a perfectly valid safe choice for implementations today. The most successful attacks against it, are ironically, due to OpenSSL's poor implementation. (http://eprint.iacr.org/2010/594 http://eprint.iacr.org/2010/594)
- lucian1900 14y ago
  The point was that they wrote their own crypto on top of (the low level AES). That is a bad idea, especially since TLS has similar properties to their system.

by lvh 14y ago

Orva 14y ago

> I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS. Yup, ZeroMQ doesn't support TLS.

jacques_chester 14y ago
You know it's weird, I've been noodling with ZeroMQ for about a year now and I just never connected those mental dots myself. Bugger.
- Nrsolis 14y ago
  It's worth noting that 0MQ was developed as a library for HFT/algorithmic trading applications. In those environments, TLS isn't necessarily a requirement because it's a closed network. If you need TLS so your trading app can talk to the ticker-plant securely, you have bigger problems than you think.
  - lucian1900 14y ago
    Then it should not be used anywhere else. Since it is, it really should have TLS support.

kbutler 14y ago

http://docs.saltstack.org/en/latest/topics/index.html http://docs.saltstack.org/en/latest/topics/index.html """ Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic. """

lvh 14y ago
That explains the feature set, but it doesn't quite explain why it doesn't use TLS; TLS also starts with public key cryptosystems and then generates signing and symmetric encryption keys, oftentimes using precisely the same base algorithms (AES-256 and HMAC-SHA256). (Also, msgpack seems completely orthogonal to this issue.)
- e12e 14y ago
  It's not really as easy as "use X library". As another commenter mentioned - using stunnel might be better than "rolling your own" based on well tested primitives, but "just using openssl" isn't necessarily a good solution, see eg this recent discussion: http://lists.randombit.net/pipermail/cryptography/2012-October/003376.html http://lists.randombit.net/pipermail/cryptography/2012-Octob...

mathrawka 14y ago

Yes, ZeroMQ doesn't have TLS support... you should use stunnel with it if you need an encrypted tunnel.

23david 14y ago

Seems like you're essentially saying that you don't trust it because it's not a peer-reviewed crypto system using TLS. Can you see that it's flawed in its specific implementation? This is a real community project. If you can see a way to improve something, just open a pull request on github.

dsl 14y ago

> I would hope the standard for cryptography is higher than "nothing obviously wrong with it" Can you please show me where that was the design decision that selected AES? Or are you just making an assumption that the code was not written by professional cryptographers and extensively peer reviewed? AES-CBC is still a perfectly valid safe choice for implementations today. The most successful attacks against it, are ironically, due to OpenSSL's poor implementation. (http://eprint.iacr.org/2010/594 http://eprint.iacr.org/2010/594)

lucian1900 14y ago
The point was that they wrote their own crypto on top of (the low level AES). That is a bad idea, especially since TLS has similar properties to their system.