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


6

the key and plaintext is the same. The attacker knows this and the IVs used but doesn't know the plaintext. Is there anything to learn about the plaintext when multiple ciphertexts are available instead of only one? No. Giving the attacker multiple encryptions of a single plaintext using a randomly chosen IV and a fixed key with AES-CBC does not leak any ...


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

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), and ...


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


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

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

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

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

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


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

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

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

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

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

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


3

If you have a nonrepeating (but possibly predictable) value, you can convert that into an unpredictable CBC-mode IV at fairly minimal cost. Here's how: Prepend the 128 bit nonrepeating value to the message CBC mode encrypt the (value, message), using any IV that's not correlated to the nonrepeating value (all 0's work) Use the first 16 bytes of the ...


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 decryption won'...


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

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



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