-
Notifications
You must be signed in to change notification settings - Fork 7.3k
crypto: allow custom generator for DiffieHellman #7086
Conversation
Thank you for contributing this pull request! Here are a few pointers to make sure your submission will be considered for inclusion. The following commiters were not found in the CLA:
You can fix all these things without opening another issue. Please see CONTRIBUTING.md for more information |
this._binding = new binding.DiffieHellman(sizeOrKey); | ||
if (keyEncoding) { | ||
if (typeof keyEncoding !== 'string' | ||
|| (!Buffer.isEncoding(keyEncoding) && keyEncoding !== 'buffer')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please place ||
at the end of the previous line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wasn't fixed.
Incorporated suggested changes. |
return ThrowError("off + len > buffer.length"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove braces, they are unnecessary here and only adding excessive changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, I added them out of habit since that used to be the style for the C++-side of node stuff.
Incorporated additional suggested changes. |
|
||
if (!sizeOrKey) | ||
this._binding = new binding.DiffieHellman(); | ||
throw new Error('Initialization failed'); | ||
else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess else
is not required anymore.
I just found something interesting while adding another test.... Currently the Init() that takes in two buffers does not call VerifyContext() after setting up dh->p and dh->g and also DiffieHellmanGroup() does not check the return value of that Init(). So what has been happening all along is that whenever you use one of the built-in 'modp' groups, no errors occur because these checks are not being done, but in reality an error (DH_NOT_SUITABLE_GENERATOR) is being set (at least for modp1) and is ignored. The issue of ignoring/enforcing this particular error was discussed in #2338. So we need to decide whether we should always check for errors in all Init() methods, ignore this particular error everywhere, or make the error simply a warning somehow. |
@mscdex I think it should throw, unless @bnoordhuis could weigh in with some objections. |
Generally your PR LGTM |
Ordinarily I would agree that it should throw on the error (DH_NOT_SUITABLE_GENERATOR), but in my particular case with ssh 2, modp1 and modp14 are still used out in the wild since not all servers have the DH group exchange support yet. So that means I would have to ignore the error with a try-catch, possibly resulting in some v8 deoptimizations which I would prefer to avoid. |
Sorry, could you please write some explanation about it. Is this error not fatal? I'm afraid I'm not really aware of all aspects of this topic. |
DH_NOT_SUITABLE_GENERATOR (probably along with DH_CHECK_P_NOT_SAFE_PRIME) is more of a warning than a fatal error. It's basically alerting you to the fact that OpenSSL thinks the generator supplied is insecure because of some mathematical properties of using certain primes and certain generators together. There was some discussion about this on the OpenSSL-dev list back in 2002 and there was a SO question about it with a fairly good answer/description of the problem. Additionally from RFC 2412 (which defines some of the groups in node's 'modp*' groups):
I think that either all DH_check() errors except DH_NOT_SUITABLE_GENERATOR (and possibly DH_CHECK_P_NOT_SAFE_PRIME) should throw and we set some properties on the DH object to indicate non-suitable generator and/or unsafe prime, or we allow a boolean to be passed in to allow skipping of DH_check() altogether. |
Anyway, let's add |
Or set a error property like |
Alright, how does that look? |
`'base64'`. If no encoding is specified, then a buffer is expected. | ||
Creates a Diffie-Hellman key exchange object using the supplied prime and an | ||
optional specific generator. | ||
Generator can be a number, string, or Buffer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use:
`generator`, `prime_encoding` and `generator_encoding`
Very minor style nits, otherwise LGTM |
@@ -3139,6 +3141,9 @@ void Verify::VerifyFinal(const FunctionCallbackInfo<Value>& args) { | |||
void DiffieHellman::Initialize(Environment* env, Handle<Object> target) { | |||
Local<FunctionTemplate> t = FunctionTemplate::New(New); | |||
|
|||
enum PropertyAttribute attributes = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be a static variable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, I was just basing that on another instance of PropertyAttribute usage elsewhere in node core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok then :P We will address it later.
Fixes made. |
Thank you, landed in a226be4 |
Fixes #7075.