This post contains (somewhat) technical discussion of (what I believe is) an important issue in integrating crypto with applications that do not contain their own cryptographic implementation. If that doesn't interest you, hit 'n' to resume your regularly scheduled flamefest. The issue is: how does the crypto provider authenticate the client? For example, if the crypto provider can accpet connections from any application in the user's process space, then any bogus application can easily start decrypting and signing as it likes. In this model, a precondition for security is that no bogus programs can be allowed to run. An alternative, slightly more complex model is that the client must somehow authenticate itself to the crypto provider. One simple way of doing this is to require the client request a password from the user, which is then forwarded to the crypto provider. The crypto provider will only provide service on connections which have been authenticated in this way. This model gives security even in the face of some bogus applications. Of course, as Nathaniel quietly reminded us this morning, any bogus application which can intercept keystrokes can subvert any such client authentication. Barry Jaspan (in his analysis of a security flaw in SSH 1.2.0) reminds us that access to the image of the process is also sufficient to break security. Perhaps the class of bogus programs which have enough capabilities to connect to the crypto provider, but not enough to intercept keystrokes or examine RAM is null, meaning that the two models have equivalent security. Actually, the simpler model has some security advantages, because the client never has to deal with any very sensitive material, such as the password. I'm interested in this question right now because the current version of premail implements the simpler model (in fact, it simply stores all the secrets in a file in /tmp, with permissions set to 600). I want to know whether it's worth the trouble to design and implement an approach based on per-client authentication. This issue is also relevant to the discussion of Microsoft's CAPI, which (as far as I can tell) allows only the simpler model. I'm not saying it's bad, but I do feel that the implications should be discussed. Thus, I have forwarded a copy of this post to cryptapi@microsoft.com in case they have any comments. If there's been a discussion of this that I missed, then apologies for brining it up again and appreciation in advance for any pointers. Raph