Open transactions could so nearly do this if only it used the math it claims it should be using instead of some apparently kiddie mockup version or "insufficient for real use" version of the math it claims it should be using. Darn, so close...
Hi guys!
I'm writing from the beautiful desert land of Sedona, AZ, where I'm on vacation for a few days.
I wanted to address this quote. FYI, Open-Transactions currently generates 1024-bit keys by default. Ultimately I would prefer that it uses 4096-bit keys instead of 1024, but that is not a terribly difficult fix to make. As more software is released based on OT, and as entities move closer towards actual production use, the keysize will be increased. (In other words, I wouldn't look at this as a deal-breaker, but rather as one of a long series of security fixes that naturally occur in this sort of project as it nears production.)
Similarly, the (untraceable) digital cash currently uses Lucre, which uses Wagner's algorithm and incorporates the SHA-1 hash. SHA-1 has had weaknesses uncovered over the past few years, though I'm not sure of their implications towards Chaumian blinding. This is fine: the whole idea of OT is similar to PGP: that it's easy to swap in new algorithms as the old ones expire. So on OT, it's not difficult to make new subclasses of OTToken and OTMint that use new algorithms.
(FYI, I have already obtained the source code for 2 new cash algorithms--Chaum and Brands--so these will be available within OT at some point in the future. Again, this is the sort of easy change that will probably happen once OT starts nearing production use.)
-Fellow Traveler
