Hello, While the discussion proceeds, I can't determine which post I should reply. Well, I think I reply to this post.
On 09/30/2015 10:37 PM, Laurent Blume wrote: > The thing is, I asked around (on some other lists), and had a look at > HSM's, we even have a hundred thousands € worth of HSM, used for > something completely different. > But that's the thing: those very expensive thingies, they come with an > API and a manual, you «only» need to develop your application around it. > The NitroKey (and others like it) are both cheaper and easier to deploy > using off-the-shelf software (at least it looks so on paper). > That said, maybe the Pro model is not the right one, and I made a > mistake there out of ignorance. I think that Nitrokey series would be a right solution, both for hardware-wise and their perspective. As Peter suggested, I feel that your use case is not directly related to OpenPGP. It seems that you just need simple (non-interactive) public key authentication. IIUC, I believe that Nitrokey community would be best place for such a use case. I guess that they are open to diverse use cases other than OpenPGP, while I have narrow/tight perspective for my Gnuk Token, specifically limited to OpenPGP. I think that it is not that technically difficult to write an application to access Nitrokey (something) for simple non-interactive public key authentication. If you say you made a mistake, it's just that it has not been directly supported by existing tool of GnuPG and its friends. > My impression is that there are no middle-ground options between the > cheap, personal use device and the super-expensive brick. > If you do have suggestions, they're very welcome. I'm still assessing > feasibility, and able to change directions. OpenPGPcard compatible assumes it's users who control their computing. This can be done by reasonable cost, because there are less conflicts. Most smartcard/token applications assume that it's a company (or other entity) who should control "consumers"' computing. This is a different problem to solve, and some expensive solution is only to be expected, naturally, --- no wonder. -- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
