views:

1424

answers:

5

I need to encrypt an ISO 8583 message... the problem here is that the message is longer than the key. I need some one help me how to encrypt this string.

For example: I have 300 chars in my string; should I encrypt each 16 chars alone then concat them, since my master key length is 16 bytes?

I appreciate your help...


ISO 8583-1:2003 Financial transaction card originated messages -- Interchange message specifications -- Part 1: Messages, data elements and code values.

+2  A: 

The key length does not impose a limit on the message size. The message can be as long as you want, and your 128-bit key (nonstandard for DES?) will still be good. The DES cipher operates on blocks of bytes, one block at a time. Standard DES uses a 56-bit key (plus 8 parity bits) and 64-bit blocks.

should I encrypt each 16 chars alone then concat them, since my master key length is 16 bytes?

Ciphers in general do not require the key and block sizes to be the same; they can define complicated operations taking a given block of cleartext and transforming it with the key to a block of ciphertext (usually of the same size). When multiple blocks need to be encrypted, a mode of operation is specified to describe how one block relates to the next block in the process.

When operating in the electronic codebook (ECB) mode, the message is divided into blocks, and each block of cleartext is encrypted separately with the same key (the resulting blocks of ciphertext are then concatenated). Like other modes of operation for DES (i.e. CBC, CFB, OFB), this approach has its pros and cons. You will need to pick the mode most suitable for your application.

Btw, you should also be aware that DES is now considered insecure.

Zach Scrivena
True, but not dreadfully helpful. The question is 'how to deal with messages longer than the block' - you said "it can be done" but not how it can be done.
Jonathan Leffler
@Jonathan: Noted. I've expanded my answer accordingly.
Zach Scrivena
+2  A: 

You need to look up encryption modes - which have names such as Cipher Block Chaining (CBC) and the 'do not use' mode Electronic Code Book (ECB), and even some exotic names like the Infinite Garble Extension (IGE). That page has a beautiful illustration of why the ECB mode should not be used.

CBC is a standard, solid mode of operation. OFB and CFB are also widely used.

You realize that the US Federal Government no longer uses plain DES because it is not secure enough (because it uses a 56-bit key and can be broken by brute force)? Triple-DES is just about tolerated - it has a 112-bit or 168-bit key, depending on which way you use it. The standard, though, is Advanced Encryption System, AES. Unless you have backwards compatibility reasons, you should use AES and not DES in new production code.

Also, you should know the answers to these questions before trying to write production code. I trust this is in the nature of homework or personal interest.

Jonathan Leffler
Actually, the 112-bit and 168-bit key sizes of 2TDES and 3TDES mean little due to the meet-in-the-middle attacks. 2TDES provides around 80 bits of security, and 3TDES provides only 112 bits of security.
Can Berk Güder
OK - thanks for the information. Both should be regarded as temporary band aids - somewhat better than DES but not good for new code.
Jonathan Leffler
It's "electronic code book," not "cook book." This refers to a code dictionary that maps between code words and plain text. Like: "bistro <=> submarine, bugle <=> destroyer".
erickson
@erickson - thanks, you're right of course. Fixed.
Jonathan Leffler
+5  A: 

DES is a block cipher, and block ciphers have different modes of operation.

The mode you mentioned is known as ECB (Electronic Codebook), and is not very secure (actually, neither is DES, but more on that later).

I'd suggest you use CBC or some other mode.

You can read about block cipher modes of operation here: Block cipher modes of operation

As for the cipher itself, I'd suggest you avoid using DES if this is at all possible. DES is extremely easy to crack nowadays. Please use AES, or at least 3DES if AES is not available.

EDIT: In response to the updated question, yes, you would need to pad the last block if the plaintext size is not a multiple of the block size.

Can Berk Güder
DES is extremely easy to crack? - That is overstating it a bit, unless you work for the NSA or built some DES cracking hardware. Clearly, it suffers from a short key, but it is much more secure than a locked filing cabinet and still useful. 3DES will keep out ALL prying eyes well into the future
Tall Jeff
Well, being a cryptographer, 56 bits *is* extremely easy. All you need to do is to buy/rent a COPACOBANA. Heck, even some CUDA GPUs would do the trick. That's what we consider "extremely easy."
Can Berk Güder
You can avoid padding if you use Cipher Text Stealing
jn_
@InSciTek Jeff: In cryptography, something is easy to crack if the cryptosystem has a flaw that allows it to crack it before brute force guessing the key, and brute force usually means the sun would die before you'd get the key. DES clearly fails in that criteria.
Calyth
+3  A: 

There are many different modes of operation for a block cipher. If you just need to applay ECB to your plain text, just split the plain text into equally sized blocks of size 8 bytes (DES block size) and encrypt each separately.
Depending on what you want to achieve, you could also use

  • ECB which encrypts block wise with each block being independent from all other (previous) blocks. Drawback: known plain text attacks can reveal patterns in your cipher text because the same plain text will always be encrypted to the same cipher text
  • CBC here you have an initialization vector and each blocks depends on all previously encrypted blocks. This is why you need an IV for the first block.
  • CFB this is an interesting one because it allows you to turn your block cipher into a stream cipher, which might be useful if you want to encrypt a video stream or whatever (similarly for OFB which basically generates a key stream)
  • CTS cipher text stealing might be of use if you want to encrypt data but want to avoid padding. A usage example might be to encrypt a blob in your database, which you cannot resize after it has been written to the DB.

There are still many more modes, but these are the most commonly used ones (imho).
As others have pointed out visit Wikipedia for all the details.

Update:
As for the padding, you have different possibilities. I'd recommend to use the ANSI X.923 standard which basically requires you to pad the last buffer with zeroes and append a counter in the last byte which gives you the number of valid bytes in the last block. The same idea is used in ISO10126 but this time padding is done with random bytes. Note that you can avoid padding at all when using CTS.

Maybe ask yourself if it's actually easier to use a crypto library to do the job for you.
If you're using C++ go for Crypto++ (not so straightforward, but consistent c++ style), Java and .NET have built in crypto providers. If you want to use plain C i can recommend libTomCrypt (very easy to use).

jn_
A: 

You might want to encrypt for the following reason:

  1. Transmit secured data that is the PIN Block (Data Element 52), this one is taken care of by the HSM, by the time you translate from the acquirer key to the issuer key.
  2. or to MAC the message, then you would select some fields to hash and append to the end of the message (usually Data Element 124 or 128)
  3. or you want to store the ISO 8583 message and want to comply with PCI DSS regulations, in this case you would encrypt the following data elements if present
    • DE 2 - Card Number
    • DE 14 - Expiry Date
    • DE 35 - Track II
    • DE 45 - Track I
    • DE 48 - EMV (Chip) Data (MasterCard TLV)
    • DE 52 - PIN Block
    • DE 55 - EMV (Chip) Data (Visa)

one more thing, your Master Key should be 128 bits to comply with Visa mandates (Triple DES Mandates to have LMK at least double length key that is 32 digits - 128 bits key)

A.Rashad