Results 1 to 3 of 3

Thread: AES Demo

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012

    AES Demo

    Attached is a demo of AES encryption/decryption using CNG. The default uses a key size of 128, but there is provision for 192 and 256. The HMAC is SHA256, which is what is used in TLS 1.2.

    The PreMaster Secret or Key Exchange in this case was randomly generated as were the Server and Client Randoms. The ones currently being used were taken from an actual session shown here:


    The above page shows a packet capture for a TLS session using the mandatory TLS 1.2 cipher suite (002F - TLS_RSA_WITH_AES_128_CBC_SHA). The Pre-Master Secret could also have been the Agreed Secret generated by a Diffie-Hellman Ephemeral process. The Master Keys are generated from all 3 values, and differ depending on whether it is for the Server or the Client. The default is the Client process and produces:
    63 4C 69 C0 A4 1E 24 40 11 F8 CA 37 21 47 9A 92
    0A 8E 88 F1 1F 51 12 FA 80 05 9A 79 72 A1 32 18
    46 7A D4 B5
    DF 9D E1 74 68 60 55 19 26 02 00 00 66 00 28 00
    03 2C 9E EA 56 F4 C9 6F AC 12 01 47 82 BB FE F8
    63 62 57 B8 EE 53 F9 7F 37 4F 0A 24 B0 5E 86 04
    A3 FB A8 FA
    06 68 62 BE 20 46 10 12 AE 3B 36 F7 12 47 DA FD

    PRF1_2 is used to create the Master Secret from Pre-Master Secret, Client Random, & Server Random. The Client & Server Randoms are then switched, and PRF1_2 is again used to create the Master Hash from the Master Secret, Server Random, & Client Random. The various keys are then extracted from the Master Hash.

    That's the hard part. The easy part is the actual encryption and decryption. If you are wondering what the IV variable is used for, it stands for Initialization Vector, and is necessary for any Block Algorithm. Block Algorithms use a repeating Xor (exclusive or) routine of the Block Length to create the encrypted value, and that repetition makes it vulnerable to being hacked when a known value is being encrypted. The Initialization Vector resolves that issue. As well, that repetition can make the encrypted value longer than the original value, necessitating Block Padding.

    This demo uses the full Unicode characters, which for ASCII (English) doubles the length of the encrypted value. You can alternatively use every second byte, or the UTF8 value. The difficulty with UTF8 is that there is no enforced standard for detecting it in an encrypted value.

    J.A. Coutts
    Attached Images Attached Images  
    Attached Files Attached Files

  2. #2
    Frenzied Member wqweto's Avatar
    Join Date
    May 2011

    Re: AES Demo

    Another post of yours that shrouds crypto w/ mystery and this is a sad state of affairs and it shouldn't be like that.

    Unfortunately IMO this piece of code is poorly written, over-complicated, mostly inefficient and very cumbersome to use from client apps. Probably extracted from a larger effort, that was not very well decoupled to begin with -- the gory result is not pretty.

    To anyone seeking a general introduction to AES/crypto -- keep looking, find something better done.


  3. #3

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012

    Re: AES Demo


    You are correct in assuming that this demo originated from a larger more complex application that involved multiple cipher suites. It was put together as a tool to use in comparing the performance of my own encryption routine to a well established currently accepted cipher such as AES. It was not intended to be a free standing routine that could simply be added to an application. It was intended to be a demo to increase a developers understanding of how AES is used in TLS 1.2. TLS 1.0/1.1 and SSL are no longer accepted as being safe by the security community because of some of the ciphers that they support.

    J.A. Coutts

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts


Click Here to Expand Forum to Full Width