4 ms·
Is there any auditing technique that could realistically find out, after the fact, how often this long-outstanding bug has been exploited over the years it has
by bcoates 13y ago
Is there any auditing technique that could realistically find out, after the fact, how often this long-outstanding bug has been exploited over the years it has been in place, like collecting a sample of presented certificates?
If we can't write perfect software, at least being able to quantify the damage would be a good start.
- e12e 13y agoWell, I suppose it might be a good idea for clients in general to log all certificates as they are presented -- the amount of data should be negligible. For a more organized approach there's always: https://www.eff.org/observatory https://www.eff.org/observatory I'm not sure if the data dumps contain the data needed to search for this bug in particular (but I suppose it should)? I wonder if moving most logic from these libraries to lua or guile might be a good idea -- and keep only the bare minimum in C/assembler (as I understand it, the key crypto algorithms need to be in something like C in order to be able to guarantee (as much as possible) against side-channel attacks). But I don't know if there are any real reasons to keep everything else in C (other than possibly that making things easier to port/compile/etc?).