Conversation
Jarkko Sakkinen
jarkko
Edited yesterday
Software crypto would really need its own "official" systemd service as that way any application could have audited crypto. I.e. crypto operations would be executed by that service and results returned back to the caller. It could probably be just user service running inside session in order to guarantee better privacy.
This is partly because Rust does not have a proper DSO support, and this would address this flaw in Rust. It is not a question how great some random crate is but more like can you make software that can be used in production as per standards that companies use.
E.g., I cannot recommend to use tpm2sh to use anything else except kernel testing for this exact reason no matter how the crates are implemented or how well I might orchestrate the calls.
This is partly because Rust does not have a proper DSO support, and this would address this flaw in Rust. It is not a question how great some random crate is but more like can you make software that can be used in production as per standards that companies use.
E.g., I cannot recommend to use tpm2sh to use anything else except kernel testing for this exact reason no matter how the crates are implemented or how well I might orchestrate the calls.
1
0
1
It would be comptetitive advantage for Rust to have first class DSO support. It's like 99% of things Rusts static linking model is exactly right thing to do but for 1% of use cases you should just have a DSO.
Prime examples:
- Core crypto libraries. These need to be hotfixe when CVE arises.
- Core graphic libraries.
- System GUI libraries.
Prime examples:
- Core crypto libraries. These need to be hotfixe when CVE arises.
- Core graphic libraries.
- System GUI libraries.
1
1
1
Haelwenn /элвэн/ 
lanodan@queer.hacktivis.me
@jarkko I think this relies on the assumption that cryptographic libraries vulnerabilities are from their core, like the math part of them.
Which while it's true for some side-channels attacks, there's a lot more on parsing (protocol, x509, …). So a separated service probably wouldn't help much there, unless it's one like TLS where it's pretty much a layer of encapsulation and you could use something like stunnel.
Which while it's true for some side-channels attacks, there's a lot more on parsing (protocol, x509, …). So a separated service probably wouldn't help much there, unless it's one like TLS where it's pretty much a layer of encapsulation and you could use something like stunnel.
1
0
0
Jarkko Sakkinen
jarkko
@lanodan it does not rely on assumptions. it is more like that in production you often need to have somehow certified/audited crypto. I.e. it is irrelevant how strong or weak the crypto is in some sense as long as it has gone through that process.
thus, statically linked crypto is a problem.
also it is a problem even when the crypto would audited that you can only hotfix all deployed rust by updating all possible rust programs. it's much easier to hotfix a single crypto entity, which could be DSO.
thus, statically linked crypto is a problem.
also it is a problem even when the crypto would audited that you can only hotfix all deployed rust by updating all possible rust programs. it's much easier to hotfix a single crypto entity, which could be DSO.
1
0
0
@lanodan it's a special corner case and i'm talking about deployments at scale of even hundreds or thousands nodes and fucking armed guards and shit xD usually corps have this thing called Secure Development Lifecycle (SDL) process that everything to needs to comply and it is hard to map to bunch of Rust programs with random versions of random crypto.
1
0
0
@lanodan It's like with Rust ecosystem that they've made the right analysis of situation i.e. for most stuff we put everything to somekind of container etc. and for 99% of stuff we pile it's great call.
But the thing is nothing ever works ideally except maybe computer science class and there is 1% where that makes absolutely no sense. So to level up I'd address these type of details too, and accept the reality. Up until that Rust is pretty much destined to be a Java for system programming sandboxed by C based ecosystem.
But the thing is nothing ever works ideally except maybe computer science class and there is 1% where that makes absolutely no sense. So to level up I'd address these type of details too, and accept the reality. Up until that Rust is pretty much destined to be a Java for system programming sandboxed by C based ecosystem.
0
0
0
Haelwenn /элвэн/
lanodan@queer.hacktivis.me
@jarkko I'm not disagreeing with the DSO bit, I think this one would be fine.
The system service on the other hand seems a lot of a problem for wholistic security (which is typically ignored by certification but isn't necessarily incompatible).
The system service on the other hand seems a lot of a problem for wholistic security (which is typically ignored by certification but isn't necessarily incompatible).
1
0
1