Why is the ciphertext 32 bytes long when encrypting 16 bytes with AES?

Question

I use encryption AES algorithm, when i encrypt 16 byte(one block) the result is 32 byte. Is this ok?

My source code that i used is:

package net.sf.andhsli.hotspotlogin;

import java.security.SecureRandom;

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.SecretKeySpec;

/**
 * Usage:
 * <pre>
 * String crypto = SimpleCrypto.encrypt(masterpassword, cleartext)
 * ...
 * String cleartext = SimpleCrypto.decrypt(masterpassword, crypto)
 * </pre>
 * @author ferenc.hechler
 */
public class SimpleCrypto {

    public static String encrypt(String seed, String cleartext) throws Exception {
        byte[] rawKey = getRawKey(seed.getBytes());
        byte[] result = encrypt(rawKey, cleartext.getBytes());
        return toHex(result);
    }

    public static String decrypt(String seed, String encrypted) throws Exception {
        byte[] rawKey = getRawKey(seed.getBytes());
        byte[] enc = toByte(encrypted);
        byte[] result = decrypt(rawKey, enc);
        return new String(result);
    }

    private static byte[] getRawKey(byte[] seed) throws Exception {
        KeyGenerator kgen = KeyGenerator.getInstance("AES");
        SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
        sr.setSeed(seed);
        kgen.init(128, sr); // 192 and 256 bits may not be available
        SecretKey skey = kgen.generateKey();
        byte[] raw = skey.getEncoded();
        return raw;
    }


    private static byte[] encrypt(byte[] raw, byte[] clear) throws Exception {
        SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES");
        Cipher cipher = Cipher.getInstance("AES");
        cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
        byte[] encrypted = cipher.doFinal(clear);
        return encrypted;
    }

    private static byte[] decrypt(byte[] raw, byte[] encrypted) throws Exception {
        SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES");
        Cipher cipher = Cipher.getInstance("AES");
        cipher.init(Cipher.DECRYPT_MODE, skeySpec);
        byte[] decrypted = cipher.doFinal(encrypted);
        return decrypted;
    }

    public static String toHex(String txt) {
        return toHex(txt.getBytes());
    }
    public static String fromHex(String hex) {
        return new String(toByte(hex));
    }

    public static byte[] toByte(String hexString) {
        int len = hexString.length()/2;
        byte[] result = new byte[len];
        for (int i = 0; i < len; i++)
            result[i] = Integer.valueOf(hexString.substring(2*i, 2*i+2), 16).byteValue();
        return result;
    }

    public static String toHex(byte[] buf) {
        if (buf == null)
            return "";
        StringBuffer result = new StringBuffer(2*buf.length);
        for (int i = 0; i < buf.length; i++) {
            appendHex(result, buf[i]);
        }
        return result.toString();
    }
    private final static String HEX = "0123456789ABCDEF";
    private static void appendHex(StringBuffer sb, byte b) {
        sb.append(HEX.charAt((b>>4)&0x0f)).append(HEX.charAt(b&0x0f));
    }

}

I removed the Android tag because this doesn't have anything to do with it. Btw. you should really give us an example of how you use the class showing what the problem is. — Morten Kristensen, Jun 26 '11 at 19:32
I assume you're using hex encoding because you want URI friendly chars. I suggest base32 encoding in that case. — Steven, Jun 28 '11 at 03:43
This will no longer work on Android 4.2, excellent info here: http://stackoverflow.com/questions/13433529/android-4-2-broke-my-encrypt-decrypt-code-and-the-provided-solutions-dont-work — slinden77, May 11 '13 at 13:17

Morten Kristensen · Answer 1 · 2020-09-03T12:21:10.440

16

If you look at the specification section 5 then you can see that the input, output and state are all 128 bit. The only thing that varies is the size of the key: 128, 196 or 256 bits. So encrypting a 16 byte input state will yield a 16 byte output state.

Are you sure you aren't mixing it up with the length in hexadecimal notation or similar? If it is in hexadecimal notation then it's correct because for each byte two characters are needed to represent it: 00-FF (for the range 0-255). So, for example, 16 bytes would be encoded as 32 characters in hexadecimal notation.

Another way you can test if the encryption is correct is by doing the equivalent decryption, see if it matches the plaintext input string.

Anyway, it does the correct thing. Here's a test:

public static void main(String[] args) {
  try {
    String plaintext = "Hello world", key = "test";
    String ciphertext = encrypt(key, plaintext);
    String plaintext2 = decrypt(key, ciphertext);
    System.out.println("Encrypting '" + plaintext +
                       "' yields: (" + ciphertext.length() + ") " + ciphertext);
    System.out.println("Decrypting it yields: " + plaintext2);
  }
  catch (Exception ex) {
      ex.printStackTrace();
  }
}

Which yields:

Encrypting 'Hello world' yields: (32) 5B68978D821FCA6022D4B90081F76B4F

Decrypting it yields: Hello world

edited Sep 03 '20 at 12:21

answered Jun 26 '11 at 19:31

Morten Kristensen

7,412
4
32
52

It solved your problem? That's good. Btw. remember to mark the answer as accepted if this is the case. – Morten Kristensen Jun 26 '11 at 19:36
In this program, seed is string that have 16 byte for key and cleartext is string that have 16 byte but result format is HEX that have 32 hex number (each number have 2 character). – ebra Jun 26 '11 at 19:40
1

Exactly for every byte the string representing it will be 2 characters long for representing `00-FF` (`0-255`) – Morten Kristensen Jun 26 '11 at 19:42
After you write an encryption algorithm, don't forget to test it by using the test vectors provided by NIST. http://csrc.nist.gov/archive/aes/rijndael/wsdindex.html OR http://www.inconteam.com/software-development/41-encryption/55-aes-test-vectors – Ranhiru Jude Cooray Jun 27 '11 at 02:10
The example will no longer work post Android 4.2, read more on the issue here: http://stackoverflow.com/questions/13433529/android-4-2-broke-my-encrypt-decrypt-code-and-the-provided-solutions-dont-work – slinden77 Oct 27 '13 at 14:33
This old answer *does not offer any reason* why the 16 bytes are expanded into 32 bytes. – Maarten Bodewes Aug 30 '15 at 11:31
The reason is that 16 bytes are encoded as 32 characters in hexadecimal. – Morten Kristensen Sep 03 '20 at 12:19

Maarten Bodewes · Answer 2 · 2021-01-07T09:43:20.780

AES defaults to ECB mode encryption with PKCS#7 compatible padding mode (for all providers observed so far). ECB and CBC mode encryption require padding if the input is not precisely a multiple of the blocksize in size, with 16 being the block size of AES in bytes.

Unfortunately there might be no way for the unpadding mechanism to distinguish between padding and data; the data itself may represent valid padding. So for 16 bytes of input you will get another 16 bytes of padding. Padding modes that are deterministic such as PKCS#7 always pad with 1 up to [blocksize] bytes.

If you look at int output = cipher.getOutputSize(16); you will get back 32 bytes. Use "AES/ECB/NoPadding" during decipher to see the padding bytes (e.g. 4D61617274656E20426F64657765732110101010101010101010101010101010).

You are better off when you fully specify the algorithm. Previously most developers would go for "AES/CBC/PKCS5Padding" but nowadays "AES/GCM/NoPadding" should probably be used because it offers message authentication and integrity. Otherwise you will keep guessing which mode is actually used.

Note that using ECB mode is not safe as an attacker can retrieve information from the cipher text; identical blocks of plain text encode to identical blocks of cipher text.

score -2 · Answer 3 · answered Nov 19 '13 at 08:31

package com.cipher;

import java.security.InvalidAlgorithmParameterException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;

import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
import javax.crypto.IllegalBlockSizeException;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

public class Encrypt {

    public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException {
        // TODO Auto-generated method stub
String s="You are doing encryption at deep level";
SecureRandom sr=SecureRandom.getInstance("SHA1PRNG");
sr.setSeed(s.getBytes());
byte[] k=new byte[128/8];
sr.nextBytes(k);
SecretKeySpec spec=new SecretKeySpec(k,"AES");
byte[] iv={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
IvParameterSpec ivs=new IvParameterSpec(iv);
Cipher cps=Cipher.getInstance("AES/CBC/PKCS5Padding");
cps.init(Cipher.ENCRYPT_MODE,spec,ivs);
byte[] iv2=cps.doFinal(s.getBytes());
System.out.println("En"+iv2);
Cipher cpr=Cipher.getInstance("AES/CBC/PKCS5Padding");
cpr.init(Cipher.DECRYPT_MODE, spec,ivs);
byte[] iv3=cpr.doFinal(iv2);
String ds=new String(iv3);
System.out.println(ds);


    }

}

This old answer only contains code, no explanation what so ever. Either explain what you are trying to say or remove it. — Maarten Bodewes, Aug 30 '15 at 11:33

Why is the ciphertext 32 bytes long when encrypting 16 bytes with AES?

3 Answers3

Linked