Hi all, first of all, a happy new year to all of you :-)
You might have read about the MD5 attack presented at 25C3. If not, read http://www.win.tue.nl/hashclash/rogue-ca/ or watch the talk at ftp://mirror.sys-panel.de/25c3-mirror/saal1/Tag4-Saal1-Slot15%3A15--ID3023-making_the_theoretical_possible-Main-2008-12-30T15%3A15%3A04+0100.wmv Possible countermeasures that were discussed during the talk are randomizing serial numbers as well as notbefore/notafter dates. And of course not using MD5 any more. I've checked in a patch that disallows usage of MD5 in end-entity profiles. Furthermore, I have just checked in a patch that automatically adds 8 bytes (64 bits) of randomness to the serial number. The serial number format now looks like this: [increasing part, optional] [random part, optional] [server id] as opposed to before: [increasing part] [server id] The database limits the total size of serial numbers to about 14 bytes, so with a standard server id width of 1 byte, this leaves 5 bytes (40 bit) for the increasing part of the serial number, which means a maximum numer of 1099511627776. I guess that should be enough for everybody :) If not, you can of course decrease the size of the random part. The corresponding configuration is in the endentity profile, the parameters are "increasing_serials" and "randomized_serial_bytes". The "increasing_serials" is a Perl boolean (e.g. 0, empty string for false, 1 for true, the default). This controls the increasing part, which can be left out if you want really random serials (you should then use the 13 bytes of randomness to make sure you don't accidentally end up with the same serial number for two certificates). The "randomized_serial_bytes" parameter controls how many bytes of randomness are added to the serial number, the default being 8. If for some reason you do not want the random serial numbers, you can go back to the status quo by using a increasing_serials value of 1 and a randomized_serial_bytes value of 0. I'll probably add randomization to notbefore/notafter later on (if one subtracts a (small, in the order of 1 day maybe) number from the notbefore date and adds a small number to the notafter date, that should be feasible and not disturb anyone) ... Cheers, Alex -- Dipl.-Math. Alexander Klink | IT-Security Engineer | [email protected] mobile: +49 (0)178 2121703 | Cynops GmbH | http://www.cynops.de ----------------------------+----------------------+--------------------- HRB 7833, Amtsgericht | USt-Id: DE 213094986 | Geschäftsführer: Bad Homburg v. d. Höhe | | Martin Bartosch
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
