4 ms·

> This shows crypto is much too hard. You can configure a bunch of things, but half the choices you can make (key length, exponent, etc...) will render your enc

> This shows crypto is much too hard. You can configure a bunch of things, but half the choices you can make (key length, exponent, etc...) will render your encryption worthless. I shouldn't have to know about the chinese remainder theorem to use crypto properly. This attitude scares me. Some things really are hard to do. Some things really are hard to understand. Some are even both. Remember what Euclid is supposed to have said to Ptolemy I of Egypt when the king complained that geometry was hard to learn: There is no royal road to mathematics! There's no shame in not being able to do or understand every difficult thing under the sun, but don't complain that such things "shouldn't be so hard". They often are. I think it's part of what makes life interesting.

norswap 13y ago
I expressed myself poorly. What I meant is that using cryptography shouldn't be that hard to use for the uninformed user. Introducing cryptography in an application is about security, and if we want more secure applications, cryptography should be easy as pie to use. Of course cryptography is hard, and it is an interesting topic (one I know a few things about as it turns out).
- jerf 13y ago
  I'm sort of split in the middle on the two sides here, but as an example of what I would hope for, in this case I'd say passing a 1 to this function in that location should have resulted in a run time error, not a happy useless implementation. Preferably with an error message that points to some helpful documentation on the topic. That's an example, that can't solve everything, and I'd despair of trying to fix every possible stupid error that way, but it would be helpful. That's not even really a "security" concern, that's just good software engineering. Passing this function something that fails the prerequisites ought to be checked. (And yes, I'd check that it's prime, too. It's an expensive check once, but trivially memoized, and you can even prefill the memoization with the usual 65537 value to make it even cheaper. In this particular case, IIRC, the exponent is always or nearly always simply reused,)
  - gizmo686 13y ago
    In this case, I think, the author rolled his own RSA implementation. In general, I do not know why the developer of end software should even touch the public exponent. It can be reused, and is not a secret; the library should handle it. In fact, the library should have a function along the lines of (publicKey, secretKey)=RSA.keyGen(), and provide the simple documentation that you want to keep the secret key secret. If they have crypto option which they want to expose (such as key-length), then they can take an optional parameter that either takes a hard-coded constant (IE RSA.512), or (as you suggest) validates the sanity of the input.

norswap 13y ago

I expressed myself poorly. What I meant is that using cryptography shouldn't be that hard to use for the uninformed user. Introducing cryptography in an application is about security, and if we want more secure applications, cryptography should be easy as pie to use. Of course cryptography is hard, and it is an interesting topic (one I know a few things about as it turns out).

jerf 13y ago
I'm sort of split in the middle on the two sides here, but as an example of what I would hope for, in this case I'd say passing a 1 to this function in that location should have resulted in a run time error, not a happy useless implementation. Preferably with an error message that points to some helpful documentation on the topic. That's an example, that can't solve everything, and I'd despair of trying to fix every possible stupid error that way, but it would be helpful. That's not even really a "security" concern, that's just good software engineering. Passing this function something that fails the prerequisites ought to be checked. (And yes, I'd check that it's prime, too. It's an expensive check once, but trivially memoized, and you can even prefill the memoization with the usual 65537 value to make it even cheaper. In this particular case, IIRC, the exponent is always or nearly always simply reused,)
- gizmo686 13y ago
  In this case, I think, the author rolled his own RSA implementation. In general, I do not know why the developer of end software should even touch the public exponent. It can be reused, and is not a secret; the library should handle it. In fact, the library should have a function along the lines of (publicKey, secretKey)=RSA.keyGen(), and provide the simple documentation that you want to keep the secret key secret. If they have crypto option which they want to expose (such as key-length), then they can take an optional parameter that either takes a hard-coded constant (IE RSA.512), or (as you suggest) validates the sanity of the input.