Hot answers tagged

21

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 ...


13

The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks.


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 ...


9

I would pick e) none of the above. None of those modes offers integrity protection, so unless integrity is handled elsewhere, your application is wildly insecure. An attacker could modify bits in transit and do nefarious things. Of the three, CFB and CTR are the worst for the application and should be very easy for an attacker to mount successful attacks, ...


9

You would not just need a mode of operation for what you're asking. What you need is a secure transport protocol. Probably the best well known one for TCP connections is TLS of course. For UDP connections you could use DTLS. If you have a shared key you could use one of the pre-shared key (PSK) variants. If you want to create your own transport protocol you ...


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 ...


5

In general, use a cryptographic MAC to protect your ciphertext, and verify it first. Emit those errors. Then padding errors should not occur at all. The "in general" seems to have been used to show that commonly is performed or should be performed. I don't think it had anything to do with the security of the scheme itself. PKCS#7 compatible padding can ...


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

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.


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 ...


4

The key that was used in the AES/Rijndael for encryption is passed through a hash function (strikethrough/strikeout mine) That's OK if the hash function is secure and not vulnerable to timing attacks. Obviously MD5 is not a great option as it has been proven to be insecure. For this specific function however - similar to key derivation - it's OK. You ...


4

No, this is not a secure way of encrypting. Specifically, it does not meet the requirements for indistinguishability under chosen plaintext attack (IND-CPA), a basic security definition for encryption. According to IND-CPA, no attacker should be able to win the following game: The attacker selects two equal-length plaintext messages. The defender picks ...


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

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

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

It is the IV as a whole that needs to be unpredictable... but knowing some bits would make guessing the IV easier. The requirement of an unpredictable IV has to do with chosen plaintext attacks. If the attacker can predict the IV, they can choose the first block of plaintext such that they can verify any guesses they have for the content of previous ...


3

As you know, it makes reading and writing the disk very slow if all the data in the drive is chained together. If so, writing to a drive of size $n$ at position $p$ will require $\Theta (n-p)$ time. One solution is the drive being divided into sectors, and each sector being chained. The IV of each sector can be attained using ESSIV. it generates IVs from a ...


2

Generating the IV for CBC mode by encrypting a counter is one of the IV generation methods recommended in NIST SP 800-38A, Appendix C: "There are two recommended methods for generating unpredictable IVs. The first method is to apply the forward cipher function, under the same key that is used for the encryption of the plaintext, to a nonce. The nonce ...


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

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

I suppose you have removed the base64 decoding, so you are working on the raw data. Then indeed the first block is decrypted as if we were in ECB-mode, because after decrypting the first block, we xor with the IV, which is all 0 and indeed has no effect. However, the IV for the next block will be the original previous ciphertext block. So after decrypting ...


2

Is the above example correct? If not, how can the IV to be used for decryption be determined? Yes, it is correct. The vector/mask in CBC mode is generally the previous ciphertext block. The algorithms in 2a and 2b simply extends this notion to the IV so that the CBC mode encryption doesn't have to be re-initialized. The outcome of the IV ...



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