[OTR-dev] AES128 CTR?

[alex323]

Just for reference, here is the code i am using:

        public static byte[] Cipher(byte[] data, byte[] key, bool encrypt)
        {
            RijndaelManaged rm = new RijndaelManaged();
            rm.Mode = CipherMode.ECB;
            ICryptoTransform cipherer;

            if(encrypt)
            {
                cipherer = rm.CreateEncryptor(key,new byte[4] { 
0x00,0x00,0x00,0x01 });
            }
            else
            {
                cipherer = rm.CreateDecryptor(key,new byte[4] { 
0x00,0x00,0x00,0x01 });
            }

            MemoryStream ms = new MemoryStream();       
            CryptoStream cs = new CryptoStream(ms, cipherer, 
CryptoStreamMode.Write);

            cs.Write(data, 0, data.Length);
            cs.FlushFinalBlock();

            byte[] cipherTextBytes = ms.ToArray();
               
            ms.Close();
            cs.Close();

            return cipherTextBytes;
        }

...

byte[] data = new byte[20] 
{0xC5,0xD7,0x0F,0xB3,0x13,0x5C,0xB5,0x95,0xF2,0xF3,0x1E,0x01,0x88,0x88,0x4C,0xEF,0xBD,0xD7,0x3B,0xD9};
byte[] key = new byte[16] 
{0xC5,0xD7,0x0F,0xB3,0x13,0x5C,0xB5,0x95,0xF2,0xF3,0x1E,0x01,0x88,0x88,0x4C,0xEF};

byte[] enc = ctrmode.Cipher(data,key,true);
byte[] dec = ctrmode.Cipher(enc,key,false);

enc.Length == 32 bytes
dec.Length == 20 bytes

As you say in the protocol, the ctr will never change the length of the 
message. I assume this is what is happening here.

enc reads this:

6D 84 FA 45 8A B6 BB 6A
94 89 9D 53 2A 21 85 72
CA 08 E3 8B 83 B5 91 95
B1 CF 65 49 BE EA 82 30

and dec == data

Did I do this right? Thanks

Regards,
Alex

alex323 wrote:

> "This should monotonically increase (as a big-endian value) for
>      each message sent with the same (sender keyid, recipient keyid)
>      pair , and must not be all 0x00."
>
>
> So I am assuming that whenever the sender keyid and recipient keyid 
> are the same, i add one to the counter. For example:
>
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03
> ...
>
> "The initial counter is a 16-byte value whose first 8
>     bytes are the above "top half of counter init" value, and whose
>     last 8 bytes are all 0x00."
>
> And this should be:
>
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 
> 0x00, 0x00, 0x00, 0x00, 0x00
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 
> 0x00, 0x00, 0x00, 0x00, 0x00
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 
> 0x00, 0x00, 0x00, 0x00, 0x00
>
> Correct?
>
>
> Nikita Borisov wrote:
>
>>
>> On Jan 18, 2005, at 4:52 PM, alex323 wrote:
>>
>>> That also means I need to code my own AES implementation as well :(
>>
>>
>>
>> Probably not; you should be able to use the AES implementation in ECB 
>> mode to encrypt the counter value.
>>
>> - Nikita
>>
>> _______________________________________________
>> OTR-dev mailing list
>> OTR-dev at lists.cypherpunks.ca
>> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 825 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20050118/56160440/attachment.pgp>