Tag Info

Hot answers tagged

6

The capacity of AES in terms of file encryption is practically unlimited for the time being, especially in OFB or CTR mode. An 8 GB file comprises short of $2^{29}$ 128-bit AES blocks. If one uses CBC or OFB CFB mode, odds of a collision (that is, the same block appearing in ciphertext, which reveals 128 bit worth of potentially usable information about the ...


6

If you mean how much data can safely be encrypted by AES with a single key (and IV), AES is designed to encrypt up to $2^{64}$ blocks of data before becoming susceptible to certain statistical attacks (in particular distinguishing the encrypted file from truly random data), because of its 128-bit block size. 8GB (= $2^{36}$ bits = $2^{29}$ blocks) is quite ...


6

The question has morphed over time. I am answering the following. So to be sure, with DES, only when you encrypt something twice with a weak key. You get the back the original plaintext? That is correct as that is the definition of a DES weak key, a key for which encryption and decryption have the same effect. So when using DES in OFB mode with a ...


5

Just use the build in crypto PRNG of your operating system or framework. C# / .net: RNGCryptoServiceProvider Class Java: SecureRandom Class Linux: /dev/urandom Win32 API: CryptGenRandom function date/time might be enough for modes which only require uniqueness, but if you generate two IVs in quick succession(within 16ms or so) or if the clock is changed. ...


5

The choice or PRNG doesn't really matter much, as long as it's a decent one. I wouldn't use BBS because it's slow, and the security proof isn't too useful. The interesting question is rather, how to seed the PRNG with sufficient entropy. You need a sufficient amount of data that an attacker can't predict. I strongly recommend not doing this yourself, but to ...


4

The properties that an IV must meet are strongly dependent on the mode that the IV is be used in. Some modes require unpredictability; other modes don't care about unpredictability but require uniqueness. As for OFB mode, it's in the 'don't care about unpredictability, but require uniqueness' camp. In particular, as long as you never reuse an IV, and you ...


4

Well, assuming that you have a fixed block cipher (that is, you don't change the block cipher as the length of the message increases), then given a message of length $N$: Both ECB and OFB take $O(N)$ time for both encryption and decryption. Both ECB and OFB take $O(1)$ space in addition to the space to hold the encrypted/decrypted message (which is ...


4

Will I encrypt the Initialization Vector like a block of plaintext? to generate keystream and I will XOR it to the plaintext to generate ciphertext? Yes, for the first block of plaintext. For the subsequent blocks, you use the output of the previous encryption (before XOR) as the input to the cipher (along with the same key).


4

No, it is not a good idea to use the Blum Blum Shub Generator to generate an Initialization Vector for a block cipher operated in OFB mode. In this usage, one needs that the IV has negligible chance to match an earlier IV used with the same key. The exact requirement is that the IV has negligible chance to match an input to the block cipher used in ...


3

OFB is a mode of operation to ensure confidentiality of messages a) longer than the block size of the encryption algorithm, and b) that can be re-broadcast. The motivation for these kinds of modes it to avoid the weaknesses that come from using plain ECB mode. To be precise, the typical attack on ECB mode involves analyzing the ciphertext and looking for ...


3

Well, if the block cipher is modeled as a random $N$ bit permutation (that is, each permutation from the set of $2^N$ bit patterns to itself is equally probable), then the answer is really quite easy (and this answer is exact): the probability that we will repeat a block within $M$ outputs is precisely $(M-1) 2^{-N}$ (for $0 < M \le 2^N+1$). The ...


2

ECB mode is a deterministic encryption, instead in OFB if the initial vector is random choosed (and of course published with the cryptogram) is a random encryption. What's the matter with det.enc.? The problem is that if you encoded two time the same message you are going to get two time the same chipertext, so the adversary can understand that you said the ...


2

As noted by poncho, both ECB and OFB encryption (and decryption) require $O(n)$ time and $O(1)$ additional space (excluding the input and output, which may be modeled as unseekable streams). These hold both in the average and in the worst case, and it's worth noting that the complexities approach their asymptotes very quickly; typically, the time complexity ...


2

A quick follow up, there is a problem with using DES in OFB mode when you are not using the full feedback register. The generated keystream will become cyclic with on average a period of the order $2^{32}$ instead of $2^{64}$. See (R.R. Jueneman, “Analysis of certain aspects of Output Feedback Mode,” Advances in Cryptology, Proceedings Crypto’82, D. ...


2

An important point for both the one-time pad as well as other (synchronous) stream ciphers is: don't reuse your key stream. For the one-time pad, the key stream is the key itself, so this means: don't use a key twice. The two-times-pad is broken. For OFB and other stream ciphers with an initialization vector (IV), the key stream is decided by both key and ...


2

OFB is a method of converting a block cipher, like AES or DES, into a stream cipher. Because One Time Pad is theoretically secure (though impractical) people often try to make stream ciphers that try to approximate one time pad. OFB is a way of taking a block cipher to try to emulate the security you get from one time pad. A key distinction is that OTP is ...


2

As @CodesInChaos said, OFB is a stream cipher. The one-time pad is a stream cipher, too. One difference is that the one-time pad is information-theoretically secure, while OFB is computationally secure.


2

There is no real advantage, other than the fact that it allows you to convert a block cipher into a stream cipher securely. Since there has been a large amount of research put into block ciphers and ciphers such as AES are commonly implemented in hardware (such as AES-NI), it allows for reuse of the primitives. Side note: the nonce generally does not need ...


1

Problem statement You have a list of messages $(m_1, m_2, \dots, m_n)$, possibly with corresponding tags/descriptions $(t_1, t_2, \dots, t_n)$, that you want to store. You want to protect confidentiality of the messages (but not the tags/descriptions) against an adversary that compromises your storage. You have a single secret passphrase $pw$ at your ...


1

Why don't you use SecureRandom generator (if you're on Linux/Android and Java)? SecureRandom sr=SecureRandom.getInstance("SHA1PRNG"); byte[] IV=new byte[length_of_IV]; sr.nextBytes(IV); Then IV will contain strongly random bytes. Note: Don't forget to use dev/urandom rather than dev/random in your java.security file otherwise the above code will not ...


1

Wikipedia has an excellent visual demonstration of the insecurity of ECB mode when applied to (potentially) repetitive data: Here, the first picture on the left shows a simple cartoon image (Tux the Penguin). The second image is the same, but with the (raw, uncompressed RGB) image data encrypted using ECB mode. While details of the image are ...



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