crypto class design

Luis Martin luis.mgarc at gmail.com
Wed Dec 19 02:22:09 EST 2007


> One thing that I'm wondering is how to indicate (e.g.) the overhead in
> terms of padding, or whatever, for various algorithms... or if it
> matters.  The old code had some really disturbing practices like
> assuming that the output buffer was 16 octets bigger, and stuff like
> that... scary.

I am not sure I understood what you want but here's my suggestion.


What about creating a new data type called crypto_card? It could be
defined like this:

typdef struct crypto_card{
  unsigned char initialization_vector[12];
  unsigned char card_no[20];
  unsigned char checksum[16];
} crypto_card;

Supposed you are using AES and you have a block size of 128. The idea is
to allocate a buffer for the card (as big as you need) and then use some
useful padding to make the data fit into 128-bit blocks. If you want
support for different block sizes make sure your data type size is a
multiple of 8, 16, and 32.

What I called initialization_vector is a random number. This way, the
card number will be encrypted to something different each time. This
prevents eavesdroppers to be able to identify that the same card is
being used in two transactions.

The checksum provides integrity checks so you don't actually perform
operations on wrong card numbers.

You could use ASCII chars to represent card numbers so if your card
number is shorter than twenty digits the NULL character could indicate
the end of the information.


Is this what you meant?



Luis.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list