# Tag Info

20

It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...

9

CBC mode decryption for the first block is defined as: $$P_0 = IV \oplus D_k( C_0 )$$ where $P_0$ is the first plaintext block, $C_0$ is the first ciphertext block, and $D_k$ is the decryption by the block cipher using the key $k$. This can be rearranged as: $$IV = P_0 \oplus D_k( C_0 )$$ which allows you to reconstruct the IV, if you know the key, the ...

7

In the first block, the IV provides the "randomness", and in subsequent blocks you just use the previous block of ciphertext instead. Based on the assumption, that the cipher is not weak and behaves like a pseudorandom permutation, this is basically the same: You XOR something unpredictable on the plaintext, and then encrypt. As long as the IV is chosen ...

6

The modes you are referencing are specifically modes of operations for block ciphers, and therefore are not directly applicable to hash functions. Block cipher operations take 2 inputs, the key and a block-sized input value, and output a block-sized keyed permutation of the input. Hash functions take a variable length input, and output a fixed length value. ...

6

In this answer I'm assuming that a key is used to encrypt more than one message. The first weakness is that CBC with fixed IV leaks if messages share a common prefix. The second weakness is that it makes a padding oracle attack much more severe. Consider a device that knows the key and decrypts a ciphertext you send to it. While it won't tell you the ...

5

At a high level, the major flaw is that you are rolling your own crypto protocol. You should strongly consider using a standardized protocol like DTLS. Some specific problems: Symmetric key distribution is left unspecified. Keys must be changed occasionally to thwart distinguishers. No way to recover from symmetric key compromise. Your message ...

5

A Padding Oracle attack due to my use of CBC Cipher Mode CBC in and of itself does not directly result in a padding oracle. It is when you abuse the padding after decryption to decide whether or not decryption was successful and then communicate (maybe not even directly) the results of that padding check. Based on your comment that The connection ...

4

If you have an error in a cipher text block you can generally represent this as: $$C'=C\oplus\Delta$$ Now if you try to decrypt this block using the previous ciphertext block $IV$ as IV you get $P'=IV\oplus D_K(C\oplus\Delta)$ which is completely unrelated to $P=IV\oplus D_K(C)$ assuming the block cipher acts as a pseudo-random permutation. As the input ...

4

What is this method/algorithm/construction called? Dunno; this is a new one on me. Is it as secure as CBC implemented the normal way? Should be. Modeled as an abstract 'take plaintext, output ciphertext' model, this method (with a random last ciphertext bits) has precisely the same ciphertext output distribution as CBC mode (with a random IV), ...

4

First, the advice: What are the best-practices to store the message length / strip away padding? Use standard padding, like PKCS#7 padding. It handles finding the length uniquely for you. Use encrypt-then-MAC to prevent padding oracle attacks. (Or better yet, don't use CBC. Use an authenticated encryption mode like GCM, or use CTR+MAC which doesn't ...

4

No, it is not necessarily secure. Here is a simplified example of why not. Assume one block zero messages are encrypted without padding. The ciphertext is $I||E(I \oplus 0)$. The MAC value is thus $E(E(I) \oplus E(I)) = E(0)$. So regardless of the IV, the MAC is the same for all such messages. So if you encrypt several zero messages you can leak that fact ...

3

Your mode is essentially equivalent to CFB mode, except that: you've reversed the order of the blocks in the message, and you're using the block cipher in the opposite direction than usual. Neither of those differences should have any direct security implications (since all standard block ciphers have the same security properties in both directions), ...

3

The "interesting" part of your encryption is here: Therefore, I prepend a block at the beginning of my packet. Its content goes as follows: First four bytes: current timestamp in seconds Next 12 bytes: zeros I compute the sha256 hash of the message (32 bytes) I xor the timestamp + zeros block with the first half of the hash I xor the ...

3

Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations. Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on ...

3

As long as the IV is chosen correctly, every individual block of the encrypted output will be uniformly random over the set of all bit-patterns of the given size. Each block is independent from the clear text, but they are not independent from each other. The first block contains the IV itself, which by construction is uniformly random and independent from ...

3

Yes there is a significant difference concerning brute-force. ECB suffers from multi target attacks whenever you encrypt the same message block. This is always possible in a chosen-plaintext attack and often possible in practice with a known-plaintext attack. With CBC the IV means that the plaintexts passed to the blockcipher are almost certainly unique ...

3

As Maarten Bodewes already wrote in a comment, if you ignore the computational overhead of XOR, then there is essentially no difference in CBC and ECB for a bruteforce attack. However, the question is actually mixing oranges and apples (and it is not obvious), because the security weakness of modes of operation has nothing to do with the underlying ...

3

The schemas from the relevant Wikipedia page really explain it all: As you see in the decryption schema, the IV is used for a single XOR that yields the first plaintext block; it is obvious that the IV impacts only that block. When encrypting, though, modifying the IV alters the first ciphertext block, then the second ciphertext block, and so on. The ...

3

In RFC2246, if you need 12 bytes of padding total, that means that you have 11 padding bytes, followed by a padding length field. So, each padding byte has a value of 11 (0x0b), as well as the padding length field. This is implied by the requirement that the total TLSCiphertext.length must be a multiple of the block size, and this TLSCiphertext.length ...

3

POODLE is primarily a padding oracle attack against SSLv3.0, which is inherently vulnerable to the attack due to the protocol design. The "on downgraded legacy encryption" part of POODLE's name comes from the fact that most SSL/TLS client implementations will allow a TLS connection to downgrade to SSLv3.0 if the handshake fails - see this answer for more ...

3

Yes, this is fine. There is a practical disadvantage in space used, if you don't otherwise need to store the size in plaintext. A size field will usually take 32 or 64 bits, whereas typical padding adds one byte on average. Also, if you use encrypt-then-MAC you need to include the length as part of the authenticated data.

2

To show that a family of functions is not a PRP, you have to either show that the functions are not permutations or that they do not behave pseudo-randomly. As it is already established that the functions are in fact permutation you need to show the latter. For a family of permutations to be a PRP means that it is computationally infeasible to distinguish a ...

2

Yes, we always have to pad the message. The reason is simple: How do we know if the message has a padding or not if we don't always pad? Let's say we pad with adding only $0$ bits. We got the (after padding) message $0101\,1100\,0000\,0000$ and a block size of 2 bytes (16 bits). Well, what was the original message? Was it $0101\,11$? Or was it $0101\,1100$? ...

2

SSL padding always pads, using 1..blocksize bytes (8 bytes for triple DES, 16 for AES). This padding makes it deterministic independently of the value of the plaintext. It's a padding mode similar to ISO 10126 (only the last padding byte is one less). Other padding values - such as the zero padding performed by PHP's mcrypt library - are also ...

2

If the last byte in the block is larger than the block size, that would generate a padding error in SSL 3.0. SSL 3.0 padding is up to $BlockSize-1$ bytes of unspecified data, and one byte with the length of the padding (not including the length byte itself). TLS 1.0 and above allow padding longer than the block size, and requires that each byte contains ...

2

Normal CBC mode cannot be parallelized during encryption; that's because CBC mode encryption is defined as: $$C_i = E_k(C_{i-1} + P_i)$$ That is, what you encrypt during the processing of block $i$ depends on ciphertext of block $i-1$; hence you can't start the next block until you've completed processing of the previous block. You can't do any ...

2

Patterns aren't hidden. Assume you've got a pair of plaintext blocks $p_1, p_2$ then the encryption of $p_2$ will always be the same: $c_2=E_k(p_1 \oplus p_2)$ as it only depends on the plaintext. So you haven't basically solved the basic problem of ECB (patterns remain) but rather moved it (to the more rare case) that two blocks repeat. Plaintext isn't ...

2

CTR consists of two parts: construction the key stream using a counter, and XOR-ing the output of the key stream with the plaintext/ciphertext. The key stream can be generated using a PRF, in which case it is of course not invertible. The key stream can also be created using a PRP (e.g. a block cipher like AES) in which case it is invertible. As indicated, ...

2

Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to ...

2

If the IV is all zeroes, then you basically have ECB for the first block. Basically you're proposing to use this first block's encryption as the IV for the second block. You're implying that the first block will always be unique, but low entropy, which sounds like a counter or time stamp. There are attacks when the IV is predictable, and while this is a ...

Only top voted, non community-wiki answers of a minimum length are eligible