Mailing List Archive

scd bug: specifying 'e length' for RSA key-attr unsupported
Hi everyone,

I'm trying to use GPG with smartcards, and ran across what appears to be
a bug in scdaemon when using both RSA and ECC keys.

Specifically, the KEY-ATTR command does not accept 'e bit length' as an
argument. scdaemon simply re-uses whichever value the card defaults to
if you change the RSA key length... but the real bug here is that when
switching back to RSA from an EC algorithm, scdaemon hardcodes the 'e
bit length' to 32.

This is in scd/app-openpgp.c:change_rsa_keyattr(), line 3254 (GnuPG 2.2.8).

This is problematic for smartcards that don't support an 'e length' of
32. The attribute change is rejected because of the unsupported value,
and the card is effectively stuck with an EC curve unless completely
reset. Example output of this failing is in the snippet below my signature.

Note that this is a likely case: the OpenPGP on Smart Card spec (v3.3.1)
specifies 65537 (bit length 17) as the only value required to be
supported, and as the default to use if none is specified. The protocol
does not support specifying 'none', so GPG does have to specify
something when changing the algorithm.

It is also a limitation for cards that support multiple 'e' lengths, in
that there is no way to change it from the default. That is more of a
missing feature than a bug. There is a strange edge case of smartcards
that support both lengths of 17 and 32 bits: you can change from 17 to
32 by changing the algo from RSA -> ECC -> RSA, and then you are
permanently switched to a 32-bit e length.

I believe this needs to be fixed in one of two ways:
1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI)
2) use '17' instead of '32' as the hard-coded length, since all cards
are required to support it

Please let me know if this makes sense, or if I'm mistaken about something.

Thanks,

Trevor

--
$ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
OK
$ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye
OK
$ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
ERR 100663351 Invalid value <SCD>
--

--
scdaemon[56643] DBG: send apdu: c=00 i=DA p1=00 p2=C1 lc=6 le=-1 em=0
scdaemon[56643] DBG: PCSC_data: 00 DA 00 C1 06 01 08 00 00 11 00
scdaemon[56643] DBG: response: sw=9000 datalen=0
scdaemon[56643] DBG: dump:
scdaemon[56643] key attribute changed (key=1)
...
scdaemon[56643] DBG: send apdu: c=00 i=DA p1=00 p2=C1 lc=10 le=-1 em=0
scdaemon[56643] DBG: PCSC_data: 00 DA 00 C1 0A 13 2B 24 03 03 02 08 01
01 07
scdaemon[56643] DBG: response: sw=9000 datalen=0
scdaemon[56643] DBG: dump:
scdaemon[56643] key attribute changed (key=1)
...
scdaemon[56643] DBG: send apdu: c=00 i=DA p1=00 p2=C1 lc=6 le=-1 em=0
scdaemon[56643] DBG: PCSC_data: 00 DA 00 C1 06 01 08 00 00 20 00
scdaemon[56643] DBG: response: sw=6A80 datalen=0
scdaemon[56643] error changing key attribute (key=1)
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
Trevor Bentley via Gnupg-devel <gnupg-devel@gnupg.org> wrote:
> Specifically, the KEY-ATTR command does not accept 'e bit length' as an
> argument. scdaemon simply re-uses whichever value the card defaults to
> if you change the RSA key length... but the real bug here is that when
> switching back to RSA from an EC algorithm, scdaemon hardcodes the 'e
> bit length' to 32.

In my opinion, the key attributes are not well defined in the spec and
host software needs guessing about behavior of card implementation.

This hard-coding in scdaemon was done for existing OpenPGPcard
implementations; Achim's OpenPGPcard and Gnuk.

> Note that this is a likely case: the OpenPGP on Smart Card spec (v3.3.1)
> specifies 65537 (bit length 17) as the only value required to be
> supported, and as the default to use if none is specified. The protocol
> does not support specifying 'none', so GPG does have to specify
> something when changing the algorithm.

According to the spec, there is no information which key attribute
(value and format) is supported by a specific card. Here, host software
needs guessing.

In the spec, IIRC, it suggests the value "32" for e's length in the key
attributes, as well as the value 65537. Well, 65537 can be represented
by 32-bit. IIRC, there is no place in the spec suggesting 17. I know
that with the background of OpenPGP format itself, 17 makes sense.

> I believe this needs to be fixed in one of two ways:
> 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI)
> 2) use '17' instead of '32' as the hard-coded length, since all cards
> are required to support it

Or, you can ask change of OpenPGP card implementation, following other
OpenPGP card implementations. And make things explicit in the spec.

> --
> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
> OK
> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye
> OK
> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye

Here, it returns "OK" for Achim's OpenPGPcard (I have the test version
of 3.3) and Gnuk 1.2.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
> In my opinion, the key attributes are not well defined in the spec and
> host software needs guessing about behavior of card implementation.

I mostly agree. The spec does state that all cards must support 65537,
so at least there is a known value that can always be chosen. But
ideally, the smartcard spec would allow sending a special value (or
omitting the field) to means 'card default'. And ideally, GnuPG would
still provide some method for the user to explicitly set a desired e bit
len if the user does not want the default.

I've added Achim to this thread, as it would be nice to get his input.

> According to the spec, there is no information which key attribute
> (value and format) is supported by a specific card. Here, host software
> needs guessing.
>
> In the spec, IIRC, it suggests the value "32" for e's length in the key
> attributes, as well as the value 65537. Well, 65537 can be represented
> by 32-bit. IIRC, there is no place in the spec suggesting 17. I know
> that with the background of OpenPGP format itself, 17 makes sense.

The spec doesn't provide a way to check if a length is supported.
However, it is clear about 65537 being required, and recommends it as
default:

SHALL accept (required):
--
Some smart cards with RSA algorithm support only one coding for the
Public Exponent (e.g. 65537 dec.). The card may reject an imported key,
if e does not match the internal requirements. But the card shall accept
65537 dec. (010001) as value for e.
--

SHOULD use (recommended):
--
The card should use 65537 dec. (10001 bin.) as default value for e, but
other values are accepted by the outside world.
--

I only see 32 specified in an example, which is just demonstrating that
it can be used:
"Length of public exponent e in bit (e. g. 32 bit decimal = 0020), binary"

You are obviously correct that 65537 fits in 32 bits, but cards that
don't accept exponents larger than 17 bits are typically going to refuse
the larger length. It may be _permitted_ to accept a 32-bit length and
generate a 17-bit exponent within it, but in practice they almost
certainly won't. And rightly so, since accepting a 32-bit length
strongly implies that it can actually handle them.

>> I believe this needs to be fixed in one of two ways:
>> 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI)
>> 2) use '17' instead of '32' as the hard-coded length, since all cards
>> are required to support it
>
> Or, you can ask change of OpenPGP card implementation, following other
> OpenPGP card implementations. And make things explicit in the spec.

I would suggest that as an 'and' instead of an 'or'. I think it's best
for GnuPG to support the existing spec as well as possible, and to
encourage the spec to improve.

>> --
>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
>> OK
>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye
>> OK
>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
>
> Here, it returns "OK" for Achim's OpenPGPcard (I have the test version
> of 3.3) and Gnuk 1.2.

They are permitted to accept it, especially if they really do support
32-bit exponents. That doesn't change the fact that other cards, which
implement the spec correctly, will fail.

As it stands today, GnuPG cannot switch from ECC to RSA on some smart
cards that _correctly_ implement the 'OpenPGP application on ISO Smart
Card Operating Systems', and I think that is worth fixing.

Thanks,

-Trevor

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
Hi all,

the problem is not the definition of the Algorithm Attributes, but the lack of an information object to see what functions the card will support.
I often got questions what algorithm the card supports - the actual definitions are presenting the 'status quo' only, but not other features of the implemention.

See my answers to your discussion in between the text below.

Regards
Achim


Am 04.07.2018 um 10:26 schrieb Trevor Bentley:
>> In my opinion, the key attributes are not well defined in the spec and
>> host software needs guessing about behavior of card implementation.
>
> I mostly agree.  The spec does state that all cards must support 65537, so at least there is a known value that can always be chosen.  But ideally, the smartcard spec would allow sending a special
> value (or omitting the field) to means 'card default'.  And ideally, GnuPG would still provide some method for the user to explicitly set a desired e bit len if the user does not want the default.
>
> I've added Achim to this thread, as it would be nice to get his input.
>
>> According to the spec, there is no information which key attribute
>> (value and format) is supported by a specific card.  Here, host software
>> needs guessing.
>>
>> In the spec, IIRC, it suggests the value "32" for e's length in the key
>> attributes, as well as the value 65537.  Well, 65537 can be represented
>> by 32-bit.  IIRC, there is no place in the spec suggesting 17.  I know
>> that with the background of OpenPGP format itself, 17 makes sense.
>
--> The Algorithm Attributs only define the format of the key representation (e. g. for key import), but not the allowed content.
In principle any running values are allowed, only the representation/format shall be in accordance with the alg-attributs - with some exceptions ;)
Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be
accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values
for p, q, e).

The actual definition is 15 years old and many features where added without changing several data Objects (DO), with respect to existing implmentations. In most cases we add new DOs that can be used
for new functionalities. I think the actual definition is OK for that purpose - for addressing your problem (what values are allowed) a new information object maybe helpful.

> The spec doesn't provide a way to check if a length is supported. However, it is clear about 65537 being required, and recommends it as default:
>
> SHALL accept (required):
> --
> Some smart cards with RSA algorithm support only one coding for the Public Exponent (e.g. 65537 dec.). The card may reject an imported key, if e does not match the internal requirements. But the card
> shall accept 65537 dec. (010001) as value for e.
> --
>
> SHOULD use (recommended):
> --
> The card should use 65537 dec. (10001 bin.) as default value for e, but other values are accepted by the outside world.
> --
>
> I only see 32 specified in an example, which is just demonstrating that it can be used:
> "Length of public exponent e in bit (e. g. 32 bit decimal = 0020), binary"
>
> You are obviously correct that 65537 fits in 32 bits, but cards that don't accept exponents larger than 17 bits are typically going to refuse the larger length.  It may be _permitted_ to accept a
> 32-bit length and generate a 17-bit exponent within it, but in practice they almost certainly won't.  And rightly so, since accepting a 32-bit length strongly implies that it can actually handle them.
>
--> The alg-attributs define the allowed format for presenting keys, actual you cannot see what values an implementiation will accept - you only know that all cards will/must accept e=65537.
You are rigth, that other values must be known by the outside world by knowledge (e. g. data sheet of the card) or try and error.

>>> I believe this needs to be fixed in one of two ways:
>>> 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI)
>>> 2) use '17' instead of '32' as the hard-coded length, since all cards
>>> are required to support it
>>
>> Or, you can ask change of OpenPGP card implementation, following other
>> OpenPGP card implementations.  And make things explicit in the spec.
>
--> The problem does not only appear to the value of e, but to all values that can be set in algorithm attributs (what algos do the card support? What key length for RSA or ELC?).
GnuPG actual is orientated to the my implementions and GNUK for historic reasons, there where not many implementations in the past ;)

The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older
implementions and can be evalutated for setting new algorithm attributes and for key import.

If you and Niibe agree, I will make a proposal and add it to the next specification.
The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples.


> I would suggest that as an 'and' instead of an 'or'.  I think it's best for GnuPG to support the existing spec as well as possible, and to encourage the spec to improve.
>
>>> --
>>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
>>> OK
>>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye
>>> OK
>>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
>>
>> Here, it returns "OK" for Achim's OpenPGPcard (I have the test version
>> of 3.3) and Gnuk 1.2.
>
> They are permitted to accept it, especially if they really do support 32-bit exponents.  That doesn't change the fact that other cards, which implement the spec correctly, will fail.
>
--> The specification allows other length codings for e, so if an implementation sets the algorithm attributs to a different length than 32 bits, it should work (should be accepted by GnuPG and other
software). My implementations always use 32 bits for e-values - so it may be possible that other length expressions are not tested in the past, by lack of test cards...

> As it stands today, GnuPG cannot switch from ECC to RSA on some smart cards that _correctly_ implement the 'OpenPGP application on ISO Smart Card Operating Systems', and I think that is worth fixing.
>
> Thanks,
>
> -Trevor
>
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
> Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be
> accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values
> for p, q, e).

For this reason, I think the current implementation in GnuPG should
change to send a bit length of 17. This is backed by two reasons:

1) All cards that implement the OpenPGP for Smart Cards spec must
support it, and presumably Gnuk and the others will keep working.

2) GnuPG's 'gen-key' already defaults to 65537, and sends bit length 17
to KEY-ATTR when importing keys. So gpg is already defaulting to 17
everywhere except when switching the card from EC to RSA mode.

> The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older
> implementions and can be evalutated for setting new algorithm attributes and for key import.
>
> If you and Niibe agree, I will make a proposal and add it to the next specification.
> The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples.

Yes, I agree with this. It should support either min/max length for
cards that support ranges, or a list of discrete values for cards with
absolute requirements. A card might support _exactly_ e=3 or e=65537,
for instance, and specifying the range "2 to 17 bits" isn't quite right.
It is similarly common to only support discrete n lengths, e.g.
n=1024/2048/3072/4096.

I strongly suggest that the response should clearly mark what the card
considers 'default' for an algorithm. It should be trivial for GnuPG to
ask the card what settings it wants and set it to that, without having
to make any guesses or assumptions.

Thanks,

-Trevor

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
Hi,

I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of
the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes,
filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17
for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with
leading zeros.

If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be
evalutated before changing the Algorithm Attributs and/or for key im-/export.

>> Yes, I agree with this. It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements. A card might support _exactly_
>> e=3 or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right. It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096.

I think this DO should contain each supported algorithm (like RSA, EC-ANSI, EC-brainpool) in a list with their specific values as range or fixed entry.
The representation to the outside world then is still in compliance with the definitions in Algorithm Attributes.

Regards
Achim


Am 04.07.2018 um 13:10 schrieb Trevor Bentley:
>> Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be
>> accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values
>> for p, q, e).
>
> For this reason, I think the current implementation in GnuPG should change to send a bit length of 17.  This is backed by two reasons:
>
> 1) All cards that implement the OpenPGP for Smart Cards spec must support it, and presumably Gnuk and the others will keep working.
>
> 2) GnuPG's 'gen-key' already defaults to 65537, and sends bit length 17 to KEY-ATTR when importing keys.  So gpg is already defaulting to 17 everywhere except when switching the card from EC to RSA mode.
>
>> The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older
>> implementions and can be evalutated for setting new algorithm attributes and for key import.
>>
>> If you and Niibe agree, I will make a proposal and add it to the next specification.
>> The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples.
>
> Yes, I agree with this.  It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements.  A card might support _exactly_ e=3
> or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right.  It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096.
>
> I strongly suggest that the response should clearly mark what the card considers 'default' for an algorithm.  It should be trivial for GnuPG to ask the card what settings it wants and set it to that,
> without having to make any guesses or assumptions.
>
> Thanks,
>
> -Trevor
>
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
> I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of
> the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes,
> filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17
> for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with
> leading zeros.

Hmm, definitely a misunderstanding then. The spec should be updated to
clarify that. "Length of public exponent e in bit" certainly implies
that it will be the exact length of _e_ in bits, not the... number of
bits in the minimum number of 32-bit ints needed to contain it? I'm
still unclear on why it's 32 bits instead of 24. Is e=3 encoded as
e_bit_len=8 or e_bit_len=32? What about e=0x100000001 (33 bits)?

When importing a key, it is ASN.1 encoded and already specifies both the
lengths and values of each parameter. Keys can be validated and
rejected at time of import, without needing the algorithm attributes DO.
Importing is not really a problem, but on-device key generation is.

My understanding was that, when calling Generate Asymmetric Key Pair, it
should generate a key with the bit lengths specified in Algorithm
Attributes. But if those fields aren't actually the bit length of the
parameters, but instead the bit length of some larger container, what is
the generate command supposed to do?

> If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be
> evalutated before changing the Algorithm Attributs and/or for key im-/export.

I still think there is that need, but only if the data can actually be
used somehow.

Maybe you can walk me through what the expected commands would be in the
following situation:

Smart Card supports:
(1) (RSA n=2048,e=3)
(2) (RSA n=2048,e=65537) *default
(3) (RSA n=4096,e=257)
(4) (RSA n=4096,e=65537)

I want to generate (on device) four keys in a row, of type (1) then (2)
then (3) then (4). Is that possible, and if so, what would the
algorithm attributes be set to before each generate command?

If that is not supposed to be possible, then the need for a new DO is
much less important.

Thanks,

Trevor


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
Hi!

This is not related to the question but let me give this quick remark.

> (1) (RSA n=2048,e=3)

Never ever use that public exponent.

> (2) (RSA n=2048,e=65537) *default

For a reason this is the default. For quite some time gpg used 41 but
when new low exponent attacks appeared we skipped all others and started
to use 65537.

> (3) (RSA n=4096,e=257)

e might be okay but it is safer to go with 65537


Shalom-Salam,

Werner

--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
Hi Trevor,

generation of keys is a complete internal function of a card, there is no influence to adjust parameters like e in the command data - all is depending on the development.
In your implmentation you are free to set any valid defaults, e maybe fixed or within a range or is calculated by random - it's the choice of the developer.
The Algorithm Attributes show how to interpret the key values during im- and export of private and public keys, but do not define internal rules for the generation.

So your example with several given values for e will not run within the current definitions. For your needs then a new information DO maybe of less priority.
But if an implmentation allows changing of the Algorithm Attributes, it is useful to know what parameters/algorithms are suppported by the card. This cannot be evaluated at the moment and a software
that wants to change an algorithm e. g. must know the implementation (internal list etc.). Also for key import it is useful to know what values a card will accept, to avoid try and error.
For that purposes I will add such an information DO in the next version, but it will not solve your requirements to set special values for e...

Regards
Achim


Am 05.07.2018 um 14:09 schrieb Trevor Bentley:
>> I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of
>> the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes,
>> filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17
>> for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with
>> leading zeros.
>
> Hmm, definitely a misunderstanding then.  The spec should be updated to clarify that.  "Length of public exponent e in bit" certainly implies that it will be the exact length of _e_ in bits, not
> the... number of bits in the minimum number of 32-bit ints needed to contain it?  I'm still unclear on why it's 32 bits instead of 24.  Is e=3 encoded as e_bit_len=8 or e_bit_len=32?  What about
> e=0x100000001 (33 bits)?
>
> When importing a key, it is ASN.1 encoded and already specifies both the lengths and values of each parameter.  Keys can be validated and rejected at time of import, without needing the algorithm
> attributes DO.  Importing is not really a problem, but on-device key generation is.
>
> My understanding was that, when calling Generate Asymmetric Key Pair, it should generate a key with the bit lengths specified in Algorithm Attributes.  But if those fields aren't actually the bit
> length of the parameters, but instead the bit length of some larger container, what is the generate command supposed to do?
>
>> If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be
>> evalutated before changing the Algorithm Attributs and/or for key im-/export.
>
> I still think there is that need, but only if the data can actually be used somehow.
>
> Maybe you can walk me through what the expected commands would be in the following situation:
>
> Smart Card supports:
>  (1) (RSA n=2048,e=3)
>  (2) (RSA n=2048,e=65537) *default
>  (3) (RSA n=4096,e=257)
>  (4) (RSA n=4096,e=65537)
>
> I want to generate (on device) four keys in a row, of type (1) then (2) then (3) then (4).  Is that possible, and if so, what would the algorithm attributes be set to before each generate command?
>
> If that is not supposed to be possible, then the need for a new DO is much less important.
>
> Thanks,
>
> Trevor
>
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: scd bug: specifying 'e length' for RSA key-attr unsupported [ In reply to ]
Thanks, Achim. Then I retract this as a bug report, and lower it to a
confusing spec report :)

I do think you should clarify the language around e length when you add
the new DO, though. It's definitely not clear how it is to be used.

Also, there is one sentence in the spec that suggests Algorithm
Attributes decides how on-device key generation is done:

"This DO announces information related to the supported algorithm of the
card. ... The formats are used by the key generation in the card..."

It is never defined how they are used, but does say that they are. The
implication is that on-device generation should match the current
Algorithm Attributes.

Yubikeys currently choose the RSA bit length of on-device generated keys
based on the current Algorithm Attributes. Isn't that the expected
behavior? Gnuk appears to do the same. So, in current implementations,
both "Algorithm ID" and "Length of modulus n in bit" are used during
generation, but "Length of public exponent e in bit" is not.

-Trevor

On 2018-07-08 11:27, Achim Pietig wrote:
> Hi Trevor,
>
> generation of keys is a complete internal function of a card, there is no influence to adjust parameters like e in the command data - all is depending on the development.
> In your implmentation you are free to set any valid defaults, e maybe fixed or within a range or is calculated by random - it's the choice of the developer.
> The Algorithm Attributes show how to interpret the key values during im- and export of private and public keys, but do not define internal rules for the generation.
>
> So your example with several given values for e will not run within the current definitions. For your needs then a new information DO maybe of less priority.
> But if an implmentation allows changing of the Algorithm Attributes, it is useful to know what parameters/algorithms are suppported by the card. This cannot be evaluated at the moment and a software
> that wants to change an algorithm e. g. must know the implementation (internal list etc.). Also for key import it is useful to know what values a card will accept, to avoid try and error.
> For that purposes I will add such an information DO in the next version, but it will not solve your requirements to set special values for e...
>
> Regards
> Achim
>
>
> Am 05.07.2018 um 14:09 schrieb Trevor Bentley:
>>> I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of
>>> the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes,
>>> filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17
>>> for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with
>>> leading zeros.
>>
>> Hmm, definitely a misunderstanding then.  The spec should be updated to clarify that.  "Length of public exponent e in bit" certainly implies that it will be the exact length of _e_ in bits, not
>> the... number of bits in the minimum number of 32-bit ints needed to contain it?  I'm still unclear on why it's 32 bits instead of 24.  Is e=3 encoded as e_bit_len=8 or e_bit_len=32?  What about
>> e=0x100000001 (33 bits)?
>>
>> When importing a key, it is ASN.1 encoded and already specifies both the lengths and values of each parameter.  Keys can be validated and rejected at time of import, without needing the algorithm
>> attributes DO.  Importing is not really a problem, but on-device key generation is.
>>
>> My understanding was that, when calling Generate Asymmetric Key Pair, it should generate a key with the bit lengths specified in Algorithm Attributes.  But if those fields aren't actually the bit
>> length of the parameters, but instead the bit length of some larger container, what is the generate command supposed to do?
>>
>>> If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be
>>> evalutated before changing the Algorithm Attributs and/or for key im-/export.
>>
>> I still think there is that need, but only if the data can actually be used somehow.
>>
>> Maybe you can walk me through what the expected commands would be in the following situation:
>>
>> Smart Card supports:
>>  (1) (RSA n=2048,e=3)
>>  (2) (RSA n=2048,e=65537) *default
>>  (3) (RSA n=4096,e=257)
>>  (4) (RSA n=4096,e=65537)
>>
>> I want to generate (on device) four keys in a row, of type (1) then (2) then (3) then (4).  Is that possible, and if so, what would the algorithm attributes be set to before each generate command?
>>
>> If that is not supposed to be possible, then the need for a new DO is much less important.
>>
>> Thanks,
>>
>> Trevor
>>
>>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel