Let's suppose I want a 2048-bit block encryption.

I take a 512-bit hash funcion (as Blake2b), provide a counter and a key and hash the counter and so XOR the hashed value in a ciphertext block, and repeat this process more times with different counters and keys up to the fourth key (2048/4=512=bits taken by hash function).

Will this method be vulnerable to MITM attacks?

Will this method be vulnerable to quantum attacks, and Groover's algorithm

Will I get 2048-bits of encryption strength?

  • 2
    $\begingroup$ Why do you need 2048-bit symmetric security? Even 256-bit AES or ChaCha20 will be enough secure and quantum-safe! $\endgroup$
    – kelalaka
    Dec 23, 2021 at 6:55
  • $\begingroup$ I need because I'm paranoid, I have top secret materials and I want to create a disk encryption program which will use larger keys than 256/512. $\endgroup$ Dec 23, 2021 at 17:06
  • 1
    $\begingroup$ Paranoid of what and whom? There is no entity that can break 256-bit encryption either classical or quantum or both combined. If you are really paranoid, you might consider evaluating your risks. Where do you encrypt the files, who can access and where, what is the encryption mode of operation how the keys are stored... $\endgroup$
    – kelalaka
    Dec 23, 2021 at 17:15
  • $\begingroup$ I encrypt my external HD and my OS, the keys are safely stored and other person who I asked will destroy the keys if I die, I use CTR in 3 layers of Threefish with 1024-bit keys. I believe I'm safe. $\endgroup$ Dec 23, 2021 at 19:08
  • $\begingroup$ We don't encrypt harddisks with CTR mode anymore, XEX/XTs are preferred. Why don't you just use Veracrypt to handle most important parts for you? $\endgroup$
    – kelalaka
    Dec 23, 2021 at 19:48

2 Answers 2


While it possible to construct a stream cipher from a hash function. This construction has one very serious flaw.

The largest issue is you have no nonce so if your key is reused it becomes trivial to decrypt both messages since your just xor-ing the plaintext.

What you effectively has is the following per block: Construction

Further, you will not get 2048 bits of encryption here. For instance I could attack the first 512 bits of cipher the text. Which means I only have to find the first key. Same for the second key ect... So for the entire block your only having to find 4 keys. So you effectively only increased the key length by 2 bits. This is because each key is independent of the other so in a brute-force attack changing one does not effect the other keys. So if your goal was 2048 bits of key strength it's even worse than a meet in the middle attack. It's basically only as strong as your starting keys bit length.

Also such a large key is kinda pointless for symmetric ciphers.

The post quantum security of hash functions like BLAKE2b are already quite secure especially with a 512 bit digest.

  • $\begingroup$ I understand, thank you for the answer. $\endgroup$ Dec 23, 2021 at 17:05
  • $\begingroup$ I think you are wrong. If someone have to brute-force two 512-bit keys in this method, for each try in the first key he must have to check another 2^512 values of second key, so having to do 2^(512*2) tries in the entire scheme (1024-bit). How can someone determine if one key among 2^512 keys is the right key which will produce the exact hashed material? How can someone determine if a single hashed value in 2^512 results is the right hash? $\endgroup$ Dec 23, 2021 at 19:28
  • $\begingroup$ Let's suppose I hash a counter "123" with a key K generating the hash H. How could you determine that H is a sub-product of "123" with a key K? $\endgroup$ Dec 23, 2021 at 19:49
  • $\begingroup$ The construction you describe, each key is only responsible for a 512 bit chunk in the block. So I only need to consider each 512 bit chunk. The counter is not secret either and can be inferred from the cipher text length. So has no effect on the key strength. Since a key is just a number 0 to 2^n - 1. With your construction of 4 keys, I could try a key on each 512 bit chunk which there are 4 of. So as I count up through keys I am only doing only 4 times the work. No space trade off either which is why I say it's worse than a MITM attack if your goal is a 2048 bit key. $\endgroup$
    – Keith
    Dec 24, 2021 at 7:14
  • $\begingroup$ Looking at your other comments, and the fact your concerned with post quantum security. Symmetric block and streams ciphers with 256 bits are still insanely secure. Perhaps your confusing bit key strength with asymmetric ciphers like ECC, and RSA which if there was a large enough quantum computer computer could break. However, for symmetric cryptography: i.g. ciphers like AES, ChaCha20 ect... A 256 bit key is enough. Large keys are also harder to handle in a secure manner. It's reasonable to memorize a 256 bit key, a 2048 bit key will need to be stored on something which could be stolen ect... $\endgroup$
    – Keith
    Dec 24, 2021 at 7:31

Will this method be vulnerable to MITM attacks?

What you describe is ECB mode. If you use the same key more than once, then yes, it is vulnerable to MITM attacks. The MITM can replace some blocks in one message with blocks with the same numbers from another message. The modified message will be perfectly decryptable and there is no way to determine if it was modified.

Your scheme will produce the same result for the same plaintext if the same password is used. Thus, knowing some messages it will be possible to decrypt some other messages: If some blocks with the same number are the same, then also the plain text is the same.

  • $\begingroup$ I mean: Hashing a counter. Each hashed block will be different from each other. $\endgroup$ Jan 7, 2022 at 1:04
  • $\begingroup$ @phantomcraft: Sure, hashed counter for the 1st block will be different from the hashed counter for the 2nd block. But all messages will have the same hashed counter for the 1st block. And all messages will have the same hashed counter for the 2st block (different from the 1st block, but the same for all messages). Etc. $\endgroup$
    – mentallurg
    Jan 7, 2022 at 2:50
  • $\begingroup$ @phantomcraft: Consequence: Since all messages use the same hashed counter for the 1st block, an attacker can replace the 1st block of message A with the 1st bock of message B. In your scheme, there is no way to detect if the 1st block was replaced. Suppose the original content of the 1st block in message A is "Transfer 1000 USD to the account 111111111.", the 1st block in message B is "Transfer 1000000 USD to the account 222222222." The attacker can replace the 1st block of message A with the 1st block of message B, without even knowing the password, and you will not detect it. $\endgroup$
    – mentallurg
    Jan 7, 2022 at 2:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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