[from a discussion of tamper-resistant hardware for payment systems on dbs@philodox.com, a mailing list dedicated to digital bearer systems, where Scott Loftesness, of DigiCash and Arcot Systems, mentioned ArcotSign.] You mentioned the URL for Arcot, and I looked at the site. It seems rather lacking in technical details, and makes a very strong claim -- that it can provide tamper resistance in software on a hardware/OS/etc. platform which is generally hostile (a general purpose computer). I noticed that there are some big name cryptographers signed on as advisors -- Hellman and Schneier, who make some pretty glowing comments about the product. I'm not generally swayed by anything but mathematics, physics, and logic when it comes to cryptography and security, despite generally agreeing with the analyses of those cryptographers. I can see a couple of ways you could approximate real security using untrusted hardware -- either a one time password system retained by the user (I've investigated this in the past, and it generally ends up being a hardware token or a printed book of codes), or a remote system like Kerberos where there exist out of band key protection mechanisms, or it's not real security. I'd love to be convinced otherwise, particularly if the technology will be available for others to license. I also noticed that the system is patent pending -- this would seem to rule out the existing hardware token/one time pad system, or the Kerberos-style central authentication server releasing security credentials when presented with a passphrase system, as there are decades of prior art in each encompassing all reasonable variations. I guess this means it's something new and interesting -- I'm sure everyone would be interested in details. Of course, in any system where all you do is authenticate yourself to a remote system, but you're not provided with a link directly between the user and the remote authority guaranteeing Confidentiality, Integrity, and Authentication, you can't really make any claims other than that the user has authenticated herself to some server -- any transactions the user could do are subject to a man in the middle attack, so while the user has successfully authenticated themselves to a remote server, and signed that *some* transaction is acceptable, there's really no legal assurance that the user has signed *any particular transaction*. This is far weaker than the promise of trusted hardware, where you could have a guarantee that as long as the protocol hasn't been violated, the user has authorized a *particular* transaction. This may be acceptable for authenticating access to an online retail banking web site, or corporate information, but it would not be sufficient for an actual payment system (DBS, account based, or other). Always interested in learning something new which would chance my assumptions, Ryan rdl@mit.edu