Comment by aw1621107 | Hacker News Reader

Comment by aw1621107 | Hacker News Reader

Parent Full thread

> So either that's still valid (and not too much of rust will come in to make a real difference security-wise) or they have revisited their position and will re-implement a bunch of openssl logic (in rust apparently though

Looks like it's the former. From the initial (?) GitHub issue discussing the move to Rust [0]:

> We do not plan to move any of the crypto under the scope of FIPS-140 from OpenSSL to cryptography. We do expect to move a) our own code that's written in C (e.g. unpadding), b) ASN.1 parsing. Neither of those are in scope for FIPS-140.

> and not in Python as it would be more logical

Is Python actually suitable for cryptographic code, especially if constant-time operations are needed?

> I don't see how it would have been an excessive burden to maintain such a small logic as an opt in for a period.

And then when said logic stops being opt-in, why wouldn't the same problem arise?

[0]: https://github.com/pyca/cryptography/issues/5381#issuecommen...

> 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.

> 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?

> 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).

> 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.

Reply on news.ycombinator.com