4 ms·
TFA says the GnuPG code is pretty rough. Has anyone (with crypto knowledge) looked at it? Confirmations and denials welcome.
by gcv 12y ago
TFA says the GnuPG code is pretty rough. Has anyone (with crypto knowledge) looked at it? Confirmations and denials welcome.
- tptacek 12y agolibgcrypt is pretty rough, yes. The plus side is that GnuPG by design has a relatively limited attack surface. It's tough to conduct a side-channel attack that requires thousands of message stimulus-response tests to get a single key or message bit, given that each iteration of that attack will (in typical GPG usage) require manual intervention. As long as your crypto isn't "online", GPG is still a pretty safe bet. You can't say the same thing about a lot of newer crypto libraries. However, if you're doing something like encrypting a session cookie, you should use Nacl, not GPG.
- hellbanner 12y agoCan you expound on your last point?
- deleted 12y ago[deleted]
- girvo 12y agoIf you assume the rest of his comment is true (I'm no crypto expert but it seems intuitive enough for me, and he is a crypto expert!), having something like a session cookie (which can be attacker controlled) encrypted with GPG (which means it's now "online", without manual intervention) has now increased the attack surface considerably; it gives up the neat offline part of GPG and makes it easier to attack. That's how I understood it anyway!
- tptacek 12y agoYep.
- tedunangst 12y ago> each iteration of that attack will (in typical GPG usage) require manual intervention. How long do you think that will last when everyone encrypts all their email?
- peri 12y agoNot much to add here myself other than something for the folks who are less steeped in networking and security concerns: you should not try to audit this stuff yourself. Parent to this post can help you find a good auditor for your language. It's very tempting, especially for smart, multilingual, incredibly talented individuals to just roll this as if the libraries below you don't matter. Crypto is, unfortunately, the leakiest of the leaky abstractions you can end up building on. No matter what, I always have someone else (and preferably several someone elses) check my work when it comes to authentication systems and encryption. IANAL,EIIWTWNBFLA,UHTPMTGMROOTS. tpateck is a much better person to talk to than me if you need to find someone to help you deal with these issues most subtle.
- jessaustin 12y agoOk, I've got "Even If I Were This Would Not Be Free Legal Advice", but "UHTPMTGMROOTS" stymies me.
- peri 12y agoTo be honest, I'm not quite sure what I meant 18 hours later, but I think it was a joke about folks who know what my DCI number is.
- JoshTriplett 12y agoIt has gotten a lot better lately. It was designed in the era before people quite realized that everything should be a library first and an application using that library second, and that still shows. However, the most recent version pulls all the interesting cryptographic operations out of the application and puts them into gpg-agent, paving the way for a future libgpg that holds no key material and just asks the agent to perform signing/encryption operations. I'm really looking forward to that.
- joeyh 12y agogpg is crucial software, find a hole and you get your name in lights. I assume security researchers are looking at it all the time. Here's what they've found lately: CVE-2014-4617 (DOS only) CVE-2013-4576 (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis -- awesome, but not exactly practical) CVE-2013-4402 (DOS only) CVE-2013-4242 (RSA side channel attack) CVE-2012-6085 (invalid keys could corrupt memory) -- 5 years with not a single security hole -- CVE-2007-1263 (bug in signed message verification) Compare this with the security history of the browser you are using to view this comment, and weep..