Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Looking for a Triple DES implementation



David Kramer <david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org> writes:

> Derek Atkins wrote:
>> Have you tried OpenSSL?
>
> Huh?  Please explain.

OpenSSL has both a cryptographic library API and a command-line.
E.g. perl's Crypt:SSLeay ..

>> Also, what MODE are you using?  CFB?  CBC?
>
> ECB

So you're only encrypting something less than 8 bytes long?

>> What are you doing about the Initialization Vector?
> You mean the key?  Yes, I know the phrase he's using as a key, and am
> using the same thing.

No, if I meant "the key" I would have said "the key."  I said
Initialization Vector and I MEAN the Initialization Vector.  Granted,
I said this before I found out you were using ECB (you ARE only
encrypting a single block of 8 bytes, right?) which doesn't use an IV.
But then you should NEVER EVER EVER use ECB for more than a single
blocksize, and you have the problem that encrypting the same block
with the same key always encrypts to the same output so you can make a
key dictionary.

>> There are lots of reasons that two encryptions of the same plaintext
>> wont result in the same ciphertext.  The question is whether the
>> ciphertext can be converted back to the correct plaintext.
>
> In this case, the question is can I generate the same exact output as
> him, because the program that reads it expects what his program is
> putting out.

That makes very little sense from a cryptographic standpoint unless
you're assuming the IV or you're using broken cryptography.
Unfortunately it sounds like the latter, not the former (although the
former is just as bad).

> I took a closer look at his program, and he's converting the output to
> Base64, which explains why his output is printable characters.  He
> didn't tell me that.  He's also treating the input as UTF8, but I don't
> know if that matters when the input is straigh old typewriter characters.

The base64 is okay.  The treating the input as utf8 may or may not
be a problem.  The treating the KEY as UTF8 is DEFINITELY a problem.
Using ECB here is also a major no-no.

> This is the guts of his C# program:
> public static string EncryptKey(string inputString, string encryptionKey)
>        {
>            //Used encrypt/decrypt examples from
> http://www.codeproject.com/useritems/Cryptography.asp
>
>            byte[] keyArray;
>            byte[] toEncryptArray = UTF8Encoding.UTF8.GetBytes(inputString);
>
>            keyArray = UTF8Encoding.UTF8.GetBytes(securityKey);
>
>            TripleDESCryptoServiceProvider tdes = new
> TripleDESCryptoServiceProvider();
>            tdes.Key = keyArray;
>            tdes.Mode = CipherMode.ECB;
>            tdes.Padding = PaddingMode.PKCS7;
>
>            ICryptoTransform cTransform = tdes.CreateEncryptor();
>            byte[] resultArray =
> cTransform.TransformFinalBlock(toEncryptArray, 0, toEncryptArray.Length);
>            tdes.Clear();
>            return Convert.ToBase64String(resultArray, 0,
> resultArray.Length);
>        }
>
> Thanks.

And this code proves to me that this guy should be fired on the spot,
or at least be removed from doing anything related to security.  It's
guys like this that write security snake-oil.

* throws up his hands in complete disgust *

Pardon me while I run to the toilet and wretch.  Honestly, do yourself
a favor and get these guys to hire a security person to write this
code for them.  They'll be much happier in the long run, even if it
costs them $1-5k now to get the work done.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord-DPNOqEs/LNQ at public.gmane.org                        PGP key available

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org