1  #+TITLE: Story 18 - Authenticated Encryption
  2  #+OPTIONS: author:nil date:nil
  3  
  4  Authenticated encryption (sometimes, but not always referred to as AEAD) seems
  5  to be a mode of operation for symmetric ciphers that causes a bit of trouble,
  6  as it has some extra requirements on top of the underlying ciphers: the tag.
  7  
  8  Discussions have been seen in other projects if this deserves a completely
  9  separate API, or if it can be retrofitted into the existing symmetric cipher
 10  API.  In different projects, different choices have been made:
 11  
 12  - OpenSSL uses added controls / parameters to pass the tag back and forth, and
 13    thereby indicate that an AEAD mode should be used.  There really is no other
 14    way, this mode of operation isn't apparent through algorithm names.
 15  - libtomcrypt, on the other hand, uses separate APIs for each of the
 16    authenticated encryption modes it supports, for reasons that are pretty
 17    obvious, since it passes most parameters as init arguments (this varies
 18    depending on the mode).
 19  
 20  Neither of this is very manageable.  A user should be able to tell if
 21  authenticated encryption is to be used or not without involving giving
 22  underhanded hints (the OpenSSL way), but should also not be forced to
 23  use a different APIs for each of the modes (the libtomcrypt way).
 24  
 25  There are several possible designs to deal with authenticated encryption:
 26  
 27  - Piggy-back on existing encryption / decryption functions ::
 28  
 29    This involves adding just enough separate functions to support authenticated
 30    encryption, and otherwise use the existing encryption / decryption
 31    functions.  The new functions would be limited to those that have to deal
 32    with the authenticated encryption tag.
 33  
 34  - Piggy-back on the encryptor / decryptor operator type :: 
 35  
 36    This involves using ~LSC_encryptor_t~ and ~LSC_decryptor_t~, but add a
 37    separate set of function, duplicating all the existing encryption /
 38    decryption functions, and including the authenticated encryption tag where
 39    it makes sense.
 40  
 41  - Make a new operator type ::
 42  
 43    This involves adding new operator types that are similar to
 44    ~LSC_encryptor_t~ and ~LSC_decryptor_t~, but are named differently, and have
 45    their own set of functions, similar to the existing encryption / decryption
 46    functions.  This also implies a separate registration of the applicable
 47    algorithm.
 48  
 49  After much consideration, the choice comes to making a new operator type, i.e.
 50  the third choice.  The reasoning behind this decision is:
 51  
 52  - Because authenticated encryption is really a combination of two concepts, it
 53    makes sense to see it as a separate operator type, no matter how similar it
 54    is to existing operator types otherwise.
 55  
 56  - It makes it less confusing for plugin authors and users alike, as it removes
 57    the need to go look what functionality is supported by the algorithm, and
 58    simply makes it clear from the algorithm's inception.
 59  
 60    - For plugin authors, it removes the possible mistakes of implementing
 61      different (and potentially incorrect) functionality.
 62  
 63    - For users, it's clear from the point that the algorithm is found in the
 64      applicable registry.  The only thing the user needs to do to find out what
 65      needs to be done is to try out all applicable registries.
 66  
 67  * Names
 68  
 69  Let's keep things short.  An idea for names is to simply use the encrypt /
 70  decrypt names, and prefix them all with ~auth_~:
 71  
 72  - ~auth_encrypt~, ~auth_encryptor~, ~auth_encryption~
 73  - ~auth_decrypt~, ~auth_decryptor~, ~auth_decryption~
 74  
 75  * New and alternate functionality compare to encryption / decryption
 76  
 77  The list of new functions would then be:
 78  
 79  - Get Encryption / Decryption Tag Size ::
 80  
 81    This is a new function to get the tag size, which is supposedly fixed.
 82  
 83  - Finalize Auth Encryption ::
 84  
 85    Compared to Finalize Encryption, this also takes a pointer to a write only
 86    tag buffer.  This is similar to the asymmetric signature finalize function,
 87    while also finalizing the encryption itself.
 88  
 89  - Finalize Auth Decryption ::
 90  
 91    Compared to Finalize Decryption, this also takes a pointer to a read only
 92    tag buffer, as well as to a write only boolean variable, which should become
 93    ~true~ if the input tag matches the calculated tag, and ~false~ if not.
 94    This is similar to the asymmetric verification finalize function, while also
 95    finalizing the decryption itself.
 96  
 97  - Perform Auth Encryption / Decryption Once ::
 98  
 99    These do the logical combination of Start, Perform, Finalize Auth, and Stop
100    Encryption / Decryption, suitable for packet mode encryption / decryption.
101  
102  Implementations will have to choose what functions to support, depending on if
103  they are designed for streaming, for packets or for both.
104  
105  * Extra perks
106  
107  In addition to minimize confusion, having authenticated encryption be a
108  separate operator also allows the option to compose algotirhms from building
109  blocks.
110  
111  Authenticated encryption can be seen conceptually as a mode of operation for
112  ciphers, which can be seen as a mode of operation for symmetric encryption
113  keys.  For example, AEAD-AES could be expressed as ~aead(cbc(aes))~.
114  
115  Composition hasn't been mentioned before, and isn't really for Le'Sec Core,
116  but could be something for Le'Sec.  Possibly.  Maybe.  This requires more
117  thought and may become another story.  See this as a possible prelude.