decrypting string with forge AES only yields some of the text

I have the following javascript (see jsfiddle):

seed = 'hi';
text = 'KQdciM892XEZXYC+jm4sWsijh/fQ4z/PRlpIHQG/+fM=';

function decrypt(seed, text){
  md = forge.md.sha256.create();
  md.update(seed);
  const key = md.digest().getBytes(32);
  const cypher = forge.util.createBuffer(forge.util.decode64(text), 'raw');
  
  // This seems right
  console.log(cypher.toHex());
  
  var decipher = forge.cipher.createDecipher('AES-ECB', key);
  decipher.start();
  decipher.update(cypher);
  const result = decipher.finish();

  if(result){
    const out = decipher.output;
    console.log(out.toHex());
    const dec = forge.util.encodeUtf8(out);
    console.log(dec);
  }else{
  	console.log('Bad key.');
  }
}

decrypt(seed, text);

The text that has been encoded is (with spaces and newlines, all):

           


```
## [1] 2
```

When I run the function decrypt, I get the output:

           


```
## [

which is only the first 22 characters. The decryption works in R with the digest::AES function, so I know it can work:

id = '123'
key = digest::digest(pp, algo='sha256', serialize = FALSE, raw = TRUE)
aes_e = digest::AES(key)

"KQdciM892XEZXYC+jm4sWsijh/fQ4z/PRlpIHQG/+fM=" |>
  base64enc::base64decode() |>
  aes_e$decrypt() 
# [1] "           \n\n\n```\n## [1] 2\n```\n\n"

So I suspect I misunderstand how forge works, though I have followed the documentation examples on GitHub here and here. This also happened when I tried AES-CBC.

How do I get the whole text?

You need to disable the default PKCS#7 padding on the forge-side, i.e. replace decipher.finish() by
decipher.finish(() => true), s. here. Then the full plaintext is returned:

<!-- begin snippet: js hide: false console: true babel: false -->

<!-- language: lang-js -->

seed = 'hi';
text = 'KQdciM892XEZXYC+jm4sWsijh/fQ4z/PRlpIHQG/+fM=';

function decrypt(seed, text){
  md = forge.md.sha256.create();
  md.update(seed);
  const key = md.digest().getBytes(32);
  const cypher = forge.util.createBuffer(forge.util.decode64(text), 'raw');
  
  // This seems right
  console.log(cypher.toHex());
  
  var decipher = forge.cipher.createDecipher('AES-ECB', key);
  decipher.start();
  decipher.update(cypher);
  //const result = decipher.finish();
  const result = decipher.finish(() => true); // disable un-padding
  if(result){
    const out = decipher.output;
    console.log(out.toHex());
    const dec = forge.util.encodeUtf8(out);
    console.log(dec);
  }else{
    console.log('Bad key.');
  }
}

decrypt(seed, text);

<!-- language: lang-html -->

<script src="https://cdnjs.cloudflare.com/ajax/libs/forge/1.3.1/forge.min.js"></script>

<!-- end snippet -->

Note that for block cipher modes like ECB, padding during encryption can only be omitted if the length of the plaintext is an integer multiple of the block size (16 bytes for AES), which is satisfied here with 2*16=32 bytes.

Also, be aware that ECB is an insecure mode and a key derivation via a fast digest (like SHA256) is a vulnerability.

Edit:

• Regarding your first comment: A non-authenticated decryption (e.g. with AES/ECB) in itself does not allow to distinguish between a correct and incorrect result. If the key is correct, the original plaintext is returned, if the key is incorrect, a random byte sequence (or more precisely, a byte sequence that is indistinguishable from a random byte sequence) is returned. In the case of a wrong key / a random byte sequence, there is generally no valid padding.

  With padding enabled, many libraries use an invalid padding as an indicator for a failed decryption, like the forge library throwing a Bad key exception. However, this is not a reliable indicator, because even with a wrong key, a valid padding could accidentally result.

  If padding is disabled, the padding criterion does not apply. A wrong key is then only noticeable by the fact that not the original plaintext but an arbitrary byte sequence is returned or by consequential errors (e.g. in the posted forge code, the decrypted data is UTF-8 decoded; since an arbitrary byte sequence is generally not UTF-8 compliant, the subsequent UTF-8 decoding generally causes a consequential error).
  Therefore, it is quite normal that the Bad Key exception no longer occurs when padding is disabled.

  The R code behaves the same way with an incorrect key: return an arbitrary byte sequence without error message.

  For completeness, there is authenticated encryption that implicitly checks the integrity of the data (e.g. AES/GCM).

• Regarding your second comment: I haven't looked at the R implementation, so I can't rule out a padding bug. But a missing padding should not be classified as a bug a priori!

  Many libraries use a default padding for block cipher modes for convenience/robustness. However, there are also libraries that do not do this, i.e. that separate encryption and padding (similar to encoding and encryption) by dedicated functions. There are just different philosophies here.