Permalink
53 comments
on commit
sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This comment has been minimized.
Edit: This user does not represent the Salt project or Salt Stack
Just to clarify, this is about the public exponent, not keysize.
It's of course questionable whether 1 (not a prime) was a good choice for the exponent to begin with, but it's hardly necessary to lose faith over this.
As for the padding, that is properly done on encryption.
So, all in all: good this was changed, but the world wasn't doomed before either.
This comment has been minimized.
Hehe, I was about to whack the Wikipedia article at you, but this isn't the issue.
Your explanation is sound, and I will just have to take your word, because quite frankly, I am not the professional cryptographer you want. I know crypto, but on a far higher level than mathematics. ;)
The commit should have fixed this once and for all, right?
Given that there were no reported compromises, there is no damage.
I am sure that Salt will at one point undergo an audit, that is if we don't change it all to SSH before (which we might well not). Would you want to volunteer?
This comment has been minimized.
Can I ask you to take a moment in Python or Ruby or something to actually try doing RSA with e=1?
RSA encryption is m^e%p. If e is 1, what is m^e%p?
This comment has been minimized.
Why was 65537 selected? Assuming correct padding and the 2048-bit RSA key size which I believe is your default, a smaller exponent like 3, would seem a better choice.
This comment has been minimized.
You should probably add 1 just to be safe and use 4.
You don't want to get bit by that trailing null.
This comment has been minimized.
e=3 is not a great choice; in the presence of other vulnerabilities, there are exploits that are easier to write on very-low-exponent RSA. 2^16+1 is the correct conservative choice.
This comment has been minimized.
Also, isn't private_encrypt(x, 5) asking for ANSI X9.31 message format?
This comment has been minimized.
@tqbf: surely, 65537 is better (and slower) than 3, but I fail to answer your earlier question because I don't know the precedence rules of ^ vs. % off the top of my head. ;)
Thanks for all the input.
This comment has been minimized.
A professional cryptographer did find this fault and evaluated the entire crypto sequence. This audit is what resulted in this change and the number selected was the recommended value to use.
With that said we are open to and continually seeking more analysis of the routines used.
Also, while I did not want to reveal it quite yet, I am working on an optional ssh transport system for Salt allowing Salt to run using just the ssh agent, although, of course, this makes Salt MUCH slower.
In the end, there are no known issues with the crypto in Salt today, and all security issues have been taken care of quickly, and publicly announced.
This comment has been minimized.
Can I ask you which professional cryptographer told you it wasn't a big deal to use "1" as your public exponent?
This comment has been minimized.
No, the cryptographer never told us that 1 was ok, he told us that the best choice was 65537 and that we should change it from 1 ASAP, which we did.
This comment has been minimized.
Oh, btw, I am not affiliated with Salt Inc.. I just use it and try to work towards sending push requests.
(There were people who thought I was an official representative, but it was just that my wife alerted me to the Twitter message.)
This comment has been minimized.
Tom Hatch: can you point me to the public announcement you guys did for the e=1 vulnerability? I'm interested in how you wrote it up. Thanks!
This comment has been minimized.
@tqbf: http://docs.saltstack.com/topics/releases/0.15.1.html#rsa-key-generation-fault
This comment has been minimized.
These represent the security issues found in the audit performed by Ronald Volgers
http://docs.saltstack.com/topics/releases/0.15.1.html
https://groups.google.com/d/msg/salt-users/JMXrTG6H9k0/vrbIeQ3u3lsJ
This comment has been minimized.
I think the larger question here is: why aren't you using TLS?
I will warn you in advance that "because we're using ZeroMQ" is a silly answer. This is at least the third vulnerability that has been found in your homebrew transport encryption, after the lack of a MAC and a timing attack. I hope you now realize that homebrewing your own transport encryption is a bad idea and you should seriously consider switching to TLS at this point to avoid future attacks.
This comment has been minimized.
I agree and am looking into working TLS into Salt, it is also noteworthy that we are actively working on an ssh transport system.
We are always looking for help and would appreciate help with getting TLS working in Salt and with ZeroMQ.
This comment has been minimized.
Ansible has a "fireball" mode by which they start a 0mq listener through SSH, but that does not actually solve the problem of the security of the 0mq channel.
I am 100% for TLS. SSH is a nice idea too, but probably will be too slow. Good to have as an option for small changes and bootstrapping though.
It's a shame 0mq doesn't do TLS itself.
This comment has been minimized.
@madduck: think of m^e%p as
pow(m, e, p)
. m raised to an exponent of 1 will always be m, when m is less than p.This comment has been minimized.
Shouldn't you ask for a CVE number to track this in downstream distributions?
This comment has been minimized.
I think bigon is right, this is a CVE worthy bug.
This comment has been minimized.
CVE CVE CVE
This comment has been minimized.
I recall hearing that a CVE was filed two months ago for this issue, when it was closed. I'm trying to track it down.
This comment has been minimized.
A CVE was issued, bt since ti was our first CVE it seems that there was a communication problem, thanks @kseifriedredhat for making sure this was filed, I will make sure these are filed in advance in the future
This comment has been minimized.
e=3 isn't a vulnerability, Kurt.
This comment has been minimized.
@kseifriedredhat, I was not involved in any of this process, but I had heard that one was filed. Thanks for getting us set straight.
This comment has been minimized.
@kseifriedredhat, yes, I submitted this to mitre right away, they allocated a CVE for it, but I must have dropped the ball somewhere since the CVE number that was given was not used on their end. I am conversing with Mitre to make sure that this does not happen again and that future security issues get CVEs allocated correctly.
This comment has been minimized.
Thanks!
This comment has been minimized.
No, Kurt, GPUs do not threaten e=3 RSA.
This comment has been minimized.
This paper does not say that GPUs threaten e=3 RSA, Kurt. It's about using GPUs to implement RSA efficiently, not about solving IFP or DLP with a GPU.
Exactly what made you think e=3 was a vulnerability?
This comment has been minimized.
Maybe because of this http://www.imc.org/ietf-openpgp/mail-archive/msg06063.html ? e.g. CVE-2006-4340 - AFAIK this was due to an implementation error of RSA and not a vulnerability of RSA itself.
This comment has been minimized.
e=3 is vuln to chinese remaindering: If you have three keys having e=3, modulus N1, N2, N3 and one message is encrypted using each key, then chinese remaindering allows calculating mod N1 x N2 x N3 and using an ordinary (continuous) cubic root.
Please PM me if you have questions on this.
This comment has been minimized.
Is there a particular reason why DTLS can't be used on top of 0MQ?
This comment has been minimized.
This comment has been minimized.
Yes, I saw that. I don't know much about 0MQ, but it looks to me like a good case for DTLS. Its usage is not as widespread as TLS, but it's still much better than a homegrown encrypted transport protocol.
This comment has been minimized.
What @yanosz explained is basically Coppersmith's Attack. The model of the attack involves low
e
such that the number of parties participating in the common encryption of a substantially similar plaintext is greater than or equal toe
. IIRC, in this case, decryption can be performed withoutd
,p
orq
in polynomial time... which is a Big Deal.This comment has been minimized.
This comment has been minimized.
Known vulnerabilities having been addressed doesn't mean there aren't many more not yet found. Furthermore, why waste time maintaining an encrypted transport protocol at all (regardless of the wisdom of doing so), when it would (eventually) be less work to use an established protocol.
This comment has been minimized.
@listrophy A corollary to that is if you have a "web scale" crypto system with more than 2^16+1 users and you use encrypted broadcasts your system may be vulnerable if enough of those individually encrypted broadcasts are hoovered up by an attacker (aka NSA).
This comment has been minimized.
You never encrypt the exact same message to more than one person in RSA, nor do you ever encrypt deterministically. This is an example of where e=3 makes a vulnerability that already exists easy to exploit, but not an example of an e=3 vulnerability. It's also the reason we have OAEP ("modern" RSA encryption). If you're passing plaintext directly to modexp to implement RSA encryption, you're boned no matter what public exponent you use.
This comment has been minimized.
@mattkeenan --- that is a corollary only if you are using RSA unsafely to begin with. In a competent RSA design, you'd never be passing deterministic plaintext directly to RSA; every message would be different by dint of padding. You must not ever use RSA without a secure padding scheme. RSA padding is not like block cipher padding; it's not a nicety, but instead absolutely required for the security of the system.
This comment has been minimized.
For the e=3 vuln, a quick google search yield this
I've forgotten most of the crypto I learnt, but the solving the cube root rings a bell.
This comment has been minimized.
The cube root attack is another that only works if you're using unpadded RSA, which is unsafe with any public modulus.
This comment has been minimized.
Yeah. This stuff changes fast - I remember an older copy of applied crypto used to recommend e=3, and then the text that I was using for crypto course explained what's wrong with e=3.
Really should find the time to brush up on this stuff...
This comment has been minimized.
Furgusen and Schneier, Cryptography Engineering, s 12.4.2, recommends e=3 RSA. But, don't use e=3, even though you can if you're careful.
This comment has been minimized.
How about implementing pyzmq ssh tunneling as an option?
http://zeromq.github.io/pyzmq/ssh.html
This comment has been minimized.
In response to this issue, @thatch45 has opened an issue to further improve salt's security model in the 0.17 release due mid-July:
#5913
"A few things to bring up here. First off, cryptography alone is not considered sufficient security, it is unwise to, for instance, expose ssh on the internet. Salt is a command and control system, it is unwise to expose ANY such system to the internet without aggressive firewall rules (any config management system, a system that contains code that manages a config management system or a system that contains keys allowing access to command and control systems)."
This comment has been minimized.
@kseifriedredhat Sounds like these are the approaches @thatch45 is considering in the next release ( 0.17, due mid-July 2013 ) to enhance the system security:
"The main goals in my mind with the present crypto in Salt are these:
Quoted from Saltstack Github Issue: #5913
This comment has been minimized.
Could 1. be "switch to OpenSSL-provided TLS"? TLS key handling can function like SSH's with a little massaging, so it's not fundamentally a worse user experience.
This comment has been minimized.
@lucian1900: did you leave a comment in the issue?
In general, I suggest to move the discussion there…
This comment has been minimized.
Ah, I missed the last line in that comment somehow.
This comment has been minimized.
TLS ought to be avoided for it's inherent complexity and unresolved issues / limited (secure) crypto configuration.
aside from an ssh-based tunnel, the proper solution here is to see through enhancements to libzmq or outsourcing salt's crypto to a more common library like NaCl/pycrypto/etc/
This comment has been minimized.
Those
os.umask
calls look odd. Are there multiple threads when this code runs?