6 ms·
The Marvin Attack
- H8crilA 3y agoA much better link: https://people.redhat.com/~hkario/marvin/ https://people.redhat.com/~hkario/marvin/
- nolist_policy 3y agoGood to see that Google's BoringSSL (Chrome/Android) is not affected.
- jedisct1 3y agoAnd BoringSSL has excellent bindings for Rust (the "boring" crate), that support everything BoringSSL does, with a really good, easy to use API. And if you absolutely need to use pure Rust implementations, there's the "superboring" crate.
- cookiengineer 3y agoSide-note: This is the same guy that runs the securitypitfalls blog, which I highly recommend. [1] https://securitypitfalls.wordpress.com/ https://securitypitfalls.wordpress.com/
- dang 3y agoThanks! Changed from https://github.com/RustCrypto/RSA/security/advisories/GHSA-c38w-74pg-36hr https://github.com/RustCrypto/RSA/security/advisories/GHSA-c... above.
- kpcyrd 3y agoRSA has been known to be problematic for a very long time at this point, hopefully it just fades into obscurity soon and we can move on with less error-prone ciphers.
- cookiengineer 3y ago> less error-prone ciphers. ...such as? The paper also describes how all programming languages that use BigInt data types are likely to be affected. It also specifically refers to the ECDSA TLS attack from 2015, as well as the Minerva/Raccoon attacks which work in a similar way. As isogeny key exchange algorithms are likely to be all vulnerable after the SIKEp434, SIKEp503, SIKEp610, and SIKEp751 fiasco(s) of last year, I'm curious as to what kind of alternatives you suggest? Honestly, at this point I'd say anyone that makes these kind of claims that there even are "less error-prone ciphers" just hasn't worked long enough in cryptography to have learned otherwise. And I'd be bold to say it's probably all not possible due to how we design the CPU hardware and their memory interactions. Even if it's not the software (and it runs in constant time to prevent analysis) there have been lots of acoustic side channel attacks that were just analyzing the sounds that the transistors on the CPU make. So all your random no-op instructions are kind of useless against that, too. [1] Minerva attack: https://minerva.crocs.fi.muni.cz/ https://minerva.crocs.fi.muni.cz/ [2] Racoon attack against FDDH: https://raccoon-attack.com/ https://raccoon-attack.com/ [3] Key recovery attack on SIDH: https://eprint.iacr.org/2022/975.pdf https://eprint.iacr.org/2022/975.pdf [4] Acoustic recovery of GnuPG (RSA) keys: http://cs.tau.ac.il/~tromer/acoustic/ http://cs.tau.ac.il/~tromer/acoustic/
- pie_flavor 3y agoWhile timing attacks are not one of the ways RSA is more error-prone, it is still more error-prone, particularly regarding client secret selection.
- coppsilgold 3y agoThat is only because the way RSA key exchange has been implemented everywhere involves padding. RSA-KEM[1] has been available since forever and no padding is required, though no one uses it for some reason. RSA-KEM is also trivial to implement as it's virtually identical to textbook RSA, with the sole restriction that m has to be randomly sampled from 1 .. n-1. And just like that, no padding oracles. [1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism https://en.wikipedia.org/wiki/Key_encapsulation_mechanism> , <https://datatracker.ietf.org/doc/html/rfc5990 https://datatracker.ietf.org/doc/html/rfc5990>
- j16sdiz 3y agoMany languages just don't have the primitive to do time invariant code.
- shadowgovt 3y agoIs time invariance necessary to mitigate the attack, or would inserting pseudorandom delay from a source the attacker can't observe be sufficient?
- H8crilA 3y agoNoise can be removed by averaging results. It generally makes such attacks more expensive but still possible.
- nine_k 3y agoThe delays should not be noise-like. Determine, say, N = 10 points in the sensitive part of the algorithm. On startup / library initialization, assign N small random delays to these points. The delays stay the same in every invocation, creating a stable and unique timing profile. This,profile is hard / impossible to reproduce on a different machine for analysis and finding correlations. To make things funnier, a random delay parameter should randomly change every few weeks on long-running installations. This would render previous timing stats invalid, making known-plaintext attacks more difficult.
- comex 3y agoRealistic attacks tend to involve doing many different runs of the algorithm with different values of whatever input is timing-dependent. That includes this attack, where you’re doing many different TLS connections which result in different messages being decrypted, and the runtime depends on the message. If you couldn’t vary the timing-dependent input, then you could effectively only measure a single duration value per target; doing multiple runs would just reduce noise. It’s very unlikely that a single duration would have enough information to recover a full key. So this is already a hopeless scenario for the attacker. But if you can vary the timing-dependent input, then you can compare timing between different runs on the actual target machine; there’s no need to reproduce the exact timing profile on your own machine (which is very difficult anyway outside of small embedded CPUs). So a random delay per machine does not help. Adding delays to sensitive parts of the algorithm either would be equivalent to adding a single overall delay (if the number of delay invocations is constant), or would make the attack much easier (if not).
- kristjank 3y ago[flagged]
- SpaghettiCthulu 3y agoDid you even read? Many other libraries are also affected, including OpenSSL.
- beanjuiceII 3y agoya but, new language, problems still didn't change?
- topspin 3y agoTrying to recall where it was that Rust promised to fix all timing attacks.
- newpavlov 3y agoThe rsa crate is in the process of switching to https://docs.rs/crypto-bigint https://docs.rs/crypto-bigint, which should more or less fix this vulnerability. You can read more about it here: https://rustcrypto.zulipchat.com/#narrow/stream/260047-RSA/topic/switchting.20to.20crypto-bigint https://rustcrypto.zulipchat.com/#narrow/stream/260047-RSA/t...
- temp0826 3y agoAt least these vulns are memory safe. Whew!
- Ar-Curunir 3y agoYes, that is a good thing.
- pornel 3y agoThis is definitely harder to exploit than just reading the key via some UAF or buffer overflow.