New Group for MSE/PE
nhelke opened this issue · comments
Hi
I would like to use your library to implement the key-exchange part of MSE/PE. The spec requires P:
0xFFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9A63A36210000000000090563
And G = 2.
I could easily add a groupId #3 for the purpose but I see that you seem to be aiming for increasing length primes with your different cases.
Could you please suggest to me a way to add this group to your library in clean way, that fits your thinking, and without breaking backwards compatibility. If you tell me how you think it should be done, I will happily do it and submit a pull request.
Best,
Nicholas
The group Ids are assigned according to RFC 2409 and RFC 3526. Since there are too much copy&paste work, I only put group 14 in the code (which is usually a good choice for most applications), and randomly picked two other groups.
Can you find your group in those RFCs? I think group id 3 was assigned in RFC 2409, section 6.3.
If the group was not assigned an ID. I think we may have three options:
- Let user directly
newaDHGroupstructure. - Create another function to create groups which was not assigned an ID.
- Use negative values in
GetGroupfunction to represent unassigned groups. (and make sure id 0 be the default group, which is group 14 now.)
All options above seems valid to me. So feel free to submit your pull request. I would be happy to accept it. The major (only?) user of this library is uniqush-conn. As long as you can make sure it is safe, then you are good.
Thanks for you quick reply. The aforementioned prime does not appear to be in either RFC. If it is ok with you I'm going to write a patch to let users create their own groups. I think it is more flexible than using negative ids for non-standard groups.
Sure. Feel free to make your change.
Thank you.