# Tag Info

## Hot answers tagged ofb

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

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

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

4

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

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

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

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

Forget OFB mode. You should use CTR (counter) mode. It has the best bounds, and is parallelizable. This means that when you are using the AES-NI instruction set, encrypt with CTR is about 7 times faster than CBC, OFB etc. If you encrypt in OpenSSL you will get this performance. For a good thorough analysis and comparison of modes of operation, see ...

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

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

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

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

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

Yes, it is correct. Just follow the bits in the decryption pictures on the Wikipedia page about modes of operation. Modes of operation don't have to have a meaning compared to other modes of operation. I don't see CFB or OFB used too much anymore. OFB with partial feedback has been shown to be less secure, so that shouldn't be used anymore. Currently the ...

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

2

I have a problem with OFB mode, because I have heard that it is stronger than CFB. On the contrary I would say that CFB is stronger. OFB means encrypting the IV again and again to produce the keystream. If you end up in a cycle, the keystream will start repeating itself. (This should not be a practical weakness, but why chance it?) CFB is more like ...

1

Actually, I think I found the answer to my question while writing it, but I'll post it anyway, since it might be interesting to others: Yes, OFB mode is secure even with 8-bit feedback, at least as long as IVs are chosen randomly. Specifically, in the paper "New proof for old modes" (IACR Cryptology ePrint Archive, 2008), which I've cited earlier here, ...

1

No OFB_DRBG isn't directly vulnerable to attacks. However from a theoretical standpoint there is one point speaking against it and in favor of CTR_DRBG. Speed. CTR can be parallelized (can encrypt counters in parallel), OFB can't (encrypting state over and over again) So the main reason is speed I'd guess and of course adding OFB_DRBG wouldn't have added ...

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

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