Possible bug or opportunity for user error with admin/user password
mike at sowbug.com
Wed Jan 30 16:22:58 CET 2019
Peter, that's a pretty wacky design decision. Thanks for spelling it out
for me. Next time I set up a new key, I'll verify that this was in fact the
issue. Meanwhile, I hope that our record of this discussion rescues another
person from an exasperating experience in the future!
On Wed, Jan 30, 2019 at 3:07 AM Peter Lebbing <peter at digitalbrains.com>
> I think your new password is now "78thisismypassword".
> There's an annoying design deficiency in the OpenPGP Card
> specification. It says this:
> > The length of the existing password is known in the card, so that
> > neither a delimiter nor padding for filling up fixed formats is
> > necessary for UTF-8. The length of the new UTF-8 password therefore
> > computes L new = Lc – L old.
> Do you see the problem? :-)
> The data field for changing OLDPIN to NEWPIN is formatted as:
> The data field that is sent when you specify the old PIN as OLDPINBAD
> and the new PIN as NEWPIN is:
> So the pin is changed to BADNEWPIN.
> So any suffix you accidentally add to the old PIN becomes a prefix to
> the new PIN.
> This is in the specification, not the GnuK implementation :-(.
> And the mistake in the reasoning of the specification is that even
> though the card might be completely certain of the length of the old
> PIN, the user might not be. Add default PINs that only differ in suffix,
> and we get a trap sprung for the unsuspecting user.
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnuk-users