1  #+TITLE: Story 15 - More on Parameters
  2  #+OPTIONS: author:nil date:nil
  3  
  4  * Recent development
  5  
  6  There's been some development with parameter descriptors (~LSC_param_desc_t~),
  7  all fuelled by the development of the LTC (libtomcrypt) plugin.
  8  
  9  - Multiple ranges of number of elements ::
 10  
 11    The first development was to allow a parameter descriptor to express
 12    multiple ranges of number of elements.  This is only relevant for scalar
 13    parameters.
 14  
 15    This was specifically added to express multiple key sizes, which is common
 16    for symmetric ciphers.  (for these, each range expresses one specific key
 17    size, where the range's min and max are the same)
 18  
 19    A maximum of 16 ranges are possible to specify.
 20  
 21  - Include an increment with each range of number of elements ::
 22  
 23    It turned out that some asymmetric keys had more than 16 possible key sizes.
 24  
 25    An example is Blowfish, which allows any key size between 5 and 448 bits.
 26    libtomcrypt has limited this to 8 to 56 bytes, or put differently, 64 to 448
 27    in increments of 8.  That makes for 49 different key sizes.
 28  
 29    By including an increment into each range, Blowfish's key size range could
 30    simply be expressed as one range, 64 to 448 in increments of 8, instead of
 31    having each key size as individual ranges; 64, 72, 80, 88, 96, 104, 112,
 32    120, 128, 136, 144, 152, 160, 168, ... 432, 440, 448.  (you can see for
 33    yourselves how that would exhaust the array of 16 possible ranges)
 34  
 35    The increment of zero is to be interpreted as one, i.e. a default.  This
 36    allows plugin writers some level of sloppiness, but those interpreting a
 37    parameter descriptor must be aware of this.
 38  
 39  
 40  * Concerns regarding integers
 41  
 42  The ~d_auxilliary~ descriptor for integers (~d_integer_desc~) is overly
 43  complex, and experience has shown that this shouldn't be necessary.  As a
 44  matter of fact, the LTC plugin takes all big numbers as bitstrings, following
 45  libtomcrypt's API.
 46  
 47  Passing big numbers as bit strings can be a bit awkward, though.  If the
 48  number of bits doesn't fit byte arrays exactly (i.e. the number of bits isn't
 49  an exact multiple of 8), how should they be padded, in the most significant
 50  end or the least significant end?  All these questions are left to the
 51  application to interpret and guess.
 52  
 53  Coming back to ~d_integer_desc~, it could be simplified by always looking at
 54  an integer as an array of bytes rather than an array of words.  The usual C
 55  types can be viewed that way, for example.  All that remains is to figure out
 56  what information is still needed:
 57  
 58  - Everything related to words can be thrown away ::
 59  
 60    This means that the following will disappear:
 61  
 62    #+BEGIN_SRC C
 63      enum {
 64        LSC_DTi_host_order = 0,
 65        LSC_DTi_lsw_first_order,
 66        LSC_DTi_msw_first_order,
 67      } d_word_order;
 68  
 69      uint8_t d_word_size;
 70    #+END_SRC
 71  
 72  - Slightly change the byte order names ::
 73  
 74    This means that ~d_byte_order~ doesn't express the composition of words any
 75    more, but rather the composition of the whole integer:
 76  
 77    #+BEGIN_SRC C
 78      enum {
 79        LSC_DTi_host_order = 0,
 80        LSC_DTi_lsb_first_order,
 81        LSC_DTi_msb_first_order,
 82      } d_byte_order;
 83    #+END_SRC
 84  
 85  - Assume host representation of negative numbers ::
 86  
 87    Most computers today employ two's complement to represent negative numbers,
 88    and so do most big number libraries.  However, on the odd (possibly legacy)
 89    computer, the normal C integer types will use host representation.
 90    Therefore, the best way to deal with any environment is to assume host
 91    representation.
 92  
 93    Any big number library that has different ideas will simply have to deal.
 94  
 95    This also means that for positive /signed/ integers, care has to be taken by
 96    the application to pad any positive number that might be misinterpreted as
 97    negative (when the most significant bit is 1) with a extra zero byte.  This
 98    is how ASN.1 INTEGERs are encoded in BER and DER.
 99  
100    With this assumption, the ~d_separate_sign_byte~ attribute can be dropped as
101    well.
102  
103  - Continue to allow different endianness ::
104  
105    For the moment, it seems easier to allow MSB first numbers, at least for the
106    big numbers.  libtomcrypt's use of bit strings assume such an organization,
107    and it would be more painful to force the parameter receiving party to
108    convert, rather than the parameter passing party.
109  
110  The result of these deliberations is that the ~d_integer_desc~ struct can be
111  reduced to this:
112  
113  #+BEGIN_SRC C
114    struct {
115      enum {
116        LSC_DTi_host_order = 0,
117        LSC_DTi_lsb_first_order,
118        LSC_DTi_msb_first_order,
119      } d_byte_order;
120    } d_integer_desc;
121  #+END_SRC