Using any of the wonders of modern cryptographic technology, how is it possible to package a tweet-sized plaintext, which is to be encrypted with a proper one-time pad, to ensure its integrity and give it authentication? For these last two services we aim for at least a 128-bit level of assurance. We also want to indicate message order, with a tag, at the same level of protection.

Here are some ways to do it:

1.) One method would be to use a Carter-Wegman MAC.

2.) Another would be to use NaCl / Libsodium with the ChaCha20 stream cipher and the Poly1305 authenticator.

3.) Use an HMAC such as HMAC-SHA-256.

Is there another way that is reliable?

Thank you very much.

  • $\begingroup$ Don't understand the purpose of para.2. What's Libsodium and Poly-do-dah for when a plain HMAC is the common approach? Is this just expediency? Clearly you need to have a OTP tag/sequence at the front of the message otherwise the recipient can't decode it. I simply use a 128 bit truly random nonce from the OTP key source. So nonce|c|hmac. $\endgroup$ – Paul Uszak Jun 28 '19 at 10:40
  • $\begingroup$ @Paul Uszak Thanks for your comments! I was trying to describe different ways to provide authentication and an integrity check for the cipertext. HMAC, Carter-Wegman MAC, or using the ChaCha20/Poly1305 combo. $\endgroup$ – Patriot Jun 28 '19 at 11:09
  • $\begingroup$ You can also go weird, and do AES-ECB + SHA-1. Simples. This is one of the 'special' cases where ECB works if you do it encrypt + MAC way around. Honestly, I can't tell what Should we MAC-then-encrypt or encrypt-then-MAC? is recommending as it's now got more entropy that one of my instruments. And it's all further messed up in that you have a very special case in using (independently) a OTP for the encryption function. $\endgroup$ – Paul Uszak Jul 1 '19 at 14:19
  • $\begingroup$ @Paul Uszak Thanks again. Why not compose a full answer? $\endgroup$ – Patriot Jul 1 '19 at 14:23

If you want to be consistent with OTP usage, then you should use a One Time MAC. Currently it seems the easiest path for that is to simply use Poly1305, but remember that you must never reuse keys for Poly1305, just like you can't reuse keys in OTP. (In particular, don't use the key generation routine used by ChaCha20-Poly1305 to derive the Poly1305 key from a nonce/key pair).

Using HMAC doesn't make much sense: if you're using OTP, that's probably because you don't trust any particular block cipher, so you shouldn't trust any particular hash or MAC algorithm.

| improve this answer | |
  • $\begingroup$ "...that's probably because you don't trust any particular block cipher..." exactly...of the implementations of the ones available to me that I know how to use; namely, Gpg2 . $\endgroup$ – Patriot Jul 1 '19 at 22:31
  • 1
    $\begingroup$ I concur with this answer. See also this thread, in particular the accepted answer. $\endgroup$ – lightspeeder Jul 1 '19 at 23:06

Another way is to go weird, and do

$$nonce||\operatorname{AES-ECB_k}(m)||H \big(\operatorname{AES-ECB_k}(m)\big)$$

where $m$ is the message that is pre-encrypted with a OTP. This is a good example of code book mode working properly, due to the OPT. No cuddly polar creatures appear, and it follows the recommended encrypt then MAC doctrine.

$nonce$ is my message order(and pad ID for decryption), but it's not sequential. It's difficult in practice to maintain a correct (non repeating) sequence. It would be truly random, drawing upon the OTP key material. If you have the resources to make Kolmogorov random key material, then use it. Don't forget that if you also need a temporal component for the order, you can just introduce a timestamp into the message plain text.

I like this approach as it's simple to understand and implement. Java would only use existing internal functions as AES and SHA* are inbuilt. You just choose the bit length of the key, hash type and nonce. So you could have 256 bits throughout for symmetry. I think that I'd make the message length an exact multiple of 128 bits, for no particular scientific reason other than feng shui.

Using a separate key for encryption of the OTP key material has another advantage. It creates an ersatz two factor encryption system. Even if the OPT falls into enemy hands (say by just seizing the PC), past messages cannot be read.

It's worth pointing out that this is an atypical use case, and so I can't find loads of authenticated OTP research material. This leaves unanswered the question of whether you should include the OTP ID ( my $nonce$) within the MAC. You could I guess in minimising lookups for corresponding pads.

| improve this answer | |
  • 1
    $\begingroup$ I am going to try it. $\endgroup$ – Patriot Jul 4 '19 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.