Re: Read random bytes from Gnuk potentially frequently without destroying the card
Damien Goutte-Gattat wrote: > In the specific case of the Gnuk token, the GET CHALLENGE command is > implemented using the same logic as the one used in NeuG [2]. I have not > looked in details how NeuG works, but given that it is specifically intended > as a random number generator, I’d say it’s safe to assume than using it as > intended cannot ”destroy the token”. :) No, it never destroy the token. So, for Gnuk Token, use it freely. > # RANDOM > # > # Get NBYTES of random from the card and send them back as data. > # This usually involves EEPROM write on the card and thus excessive > # use of this command may destroy the card. I didn't know this help text. I think that it's specific to Zeitcontrol card. For Gnuk on STM32F103 (not the emulation version), it runs ADC (Analogue to Digital Converter) for randomness. It never destroy anything. While intended usage of ADC is measurement of some analog input, we use ADC to get noise (in theory, each sample has 0.5-bit of information, nobody knows). -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Read random bytes from Gnuk potentially frequently without destroying the card
Hi, On Sunday, 20 November 2022 04:59:32 GMT John Scott via Gnupg-users wrote: > I'd like to try writing a program for my libreCMC router that feeds the > Linux entropy pool with data from the token's true RNG. FYI, I wrote a similar program a few years ago: scdrand [1]. It uses Scdaemon’s RANDOM command to extract random bytes from any Scdaemon-supported token (be it a Gnuk token, an actual smartcard, a Yubikey, etc.) and feed them to the kernel’s entropy pool. I am not really using it anymore because I found that I had no longer any need for it with recent Linux kernels, but it should still work. Of course, this should not dissuade you from writing your own program. :) > I also notice that OpenSC has the feature to get an arbitrary number of > random bytes from the card with its OpenPGP module […] does this > probably use the same mechanism under-the-hood Yes. Both Scdaemon’s RANDOM and pkcs11-tool’s --generate-random work by sending the token a ISO7816 "GET CHALLENGE" command, which instructs the token to send back random bytes. Whether “excessive use” of that command end up damaging the token, and what is “excessive use”, ultimately depends on how that command is implemented token-side. In the specific case of the Gnuk token, the GET CHALLENGE command is implemented using the same logic as the one used in NeuG [2]. I have not looked in details how NeuG works, but given that it is specifically intended as a random number generator, I’d say it’s safe to assume than using it as intended cannot ”destroy the token”. :) Hope that helps. - Damien [1] https://git.incenp.org/damien/scdtools [2] https://www.gniibe.org/memo/development/gnuk/rng/neug.html signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Read random bytes from Gnuk potentially frequently without destroying the card
Hi all, Just for fun and because I have extra Gnuk tokens lying around, I'd like to try writing a program for my libreCMC router that feeds the Linux entropy pool with data from the token's true RNG. The help text for scdaemon states > # RANDOM > # > # Get NBYTES of random from the card and send them back as data. > # This usually involves EEPROM write on the card and thus excessive > # use of this command may destroy the card. I note that the help text says "usually." Can anyone confirm whether Gnuks specifically do a ROM write in this case? If they still do the write, I have a follow-up question. I also notice that OpenSC has the feature to get an arbitrary number of random bytes from the card with its OpenPGP module (it's not limited to 256 like requests to scdaemon are), like this: $ pkcs11-tool --generate-random 1024 I realize this isn't the list for OpenSC questions, but does this probably use the same mechanism under-the-hood and hence invoke a write as well, or is there a chance that it avoids the write? Thanks for the excellent libre software, and happy hacking signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users