# Tag Info

2

A secure cipher is required to produce ciphertexts that are computationally indistinguishable from random strings, so somebody might naïvely think that this is sufficient for your iterated ciphers to be safe. But no, it's not sufficient, because for the iteration to be safe the ciphers also need to be statistically independent of each other. On trivial ...

4

When combined with your comments, I can say this is unsafe in the sense that it is highly advised against "rolling your own encryption." It looks to me like you are layering multiple encryption methods together without too great of a concern for understanding the attacks made against them. Is this secure? Maybe. In theory, we designed these ...

3

AES-CTR is not considered as a CSPRNG, why? I don't know why this was given as a negative. AES-CTR can certainly used to generate a pseudo random stream of values. If that alone makes it a CSPRNG is up for debate if you ask me. For instance, the DRBG's specified by NIST all provide a reseeding operation, which is missing from AES-CTR. Although they do ...

0

Though AES is more secure than RSA in same bit size, AES is symmetrical encryption. That's why SSL certificate can't use AES, but must be asymmetrical ones, e.g. RSA or ECDSA. AES is used in SSL data session, i.e. SSL negotiation is basically to define AES key to be used by data session. Anyway, RSA is going away. ECDSA can provide stronger encryption at ...

3

In some applications, a serious limiting factor for the security of 4DES is its 64-bit block size. In common modes of operation, that limits the security to data sizes that are insufficient for many application nowadays. It makes 4DES much less secure than AES-128 is. For example, assume a VPN in CBC mode using a fixed key. Assume an adversary injects known ...

7

In C, multiplication in the field $\operatorname{GF}(2^8)$ with reduction polynomial $x^8+x^4+x^3+x+1$ can be coded as one of these three functionally equivalent functions: uint8_t mult1B_compact(uint8_t a, uint8_t b) { uint8_t r = 0, i = 8; while(i) r = (-(b>>--i & 1) & a) ^ (-(r>>7) & 0x1B) ^ (r+r); return r; } ...

2

It's necessary to have all components in constant time for them to be side-channel-free; what's more, time isn't the only side-channel that an implementation have to be consider. I've attempted making my implementation side-channel free, starting from finite-field multiplication: static inline uint8_t xtime(uint16_t x) { x = ((x << 1) & 0x00ff) ...

1

If I understand correctly, your input to HMAC is the ciphertext $c$, padded with null bytes (to a multiple of 16 bytes): # pad to a multiple of 16 bytes if self._len_ct & 0x0F: self._auth.update(bytes(16 - (self._len_ct & 0x0F))) As a concrete example, suppose the ciphertext is $c=$ deadbeef00, then you will compute the HMAC tag as $t ... 3 If the ciphertext is the same size as the plaintext, then yes with 100% probability. There are only finitely many values the ciphertext can take. So repeatedly encrypting the ciphertext, means that a value must repeat eventually. If this cycle doesn't include the original message, then there is some ciphertext that has an ambiguous decryption (because two ... 3 But does the padding precipitate a weakness in the encryption? If padding oracle exist then you can decrypt the entire ciphertext in 128 tries per byte (on average). However, similar plaintext oracle attacks may be about as strong, and plaintext oracles are not just about CBC mode either. You will need to use an authenticated cipher (such as AES-GCM) to ... 5 I could've sworn this was a duplicate question, but I can't find a good match for it here right now, so let me answer it instead. What if size of encrypted input is always less or equal 16 bytes? I suspect AES/ECB will be as good as AES/CBC in this case... For plaintexts shorter than the cipher block size (i.e. 16 bytes for AES), CBC mode encryption is ... 3 A third possible reason one might do this is to allow quick erasure. Suppose you want to securely delete Text1, that is, make sure that no one, not you, not a hacker, not the TLA that gains access to the computer, can possibly recover it. Now, E(Text1) may be lengthy, and scrubbing it from the files may take more time than we would care to take (and we ... 4 How would one go about constructing such a cipher? Has it been done? Can it be done? If you have a key which is at least as long as the message (and don't reuse the key to encrypt a second message), we know how to do that (and it isn't that hard). Other than that, no, we don't know how to do it; we don't even know that it can be done. The closest we can ... 5 With this in mind, one would obviously want a cipher that is mathematically provable to be resistant to KPA. Any scheme that has a message space larger than the key space and is unconditionally provably resistant against known-plaintext attacks while being efficiently computable immediately implies$P\neq NP$. As we don't know for sure whether$P\neq NP$... 4 If you are talking about FHE (as stated in the title, but not in the question body) then yes, this is possible. Encrypt the symmetric key$k$that was used to originally encrypt the data as well as the symmetric ciphertext$c$under the FHE public key. Then homomorphically evaluate the decryption circuit of the symmetric encryption scheme on those ... 3 Q0 : Is the precomputed key stream vulnerable to side-channel attacks like a lookup table for exemple ? Of course not; once it is precomputed it sits in memory. Even if it is accessed, no actions are performed that depend on the randomized stream - other than the XOR with the plaintext of course. In principle that could be vulnerable, but since nothing is ... 4 Natural language has a nonuniform distribution. If a character$x$appears$N_x$times in a candidate decryption with$N$characters, the sample entropy estimate will be $$\sum_{x \in X} (N_x/N) \log (N/N_x)$$ by Shannon’s formula, where$X\$ is the set of characters. If the decryption is incorrect (wrong key guess) this value will be high, nearly equal to ...

Top 50 recent answers are included