Hi Avi, (Sorry about addressing Dillon last time. My mistake.)
> Hi there Mr. Walton, Just jeff. No pretension here. > So I don't know if 'default' has a special meaning in cryptography. > To me, 'default' means something that is X today but may be Y > tomorrow. Definitely a moving target. Triple DES is a 64 bit cipher which offers little security today. Hence the reason for AES or Camellia (128 bit ciphers). NIST recommends AES, the ISO has adopted Camellia. AES gets a lot of attention. But Camellia is well regarded. See http://www.ntt.co.jp/news/news05e/0505/050526.html. SHA and SHA1 are 128 and 160 bit hash functions. NIST recommends the SHA-2 family of hashes for new application. SHA-2 is mandatory in 2010 and after. SHA-2 include SHA-256, SHA-384, and SHA-512. I don't know what NESSIE or the ISO recommends, but I would expect that a 256 bit version of Whirlpool is in the offering. > Thus, so far I avoided using anything that has a 'default' in it. DefaultEncryptorWithMAC is a convenient construction with limitations. If you prefer, you can name it AesEncryptionWithMac (after changing the typedefs). You must perform both message encryption and message authentication. Encrypt then Authenticate applies to both secure communications and on-disk file encrpytion. The point is that encryption alone is not a solution,* AesEncryptionWithMac has limitations, and CCM is probably what you require. I have a Crypto++ implementation of CCM, but it does not do the library justice. So I keep it to myself and hope that Wei provides one in the future. The nice thing about Crypto++ is modularity. Once Wei provides CCM, you will be able to plug in AES in the United States, and Camellia in Europe (presuming you have faith in CCM). > My up-to-date knowledge in cryptography relies upon your introduction > article on CodeProject Keep in mind these are gentle introductions. So if you look at the Block Cipher article, it only provides information on the ciphers and how to use them with Crypto++. It does not offer the whole picture. This is similar to the way C++ sample code is presented without parameter validation and exception handling. > I really appreciate the hard work you all put into Crypto++. Thanks. I try to help others so that they do not waste time with my past mistakes. Jeff * Section 9.6 of Handbook of Applied Cryptography states we can use E_k(m || hm)) for Confidentiality and Integrity. I used it for years and later found that it suffered cryptographic defects also. On 2/1/09, Avi <[email protected]> wrote: > > Hi there Mr. Walton, > > > You might also want to look at > > http://www.codeproject.com/KB/tips/CryptoPPIntegration.aspx. > > I was going over it while receiving your message :) > I now realize that I should work with the .dsw / .sln files, and leave > the various .dsp / .vcproj files alone. > > > Key exchange and key management is another can of worms. > I agree, and I would love to perform this secure handshake, but alas, > I don't think I'll have permissions to execute code (e.g. COM object) > on the web server in my company. > That's why Hugo and Dillon's idea is so appealing to me. > > > Wei shows us how to use DefaultEncryptorWithMAC in test.cpp by way of > > EncryptFile( ) and EncryptString( ). > My up-to-date knowledge in cryptography relies upon your introduction > article on CodeProject (I SHOULD go over your articles in more depth). > So I don't know if 'default' has a special meaning in cryptography. > To me, 'default' means something that is X today but may be Y > tomorrow. > Thus, so far I avoided using anything that has a 'default' in it. > > On a general note, I really appreciate the hard work you all put into > Crypto++. > > Thank you, > > Avi. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
