Re: RijndaelManaged and Rijndael CryptoTransforms do not support CFB or OFB CrytoModes

From: Rob Teixeira [MVP] (RobTeixeira_at_@msn.com)
Date: 06/16/04

  • Next message: Chris: "Re: RijndaelManaged and Rijndael CryptoTransforms do not support CFB or OFB CrytoModes" 
    Date: Tue, 15 Jun 2004 20:05:11 -0400

    Inline...

    "Chris" <chrisNnOoSsPpAaMmtanger@technocisive.com> wrote in message
    news:e1K9MLyUEHA.2988@TK2MSFTNGP10.phx.gbl...
    > Thanks for the explanation. I was surprised to see the following
    > comment that you made "You can create as many cryptostreams as you want,
    and
    > reuse the underlying stream and cipher transform instance." For a given
    > transform instance the same IV will be used to start off on the first
    block
    > of data each time the transform is used. I do not wish to reuse my
    > transform instance because if I encrypt two different messages and the
    first
    > "blocksize length of" of plaintext is identical, then the initial
    ciphertext
    > for both messages will also be identical. If I understand correctly this
    > would allow an attacker to build a "code book".

    In CFB mode, it is *vital* that you rotate IVs as often as possible. In CBC
    mode, it isn't as important. Building a codebook based on this method isn't
    as easy as it looks, and only really works well if the potential attacker
    can induce plain text data into your encryption process himself. But
    rotating IV values will always give you stronger results. The only problem
    is that now you have to negotiate the new IV with the client before each new
    message.

    > Reusing the underlying stream gives me some good ideas. What do you
    > think of this: For each message I will create an
    > ICryptoTransform(Encryptor) and a CryptoStream. For the first message the
    > ICryptoTransform will use the initial IV. After I am finished writing
    each
    > message to its respective CryptoStream I will call FlushFinalBlock. I
    will
    > save the last block of ciphertext to use as the IV for the next messages
    > ICryptoTransform. The reason I will do this is because it will save the
    > time and CPU resources that would otherwise be needed to call GenerateIV.
    > The only think that worries me about this is that there would be somewhat
    > predictable plaintext in the final block of each message (the padding). I
    > don't think this would assist in cryptanalysis, but perhaps it would.

    That's hard to say. Even though the padding is predictable, the XOR of all
    previous blocks makes this extremely difficult. For example, let's say your
    padding on two different messages was "03 03 03", they wouldn't necessarily
    transform into the same cipher text because presumably the preceding message
    data was different and combined with the XOR operation of CBC mode would
    mask those even further.

    -Rob Teixeira [MVP]

    > The other idea is to create one ICryptoTransform (Encryptor) and one
    > CryptoStream, whenever a message is completed I can simply write a
    > "blocksize length" of bytes I will call flush bytes. While wasting a
    whole
    > block of encryption resources is unfortunate, I will effectively ensure
    that
    > my entire encrypted message is sent without waiting for the next message
    to
    > be encrypted, this way I can gain some of the advantages of CFB or OFB
    mode
    > (pseudo stream mode) without needing to use CFB mode and I get the added
    > bonus that it will be more efficient than CFB mode as long as my messages
    > are more than "block size" in length.
    >
    > -Chris
    >

  • Next message: Chris: "Re: RijndaelManaged and Rijndael CryptoTransforms do not support CFB or OFB CrytoModes"

    Relevant Pages

    • Re: Encrypt a string to a string and vice versa
      ... fine (at least I don't get an exception anywhere, if the string is ... correctly encryption is left aside). ... where I'm just creating a MemoryStream by ... The problem is, as soon as I call ReadByte on the CryptoStream, I get the ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: DES and UUEncoded
      ... using DES encryption is easy. ... decryption. ... > Then you hook up a CryptoStream to that memory stream, ... > decrypted output will be avaliable in the memory stream. ...
      (microsoft.public.dotnet.security)
    • Re: Im having problems with cryptography and sockets, help
      ... > I made many changes to the original code after I posted, ... Then, after looking some example code for encryption, I tried the ... > FlushFinalBlock or close the cryptostream, ... so that things like ReadToEnd will complete. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Encrypt a string to a string and vice versa
      ... All I want to do is to encrypt a string into an encrypted ... The encryption libraries in .NET are ... Look at CryptoStream for some sample code. ... Convert the resulting binary data into a string again. ...
      (microsoft.public.dotnet.languages.csharp)