title: AES 128 decryption with ciphertext shorter than key
body: <p>We are developing an application that has to work with data that is enycrpted by LoraWan (<a href="https://www.lora-alliance.org" rel="nofollow noreferrer">https://www.lora-alliance.org</a>)</p>
  
  <p>We have already found the documentation of how they encrypt their data, and have been reading through it for the past few days (<a href="https://www.lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf" rel="nofollow noreferrer">https://www.lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf</a>) but currently still can't solve our problem.</p>
  
  <p>We have to use AES 128-bit ECB decryption with zero-padding to decrypt the messages, but the problem is it's not working because the encrypted messages we are receiving are not long enough for AES 128 so the algorithm returns a "Data is not a complete block" exception on the last line.</p>
  
  <p>An example key we receive is like this: D6740C0B8417FF1295D878B130784BC5 (not a real key). It is 32 characters long, so 32 bytes, but if treat it as hexadecimal, then it becomes 16 bytes long, which is what is needed for AES 128-bit. This is the code we use to convert the Hex from String:</p>
  
  <pre><code>public static string HextoString(string InputText)
  {byte[] hex= Enumerable.Range(0, InputText.Length)
                   .Where(x =&gt; x % 2 == 0)
                   .Select(x =&gt; Convert.ToByte(InputText.Substring(x, 2), 16))
                   .ToArray();
  return System.Text.Encoding.ASCII.GetString(hex);}
  </code></pre>
  
  <p>(A small thing to note for the above code is that we are not sure what Encoding to use, as we could not find it in the Lora documentation and they have not told us, but depending on this small setting we could be messing up our decryption (though we have tried all possible combinations, ascii, utf8, utf7, etc))</p>
  
  <p>An example message we receive is: d3 73 4c which we are assuming is also in hexadecimal. This is only 6 bytes, and 3 bytes if we convert it from hexa to normal, compared to the 16 bytes we'd need minimum to match the key length.</p>
  
  <p>This is the code for Aes 128 decrypt we are using:</p>
  
  <pre><code>private static string Aes128Decrypt(string cipherText, string key){
  
  string decrypted = null;
  
  var cipherPlainTextBytes = HexStringToByteArray(cipherText);
  //var cipherPlainTextBytes = ForcedZeroPadding(HexStringToByteArray(cipherText));
  var keyBytes = HexStringToByteArray(key);
  
  using (var aes = new AesCryptoServiceProvider())
  {
      aes.KeySize = 128;
      aes.Key = keyBytes;
      aes.Mode = CipherMode.ECB; 
      aes.Padding = PaddingMode.Zeros; 
  
      ICryptoTransform decryptor = aes.CreateDecryptor(aes.Key, aes.IV);
      using (MemoryStream ms = new MemoryStream(cipherPlainTextBytes, 0, cipherPlainTextBytes.Length))
      {
          using (CryptoStream cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read))
          {
              using (StreamReader sr = new StreamReader(cs))
              {
                  decrypted = sr.ReadToEnd();
              }
          }
      }
  }
  return decrypted;}
  </code></pre>
  
  <p>So obviously this is going to return "Data is an incomplete block" at sr.ReadToEnd().</p>
  
  <p>As you can see from the example, in that one commented out line, we have also tried to "Pad" the text to the correct size with a full zero byte array of correct length (16 - cipherText), in which case the algorithm runs fine, but it returns complete gibberish and not the original text. </p>
  
  <p>We already have tried all of the modes of operation and messed around with padding modes as well. They are not providing us with anything but a cipherText, and a key for that text. No Initialization vector either, so we are assuming we are supposed to be generating that every time (but for ECB it isn't even needed iirc)</p>
  
  <p>What's more is, they are able to encrypt-decrypt their messages just fine. What is most puzzling about this is that I have been googling this for days now and I cannot find a SINGLE example on google where the CIPHERTEXT is shorter than the key during <strong>decryption</strong>. </p>
  
  <p>Obviously I have found examples where the message they are <strong>Encrypting</strong> is shorter than what is needed, but that is what padding is for on the ENCRYPTION side (right?). So that when you then receive the padded message, you can tell the algorithm what padding mode was used to make it correct length, so then it can seperate the padding from the message. But in all of those cases the recieved message during decryption is of correct length.</p>
  
  <p>So the question is - what are we doing wrong? is there some way to decrypt with ciphertexts that are shorter than the key? Or are they messing up somewhere by producing ciphers that are too short?</p>
  
  <p>Thanks for any help.</p>