Hot answers tagged

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


5

What you are asking is a straight application of Format Preserving Encryption, which builds ciphers which input and output are in a constrained format (generically: common to input and output, hence preserved). The FPE field has many articles with proven techniques; and proposed standards, including BPS and SP800-38G Draft. Note: the method tentatively ...


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


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



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