Hi Dillon, > I'll look around for "Wei's Instructions" on how to build the library > because so far it has not been a pleasant experience. You might also want to look at http://www.codeproject.com/KB/tips/CryptoPPIntegration.aspx.
> I got to a stage where I need it to be more secure, so I'm taking > the opportunity here to expand my horizons into cryptography. > ...I want to add a final encryption phase to this nightly build. Confidentiality (encryption) alone is an incomplete solution. You must also ensure the data has not been altered. In the case of communications, TCP/IP provides mechanisms to detect transmission errors. However, they have no cryptographic properties. So if an attacker (which controls the network) decides to modify your encrypted data, TCP/IP will most likely not detect it. Standard practice is Encrypt then Authenticate. One of the early works is "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)" by Hugo Krawczyk. NIST (based on IEEE Wireless LAN group) recommends CCM. Crypto++ does not incorporate CCM at this point (Wei: hint, hint). However, if you look at default.h, you will find DefaultEncryptorWithMAC and DefaultDecryptorWithMAC. The composition does suffer from cryptographic defects. But if you were willing to use encryption alone, you will find this construction orders of magnitude stronger. But again, it is still lacking and there are better alternatives. Wei shows us how to use DefaultEncryptorWithMAC in test.cpp by way of EncryptFile( ) and EncryptString( ). DefaultEncryptorWithMAC uses the following typedefs, which you will probably want to change to AES and a SHA-2 hash. If you favor European standards, Camellia and Whirlpool might be your choices. typedef DES_EDE2 Default_BlockCipher; typedef SHA DefaultHashModule; typedef HMAC<DefaultHashModule> DefaultMAC; > (*) Please correct me if I'm wrong here: I believe I will need to > embed the private key into client.exe... Key exchange and key management is another can of worms. Jeff On 2/1/09, Avi <[email protected]> wrote: > > Hi Dillon, > > For the sake of clarity, I started programming 15 years ago. It's > cryptography that I'm new to. Same as American Football – didn't get > to it yet :) > > Anyways, yes – I rebuilt everything according to compiler version and > flavor. > I even name my libs this way (for example: > cryptopp552.debug.msvc60.lib) so I know exactly what I'm linking up > against. > > Regarding my client, it's just a small util I developed in my own free > time. The audience loves it and I enjoy maintaining it. I got to a > stage where I need it to be more secure, so I'm taking the opportunity > here to expand my horizons into cryptography. > > So, it goes like this: I have an offline tool that builds a database > on a nightly basis (the size is around 1Mb). I want to add a final > encryption phase to this nightly build. > I have an .exe client (let's call it client.exe) that checks for > updates and downloads the database from our intranet upon need. > > Currently I have the full database, more of less, sitting as clear > text on the client machine's harddisk. > I want to change my strategy, place just a minimal subset of the > database on the harddisk for working offline (e.g. laptops), and if > client.exe detects that it is connected to the intranet, I plan to > download the full database file into memory (without saving it). > > (*) Please correct me if I'm wrong here: I believe I will need to > embed the private key into client.exe as well as the decryption > function. > > Just to be clear, both versions of the databases will be encrypted in > the same manner so it doesn't matter which version I load, it will be > decrypted the same way. > > Practically, I wish to tighten up the security of the database(s) and > make sure that no readable version of the file will exist. > > (*) Once decrypted, the database will be stored in memory as clear > text data… > > > Dillon, thanks for your time and effort – I really appreciate it. > > I'll look around for "Wei's Instructions" on how to build the library > because so far it has not been a pleasant experience. > > Good luck with the Super Bowl! > > 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. -~----------~----~----~----~------~----~------~--~---
