Possible bug or opportunity for user error with admin/user password

Frédéric SUEL frederic.suel at free.fr
Thu Jan 31 10:56:51 CET 2019


I confirm that chinese ST-DONGLE V2 clone is running too. I find a clone
call "MX-LINK V2 of 2018-02-18" which has two leds and a STM32F103CBU6
(72 Mhz) processor instead of STM32F101CB1b (36 Mhz) as usual in this
type of clone. For the usual clone, you have to change in configure MHZ
from 72 to 36 before to compile.

I confirm too that MX-LINK V2 clone run fine as NEUG TRNG on Debian.

It can be find in some Chinese vendors, the picture on the clone is a
big M instead of noting or a big ST.


Le 31/01/2019 à 08:19, NIIBE Yutaka a écrit :
> Hello,
> BTW, I'm glad to see Gnuk on ST_DONGLE is running.  It might confuse a
> border official effectively, when there is such an opportunity.  No, I
> don't have any experience, though.
> I know the issue in question.  I reported in 2011 to GnuPG mailing list,
> and had a note:
> https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html
> Peter Lebbing <peter at digitalbrains.com> wrote:
>> Hmmmm, even then I think it's overzealous optimization, given the
>> problem at hand. You'd need one byte more in your packet buffer, but
>> will CHANGE REFERENCE DATA often be the largest packet in your card
>> application (and hence determine the size of your buffer)? Even if that
>> were the case, they should have thought of a clever solution :-).
>> I suspect they simply forgot this special case, thinking "the length is
>> known", without asking themselves "to whom?".
> I have same suspect.
> Anyway, my "solution" is using KDF feature.  With KDF feature, the
> length is fixed, so, no such problem.
> I think that KDF feature is mature, now.  Having GnuPG 2.2 in Debian
> backports, I can promote the use this year.  I will write a short howto.

More information about the Gnuk-users mailing list