7
First of all, GCM is a form of counter mode. Which means that unlike with e.g. cipher block chaining, the output of one block depends on exactly one block of input. Worse, yet: You can modify a single bit and the decrypted result will differ in exactly that bit. Because if you are honest, a block cipher in counter mode is not a "block cipher" at all, but a (...
3
It would not improve security at all.
For AES-CTR mode, encryption and decryption use the same algorithm: generate the key stream using the counter and then XOR the plaintext with it. Because of that, step 1 and 3 would completely cancel each other out, and you would be left with the "decryption" in step 2.
If you'd just use the first two steps then you ...
3
The practical answer is that you should almost certainly be using authenticated encryption, in which case authenticating an individual encrypted message requires you to process all of it anyway. Once you throw in this element, random access into encrypted data becomes not a matter of message encryption modes, but rather of how to split your data into a ...
3
What it means is that neither CTR nor OFB detects errors in a message, and that an adversary can flip arbitrary bits of their choice in the plaintext very easily—by flipping the corresponding bits of ciphertext. This is because both CTR and OFB essentially work by using the block cipher as a stream cipher to pseudorandomly generate a one-time pad to xor ...
1
Would adding more rounds to AES increase security?
Not really.
The cheapest known attacks on AES today are essentially generic key searches. That is, they don't really depend on the details of AES itself. If you increased the number of rounds, that would slightly raise the cost of testing each key, but it would also raise the cost of using your AES ...
1
Both OFB and LFSR use the output of one iteration of the function as input for a new iteration. Furthermore, both OFB and LFSR generate a pseudo random stream of bits / bytes. This stream can be used as key stream to encrypt/decrypt data, turning the algorithm into a stream cipher.
There is a difference if the output of the last iteration is used to to ...
1
The property that you are looking for is the "online" property of a stream cipher. CCM was however developed for packet encryption where the size of the data is known beforehand. So CCM lacks the strict online requirements for an online cipher. However, since the cipher underneath still uses counter mode, the encryption itself can still be performed on each ...
1
The genesis block is embedded in the chainblock (the hash of all the transactions since the bitcoin network was powered on).
Now, from your question I deduce that you know little about cryptography and in particular hash functions and the blockchain protocol so I will try to explain myself in the simplest (and obviously incomplete) way possible:
Blockchain ...
1
I will assume you're asking about NaCl crypto_secretbox, although the same considerations apply everywhere ‘nonce’ appears in the NaCl API.
Is it bad if I encrypt every field with the same key and nonce?
Yes, it is very bad. If you reuse a key/nonce pair for two different messages, you violate the security contract of NaCl. It is so bad that an ...
1
TLDR: from a theoretical standpoint counting the number of block encryptions for known plaintext attack, what's proposed increases security by less than 3 keys bits (or less assuming many messages). From a practical standpoint, what's proposed is pointless, because one layer of AES-256 is more than safe enough against all except attacks targeting the ...
1
I assume you were thinking about changing the block cipher inside the CTR construction, i.e., instead of encrypting each counter with AES, you would encrypt with "3AES".
First, notice that 3DES normally uses three keys and not two. Three-keys 3DES has 112-bit security level, while two-keys 3DES has around 80-bit.
So, I'm assuming you want to use CTR mode ...
Only top voted, non community-wiki answers of a minimum length are eligible
