3 ms·

> Is Python actually suitable for cryptographic code, especially if constant-time operations are needed? No, but as seen in the first chunk of rust code added,

> Is Python actually suitable for cryptographic code, especially if constant-time operations are needed? No, but as seen in the first chunk of rust code added, the amount of logic that needs to be constant-time is a) very, very limited to a few primitives only b) algebraic in nature (put differently, it's not where memory bugs will pop up, so using rust over C doesn't even buy you much). For instance, ASN.1 parsing doesn't need to done in constant time in the vast majority of cases (and in all cases I am aware of). > And then when said logic stops being opt-in, why wouldn't the same problem arise? Some friction will certainly remains, but it will be nothing compared to the current breakage.

aw1621107 6y ago
> No, but as seen in the first chunk of rust code added, the amount of logic that needs to be constant-time is a) very, very limited to a few primitives only b) algebraic in nature (put differently, it's not where memory bugs will pop up, so using rust over C doesn't even buy you much). That's fair, though if some other part of the codebase is ported to Rust anyways sticking to C doesn't save you, unfortunately. > For instance, ASN.1 parsing doesn't need to done in constant time in the vast majority of cases (and in all cases I am aware of). I'm curious why this has to be done in C/Rust. Performance? > Some friction will certainly remains, but it will be nothing compared to the current breakage. What would be different then compared to now that would reduce breakage to such an extent?
- zimmerfrei 6y ago
  > That's fair, though if some other part of the codebase is ported to Rust anyways sticking to C doesn't save you, unfortunately. This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference. > I'm curious why this has to be done in C/Rust. Performance? ASN.1 is only used during handshakes and I/O of files (the chunk of rust added covers loading of PKCS#7 files which are typically quite small, and not typically dealt with in massive numbers). I doubt the performance hit would be so high. Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast. > What would be different then compared to now that would reduce breakage to such an extent? The ability to try the feature out and still have a plan B if it doesn't work out, and the possibility to have a smooth, long, relaxed upgrade plan with good warnings and more time to prepare. But to be honest, while writing all this chain of comments, I really doubt there was a real need to add rust into the mix (other than the political angle I already mentioned).
  - aw1621107 6y ago
    > This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference. I was thinking that if the maintainers were planning on porting some other larger part of the codebase, then starting with something small/relatively inconsequential would be a good first step, and keeping it in C wouldn't provide much benefit once said other larger part were ported. > Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast. Interesting! I'm curious why the maintainers didn't opt for that approach instead. > The ability to try the feature out and still have a plan B if it doesn't work out Would people have tried this feature out if it were made opt-in? It's clear that the initial announcements reached far fewer people than one might like, and I honestly have no idea how many people would see a build-time warning.

aw1621107 6y ago

> No, but as seen in the first chunk of rust code added, the amount of logic that needs to be constant-time is a) very, very limited to a few primitives only b) algebraic in nature (put differently, it's not where memory bugs will pop up, so using rust over C doesn't even buy you much). That's fair, though if some other part of the codebase is ported to Rust anyways sticking to C doesn't save you, unfortunately. > For instance, ASN.1 parsing doesn't need to done in constant time in the vast majority of cases (and in all cases I am aware of). I'm curious why this has to be done in C/Rust. Performance? > Some friction will certainly remains, but it will be nothing compared to the current breakage. What would be different then compared to now that would reduce breakage to such an extent?

zimmerfrei 6y ago
> That's fair, though if some other part of the codebase is ported to Rust anyways sticking to C doesn't save you, unfortunately. This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference. > I'm curious why this has to be done in C/Rust. Performance? ASN.1 is only used during handshakes and I/O of files (the chunk of rust added covers loading of PKCS#7 files which are typically quite small, and not typically dealt with in massive numbers). I doubt the performance hit would be so high. Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast. > What would be different then compared to now that would reduce breakage to such an extent? The ability to try the feature out and still have a plan B if it doesn't work out, and the possibility to have a smooth, long, relaxed upgrade plan with good warnings and more time to prepare. But to be honest, while writing all this chain of comments, I really doubt there was a real need to add rust into the mix (other than the political angle I already mentioned).
- aw1621107 6y ago
  > This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference. I was thinking that if the maintainers were planning on porting some other larger part of the codebase, then starting with something small/relatively inconsequential would be a good first step, and keeping it in C wouldn't provide much benefit once said other larger part were ported. > Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast. Interesting! I'm curious why the maintainers didn't opt for that approach instead. > The ability to try the feature out and still have a plan B if it doesn't work out Would people have tried this feature out if it were made opt-in? It's clear that the initial announcements reached far fewer people than one might like, and I honestly have no idea how many people would see a build-time warning.