Questions about the AES Encryption object 137 written by Mark_T

Don M

I have been playing around trying to understand this object. http://obex.parallax.com/object/137

It seems fairly straight forward and I'm trying to verify the results shown on the terminal display with an online AES encrypt / decrypt.

I am using this website: http://aes.online-domain-tools.com/

Here is a couple examples that is shown on the terminal:

Monte Carlo 128 bits

COUNT = 0
KEY = 139a35422f1d61de3c91787fe0507afd
PLAINTEXT = b9145a768b7dc489a096b546f43b231f
CIPHERTEXT = d7c3ffac9031238650901e157364c386

COUNT = 1
KEY = c459caeebf2c42586c01666a9334b97b
PLAINTEXT = d7c3ffac9031238650901e157364c386
CIPHERTEXT = bc3637da2daf8fcf7c68bb28c143a0a4


I entered the above key and plaintext from count 0 into the online encrypt and I don't get the the same cipher result that is shown on the terminal. The Monte Carlo method that he set up in the demo uses ECB mode. I tried all the different combinations of plaintext and hex and I never get the same result as shown on the terminal.

What am I doing wrong or don't understand about this?


Thanks.
Don

LoopyByteloose

I wonder if some of the problem might lie in the Propeller expecting you to use ASCII.

If you are using 'cut and paste' to transfer data from your computer, you might be providing UTF-16 (in Windows) or UTF-8 in Linux.

The relationship is that UTF-16 and UTf-8 take more than one byte to represent a character. So results might vary. UTF-16 and UTF-8 are NOT the same.

Consider setting up a rigorous ASCII scheme or a rigorous UTF scheme for testing.

+++++++++++++
So, there is a secondary issue that encrypted text has to somehow anticipate which font format is expected.

Don M

What is odd is that in the demo he has another method called "VaryKey(bits)"

Here is a few of the responses that print on the terminal from that method:

COUNT = 80
KEY = ffffffffffffffffffff800000000000
PLAINTEXT = 00000000000000000000000000000000
CIPHERTEXT = 545d50ebd919e4a6949d96ad47e46a80

COUNT = 81
KEY = ffffffffffffffffffffc00000000000
PLAINTEXT = 00000000000000000000000000000000
CIPHERTEXT = dbdfb527060e0a71009c7bb0c68f1d44

COUNT = 82
KEY = ffffffffffffffffffffe00000000000
PLAINTEXT = 00000000000000000000000000000000
CIPHERTEXT = 9cfa1322ea33da2173a024f2ff0d896d

Now if you copy and paste the key and Plaintext into these online encryptors you do get the same Ciphertext result using the ECB method. So not sure that your explanation makes total sense.

Here are some more results from the method "VaryPlain(bits)".

COUNT = 105

KEY = 00000000000000000000000000000000

PLAINTEXT = ffffffffffffffffffffffffffc00000

CIPHERTEXT = 7678f3a833f19fea95f3c6029e2bc610



COUNT = 106

KEY = 00000000000000000000000000000000

PLAINTEXT = ffffffffffffffffffffffffffe00000

CIPHERTEXT = 3aa426831067d36b92be7c5f81c13c56



COUNT = 107

KEY = 00000000000000000000000000000000

PLAINTEXT = fffffffffffffffffffffffffff00000

CIPHERTEXT = 9272e2d2cdd11050998c845077a30ea0

And they also produce the same correct Ciphertext using copy and paste.

Mark_T

No idea about that site, the test vectors are those given by NIST:

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Test_vectors

Don M

Mark- I'm having a hard time understanding how to use this.

If I give you an example could you show me how to use it with your object?

Here's some data:

Key: 70629CC47F4614712456569D5200DA77
IV: 309A22336A8EA576F6A3BA9DD97FD20E
Plaintext: 322E30302C5230322C4330312C4D49443A464646464646464600000000000000

Method: CBC Encrypt

Also same key & plaintext using ECB Encrypt.

The key and IV were generated on my Mac using ssh.

Here's what I tried and I don't believe its correct because if I compare it to the same data input in this website I get different results: http://aes.online-domain-tools.com/

VAR
  byte buffer[180] 'buffer to assemble output strings
  long bpos

  long nn
  long ii
  long jj

  long plaintext [4*4]
  long ciphertext [4*4]
  byte thekey [16] '[32]
  long initvec [4]
  long check [4]
  long before
  long after


  repeat nn from 0 to 15
    thekey[nn] := byte[@ExKey][nn] 
  repeat nn from 0 to 7 '15
    plaintext[nn] := long[@ExPlain][nn] 

  repeat nn from 0 to 3
    initvec[nn] := long[@ExIV][nn] 

  aes.Start

  aes.SetKey (128, @thekey)
  
  debug.str(string("Key: "))
  repeat nn from 0 to 15
    debug.hex(byte[@TheKey][nn], 2)
  debug.tx(13)   


'  aes.CBCEncrypt (@ExPlain, @ciphertext, 4, @ExIV)
  aes.ECBEncrypt (@ExPlain, @ciphertext) 

  debug.str(string("IV: "))
  repeat nn from 0 to 3
    debug.hex(long[@InitVec][nn], 8)
  debug.tx(13)

  debug.str(string("Plain: "))
  repeat nn from 0 to 7 '15
    debug.hex(long[@PlainText][nn], 8)
  debug.tx(13)

  debug.str(string("Cipher: "))
  repeat nn from 0 to 15
    debug.hex(long[@CipherText][nn], 8)
  debug.tx(13)
  
DAT

ExKey         byte $70, $62, $9C, $C4, $7F, $46, $14, $71
              byte $24, $56, $56, $9D, $52, $00, $DA, $77

ExPlain       long $322e3030
              long $2c523032
              long $2c433031
              long $2c4d4944
              long $3a464646
              long $46464646
              long $46000000
              long $00000000
              long $00000000
              long $00000000
              long $00000000
              long $00000000
              long $00000000
              long $00000000
              long $00000000
              long $00000000               

ExIV          long $309A2233
              long $6A8EA576
              long $F6A3BA9D
              long $D97FD20E       

Very much appreciate any help here.

Thanks.
Don

Don M

Also why do you reverse the order of the longs when you print them out with the "prinarr" method?

This long $322e3030 in the DAT section becomes 30302e32 when printed out with your methods. Do they need to be entered that way into the encryption methods? I don't understand why this is done.

Appreciate any help with this.

Thanks again.
Don

Don M

Ok I think I may have figured out the ECB method. If I use your prinarr method to reverse the order of each long and then run the encryption now I get the same result as on line...

So a little more playing to do to fully understand it but any advice greatly appreciated.

ersmith

Don M wrote: »

Also why do you reverse the order of the longs when you print them out with the "prinarr" method?

This long $322e3030 in the DAT section becomes 30302e32 when printed out with your methods. Do they need to be entered that way into the encryption methods? I don't understand why this is done.

I think you'll find that the Propeller is a little endian machine, so:

   long $11223344

is stored in memory as $44, $33, $22, $11 (in that order).

Don M

Ok that gives me a clue as to what I think I need to do. Stay tuned...

Mark_T

Cryptography papers are excruciatingly careful to explain any order or endianness assumptions.
The common practice is to treat all values as byte vectors (array or octets) or sometimes
bit-vectors. Thus you would expect all test vectors to be in memory in byte ordering whatever
the processor.