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

[Achim Pietig]

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
> 
>