CryptoPP::ArraySource Stub Decryption
Dillon Beresford
CryptoPP::ArraySource as opposed to LoadFile. For my project I needed to be able to generate stubs on the fly which would handle all of the decryption. I'm also currently writing up some code that will actually add two extra layers of protection to both keys inside the executable to avoid reverse code engineering from dumping keys in memory We simply store our keys in the stub.
If we add stub + *.enc file to SFX we can have our stub do all the work for us. :)
I would suggest to anyone storing keys inside a binary to compress the executable using something other than UPX or ASPack. ;-) keys get gen all the time so it's best to use something with tons of instructions for anti-debugging, strip TLS, exports, and CRC protection and aPlib for compression.
Dillon's code reading from CryptoPP::ArraySource as opposed to CryptoPP::FileSource
void stubClass::LoadKey(const char *bufferPub, const char *bufferPri) {
CryptoPP::ArraySource(bufferPub, true,
new CryptoPP::StringSink(pubString));
CryptoPP::ArraySource(bufferPri, true,
new CryptoPP::StringSink(priString));
}
Hugo's class using CryptoPP::FileSource
/*
void stubClass::LoadKey(const char *pubFilename, const char *privFilename) {
CryptoPP::FileSource (pubFilename, true,
new CryptoPP::StringSink(pubString));
CryptoPP::FileSource (privFilename, true,
new CryptoPP::StringSink(priString));
}
*/
We can store our keys in bufferPub and bufferPri and call this from the main() in our stub.
const char bufferPri[]="308..."
const char bufferPub[]="308..."
int main() {
char EFile[]="dob.enc";
char DFile[]="dec.exe";
stubClass stubDecrypt;
// grab our keys from memory.
stubDecrypt.LoadKey(bufferPub,bufferPri);
// decrypt our file
stubDecrypt.AES_CTR_Decrypt(EFile, DFile);
return 0;
}
thanks Hugo!
linked back to the original thread where Hugo posted his class.
regards,
Dillon Beresford
Avi
I'm new around here and new to the cryptography world.
I'm using VC++ 6.0 SP5 on a WinXP SP2 machine (I have a legacy code
base that I'd like to secure).
I tried to follow your (and originally Hugo's) example, but I'm having
the same runtime error in both cases.
I'm posting my problem here instead of in Hugo's thread in order to
narrow the differences between our executables (since you embedded
your keys into the source code).
The code crashes in oaep.cpp, line 91: memcpy(output, M, maskedDB
+dbLen-M);
The 'output' value is 0 (NULL).
I attached the call stack below.
Any ideas?
Avi.
--
CryptoPP::OAEP_Base::Unpad(const unsigned char * 0x0032b7f1, unsigned
int 255, unsigned char * 0x00000000, const CryptoPP::NameValuePairs &
{...}) line 91 + 20 bytes
CryptoPP::TF_DecryptorBase::Decrypt(CryptoPP::RandomNumberGenerator &
{...}, const unsigned char * 0x0032bbd8, unsigned int 257, unsigned
char * 0x00000000, const CryptoPP::NameValuePairs & {...}) line 142 +
59 bytes
CryptoPP::PK_DefaultDecryptionFilter::Put2(const unsigned char *
0x00000000, unsigned int 0, int -1, unsigned char 1) line 626 + 75
bytes
CryptoPP::BufferedTransformation::MessageEnd(int -1, unsigned char 1)
line 763 + 78 bytes
CryptoPP::SimpleProxyFilter::LastPut(const unsigned char * 0x00000000,
const unsigned char * 0x00000000) line 513 + 51 bytes
CryptoPP::FilterWithBufferedInput::PutMaybeModifiable(unsigned char *
0x00326d68, unsigned int 0, int -2, unsigned char 1, unsigned char 0)
line 410
CryptoPP::FilterWithBufferedInput::Put2(const unsigned char *
0x00326d68, unsigned int 0, int -2, unsigned char 1) line 156
CryptoPP::Filter::Output(int 2, const unsigned char * 0x00326d68,
unsigned int 0, int -2, unsigned char 1, const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
{0x00000000 ""}) line 115 + 44 bytes
CryptoPP::BaseN_Decoder::Put2(const unsigned char * 0x00000000,
unsigned int 0, int -1, unsigned char 1) line 163 + 42 bytes
CryptoPP::BufferedTransformation::ChannelPut2(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
{0x00000000 ""}, const unsigned char * 0x00000000, unsigned int 0, int
-1, unsigned char 1) line 250 + 27 bytes
CryptoPP::BufferedTransformation::ChannelMessageEnd(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
{0x00000000 ""}, int -1, unsigned char 1) line 938 + 63 bytes
CryptoPP::BufferedTransformation::TransferMessagesTo2
(CryptoPP::BufferedTransformation & {...}, unsigned int & 0, const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
{0x00000000 ""}, unsigned char 1) line 407 + 28 bytes
CryptoPP::BufferedTransformation::TransferAllTo2
(CryptoPP::BufferedTransformation & {...}, const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
{0x00000000 ""}, unsigned char 1) line 448 + 24 bytes
CryptoPP::SourceTemplate<CryptoPP::StringStore>::PumpAll2(unsigned
char 1) line 718 + 73 bytes
CryptoPP::Source::PumpAll() line 689 + 47 bytes
CryptoPP::Source::SourceInitialize(unsigned char 1, const
CryptoPP::NameValuePairs & {...}) line 701
CryptoPP::StringSource::StringSource(const char * 0x0012fbd8, unsigned
char 1, CryptoPP::BufferedTransformation * 0x00326b10) line 737 + 173
bytes
stubClass::AES_CTR_Decrypt(const char * 0x0012ff48, const char *
0x0012ff30) line 128 + 364 bytes
main() line 92
--
On Jan 23, 4:34 am, Dillon Beresford <dillon.beresf...@gmail.com>
wrote:
>
> regards,
>
> Dillon Beresford
>
> stub.cpp
> 4KViewDownload
>
> stubClass.cpp
> 3KViewDownload
>
> stubClass.h
> < 1KViewDownload
Avi
and decrypt here just to make sure we're on the same page.
I've narrowed it down to not being able to decrypt the 512 bytes key
from the file.
Avi.
--
void stubClass::AES_CTR_Encrypt(const char *infile, const char
*outfile)
{
try
{
//Open outfile in binary and output
ofstream file( outfile, ios::binary );
BYTE keyAES[ CryptoPP::AES::MAX_KEYLENGTH ];
BYTE ivAES[ CryptoPP::AES::BLOCKSIZE ];
//Generate AES key and iv
CryptoPP::OS_GenerateRandomBlock(false, keyAES,
CryptoPP::AES::MAX_KEYLENGTH);
CryptoPP::OS_GenerateRandomBlock(false, ivAES,
CryptoPP::AES::BLOCKSIZE);
//Pass key to string
string AesKey((char*)keyAES, CryptoPP::AES::MAX_KEYLENGTH);
AesKey.append((char*)ivAES, CryptoPP::AES::BLOCKSIZE);
//Crypt string AesKey with RSA and save to file stream in HexFormat
CryptoPP::StringSource pubStr(pubString, true, new
CryptoPP::HexDecoder);
CryptoPP::RSAES_OAEP_SHA_Encryptor pub(pubStr);
CryptoPP::AutoSeededX917RNG <CryptoPP::DES_EDE3> rng;
CryptoPP::StringSource(AesKey, true,
new CryptoPP::PK_EncryptorFilter(rng, pub,
new CryptoPP::HexEncoder(new CryptoPP::FileSink(file))));
//Crypt file with AES-CBC and save to file stream
CryptoPP::AES::Encryption aesEncryption( keyAES,
CryptoPP::AES::MAX_KEYLENGTH);
CryptoPP::CBC_Mode_ExternalCipher::Encryption cbcEncryption
( aesEncryption,ivAES );
CryptoPP::FileSource(infile, true,
new CryptoPP::StreamTransformationFilter(cbcEncryption,
new CryptoPP::FileSink(file)));
//Close the stream
file.close();
}
catch(CryptoPP::Exception &e)
{
cout << "CryptoPP::Exception caught: " << e.what() << endl;
}
}
void stubClass::AES_CTR_Decrypt(const char *infile, const char
*outfile)
{
try
{
ifstream file( infile, ios::binary );
byte keyAES[ CryptoPP::AES::MAX_KEYLENGTH ];
byte ivAES[ CryptoPP::AES::BLOCKSIZE ];
char Key[512];
file.read(Key,512);
CryptoPP::StringSource privStr(priString, true,
new CryptoPP::HexDecoder);
CryptoPP::RSAES_OAEP_SHA_Decryptor priv(privStr);
CryptoPP::AutoSeededX917RNG<CryptoPP::DES_EDE3> rng;
string AesKeyUnCrypt;
CryptoPP::StringSource(Key, true,
new CryptoPP::HexDecoder(
new CryptoPP::PK_DecryptorFilter(rng, priv,
new CryptoPP::StringSink(AesKeyUnCrypt))));
memcpy(keyAES,AesKeyUnCrypt.data(),CryptoPP::AES::MAX_KEYLENGTH);
memcpy(ivAES,AesKeyUnCrypt.data()+
CryptoPP::AES::MAX_KEYLENGTH, CryptoPP::AES::BLOCKSIZE);
CryptoPP::AES::Decryption aesDecryption( keyAES,
CryptoPP::AES::MAX_KEYLENGTH);
CryptoPP::CBC_Mode_ExternalCipher::Decryption cbcDecryption
( aesDecryption, ivAES );
CryptoPP::FileSource(file, true,
new CryptoPP::StreamTransformationFilter(cbcDecryption,
new CryptoPP::FileSink(outfile)));
}
catch(CryptoPP::Exception &e)
{
std::cout << "CryptoPP::Exception caught: " << e.what() << endl;
}
}
--
Dillon Beresford
Hash: SHA1
output is NULL then you get the error. Are you planning on decrypting
from a stub or just need the decryption and encryption to read from
key files? If you take a look at the svn Hugo and I maintain for our
project you might get a better working example of how the Class is
implemented. You can download the project here and use dobclass.
http://code.google.com/p/komodopgmp/source/browse/trunk/windows/dev/dobrexor/dobclass.cpp
http://code.google.com/p/komodopgmp/source/browse/trunk/windows/dev/dobrexor/dobclass.h
Download the entire project if you like. It's the full implementation
of the class you want.
http://komodopgmp.googlecode.com/files/dobrexor-beta-build-win-current.zip
// file.read(Key,512); <--
Let me know how your LoadKeys is working. Are you planning on securing
this legacy code from one application or working with a self
decrypting archive?
Regards,
Dillon Beresford
Komodo PGMP project
http://code.google.com/p/komodopgmp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJhZRxRnxC5lZRuuERAlINAJ4hI7MhGmvGCspsxel5GlOoT6q0zQCfeQNy
NKh/cQvBrsw5cQiiezMNK/E=
=cL0O
-----END PGP SIGNATURE-----
Avi
Thanks for the swift reply.
Regarding my code, I have a small utility that downloads an updated
database with information that I would like to encrypt. The method I
want to use if that the .exe would know how to decrypt the file and
display its data.
I'm really a newbie rookie novice here and just starting to get used
to the idea of composing multiple transformations on top one another.
Hugo's example looks very appealing to me and your touch of embedding
the key into the executable seems like exactly what I need.
After spending many hours following your last post, I reached the same
dead end... memcpy crashes.
Here's the detailed explanation:
I d/l the full dobrexor project, and since it didn't have a .dsp/.dsw
files set, I went and installed VS2005.
Since it didn't also have a .sln file, I realized the hard way that
the .vcproj file is of VS2008.
Nevermind, I created a new Win32 Console App. under VS2005 and since
then, I spent many hours trying to make everything work...
I used the statis lib. version of cryptopp552, which does not really
work out-of-the-box are requires its own tweaks.
It took me a while to realize that dobrexor is set to wirk with
cryptopp's DLL version.
I changed it to work with the static lib version, but I got into more
trouble when trying to use work with dobrexor's menus.
Trying to encrypt a file, it crashed with a null filename.
After a short while I found that dobrexor contains the following
lines:
const char pub[1024]="";
const char pri[4096]="";
Evidently, these supposed to be the pub/priv file names.
Added my own filename (although I think that dobrexor should ask the
user to input the pub/priv filenames, at least if the filename strings
are empty).
Now it all works, up to the point where I crash on the very same
memcpy line as stated above..........
I'm guessing you have a very well tweaked development environment, but
can you please verify and let me know if a clean copy of both dobrexor
and cryptopp552 compiles out-of-the-box (e.g. a clean install on a
VMWare or something)?
Thanks,
Avi.
On Feb 1, 2:24 pm, Dillon Beresford <dillon.beresf...@gmail.com>
wrote:
> Download the entire project if you like. It's the full implementation
> of the class you want.
>
> // file.read(Key,512); <--
>
> Let me know how your LoadKeys is working. Are you planning on securing
> this legacy code from one application or working with a self
> decrypting archive?
>
> Regards,
>
> Dillon Beresford
> Version: GnuPG v1.4.7 (MingW32)
> iD8DBQFJhZRxRnxC5lZRuuERAlINAJ4hI7MhGmvGCspsxel5GlOoT6q0zQCfeQNy
> NKh/cQvBrsw5cQiiezMNK/E=
> =cL0O
> -----END PGP SIGNATURE-----
>
> 2KViewDownload
Dillon Beresford
2KViewDownload
>
Avi,
> Thanks for the swift reply.
> Regarding my code, I have a small utility that downloads an updated
> database with information that I would like to encrypt. The method
> I want to use if that the .exe would know how to decrypt the file
> and display its data.
Is this function for downloading the information also a part of the
program that encrypts and decrypts the data? Reason I ask is because
I want to know what your doing to clean up memory after download has
been completed, provided the download function is a part of this.
> I'm really a newbie rookie novice here and just starting to get
> used to the idea of composing multiple transformations on top one
> another. Hugo's example looks very appealing to me and your touch
> of embedding the key into the executable seems like exactly what I
> need.
> After spending many hours following your last post, I reached the
> same dead end... memcpy crashes.
> Here's the detailed explanation: I d/l the full dobrexor project,
> and since it didn't have a .dsp/.dsw files set, I went and
> installed VS2005.
> Since it didn't also have a .sln file, I realized the hard way that
> the .vcproj file is of VS2008.
I've got Visual Studio 6/2003/2005, I will create some projects and
send you the link to download the Visual Studio 6 project.
> Nevermind, I created a new Win32 Console App. under VS2005 and
> since then, I spent many hours trying to make everything work...
> I used the statis lib. version of cryptopp552, which does not
> really work out-of-the-box are requires its own tweaks.
I have to ask, did you link the cryptlib(d) debug with your debug
build and the cryptlib.lib with the release build?
> It took me a while to realize that dobrexor is set to wirk with
> cryptopp's DLL version.
is static.
There is nothing really special about the build configurations for
dobrexor.
However, Komodo PGMP is special due to the /CLR and Unicode which was why
I went with dll for Komodo.
> Trying to encrypt a file, it crashed with a null filename. After a
Yeah, it's still a work in progress and we need make some changes.
> Evidently, these supposed to be the pub/priv file names. Added my
> own filename (although I think that dobrexor should ask the user to
> input the pub/priv filenames, at least if the filename strings
std::cin
names for the keys.
> I'm guessing you have a very well tweaked development environment,
> but can you please verify and let me know if a clean copy of both
> dobrexor and cryptopp552 compiles out-of-the-box (e.g. a clean
> install on a VMWare or something)?
instance
the LINUX build was developed using the g++ and NetBeans IDE with C++
plugin.
The Win32 was compiled with VS 2008. Can you take a screen shot of
your debug
and release configuration in VS 2005 and send me a link to view the
Includes
and Library path. I would also like to see what's under General.
What is the size of the data your decrypting? And finally the keys are
both
the public and private keys stored inside the exe?
Check and double check those cryptlib builds. I know this sounds crazy
but
when I was implementing my wrapper/proxy for the unmanaged code I had to
go back several times and double check various switches to get my libs
just right!
If you are doing all of this from win32 console, Crypto++ libs worked
nicely
for me. Never had any issues but then again ah did you rebuild those libs
when you moved the code over to Visual Studio 2005? Don't forget to
rebuild
cryptlib and cryptlibd.
Look forward to your response. I think we can now this out tonight.
Dillon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
08+94yps66QbWxM1JQ2gWQc=
=dbQy
-----END PGP SIGNATURE-----
Avi
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.
Jeffrey Walton
> 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
Dillon Beresford
From: Dillon Beresford <dillon.b...@gmail.com>
Date: Sun, Feb 1, 2009 at 5:35 PM
Subject: Re: CryptoPP::ArraySource Stub Decryption
To: Avi <skydi...@gmail.com>
Avi,
I feel your pain with the library. It can be a cumbersome process
getting a configuration setup. I'm actually not looking forward to
writing build documents for my project. So the example you gave me is
perfect, I see exactaly what your trying to acomplish. One quick
question. Are you also embedding the public key as well? You said, you
embedded the private key. Is the public key stored in there as well?
Just checking, decryption will fail if the public key is not stored as
well.
>(*) 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.
const char privKey[] = "000......";
stubDecrypt.LoadKey(pubKey,priKey);
You are correct the private key needs to be stored, and the public key
(together). The way the class is designed it reads from two files. The
way my stub is designed it reads from two types. I know you already
understand storage I just want to make sure that you have included the
public key as well. All the very best and I will try to respond as
quickly as possible to help you resolve this issue.
Sounds like a fun little project and very useful too.
Regards,
Dillon Beresford
Avi
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 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( ).
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.
Avi
> Are you also embedding the public key as well?
encryption and decryption, but I use two different executables:
client.exe and another one for building the database (let's say
build_db.exe).
I plan to #define some macro that will be used to compile just
AES_CTR_Encrypt and embed the public key for build_db.exe and will
compile just AES_CTR_Decrypt and embed just the private key in
client.exe.
(*) I reinstalled crypto552 and built it properly via the .dsw file,
reinstalled dobrexor, linked to cryptopp and rebuilt and I still get
the same crash.
One thing I neglected to mention is that I got a dreadful compiler
error, namely:
--
Compiling...
dobclass.cpp
P:\CryptoPP\dobrexor\dobclass.cpp(102) : fatal error C1001: INTERNAL
COMPILER ERROR
(compiler file 'msc1.cpp', line 1794)
Please choose the Technical Support command on the Visual C+
+
Help menu, or open the Technical Support help file for more
information
Error executing cl.exe.
--
I guess it's a VC6 thing. This was my workaround:
--
CryptoPP::FileSink* fs = new CryptoPP::FileSink(pubFilename);
CryptoPP::StringSource(pubString, true, fs);
CryptoPP::StringSource(priString, true, new CryptoPP::FileSink
(privFilename));
--
Later I found out that this is the recommended solution.
I'll install VS2008 tomorrow (it's really late night right now) and
see if I get a better result.
> Sounds like a fun little project and very useful too.
challenge myself in various fields of programming.
Today it's my baby :)
Good night.
Avi.
Jeffrey Walton
(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 <skydi...@gmail.com> wrote:
>
> Hi there Mr. Walton,
>
> > You might also want to look at http://www.codeproject.com/KB/tips/CryptoPPIntegration.aspx.
Jeffrey Walton
> I plan to #define some macro that will be used to compile just
> AES_CTR_Encrypt and embed the public key for build_db.exe and will
> compile just AES_CTR_Decrypt and embed just the private key in
> client.exe.
AES is a symmetric cipher. There is no notion of public keys and
private keys in the algorithm. If you want to protect you symmetric
key (generated offline - not exchanged - and hard coded into the
executables, you might also look at RFC 3394: Advanced Encryption
Standard (AES) Key Wrap Algorithm.
> (*) I reinstalled crypto552 and built it properly via the .dsw file,
> reinstalled dobrexor, linked to cryptopp and rebuilt and I still get
> the same crash.
Does Crypto++ pass its validation test? I believe the command is "cryptest v".
> P:\CryptoPP\dobrexor\dobclass.cpp(102) : fatal error C1001: INTERNAL
> COMPILER ERROR
Haven't seen this show its head in quite some time. Last time was with
VC6.0. If you are using 6.0, have you applied Microsoft's processor
patch?
> CryptoPP::FileSink* fs = new CryptoPP::FileSink(pubFilename);
> CryptoPP::StringSource(pubString, true, fs);
> CryptoPP::StringSource(priString, true, new CryptoPP::FileSink
> (privFilename));
When you pass variable fs to StringSource, StringSource owns it an
will delete it (the behavior is noted in ReadMe.txt if I recall
correctly). Are you performing a double delete to cause the crash?
Jeff
On 2/1/09, Avi <skydi...@gmail.com> wrote:
>
Avi
well, combined with the fact realizing you have no idea what I'm
talking about, I ran dobrexor one more time, with RSA Key Len of 2048
instead of the 1024 I used the whole time... BINGO!
Once the code worked I went back to Hugo's post 'cause the number 2048
rang a bell and indeed that's the key length that appears in the
example (in not so many words, though).
To summarize - I guess I'm missing some fundamental RSA backgroud
(2048 works, 1024 and 4096 doesn't work).
But I have to say the dobrexor, at its current stage is a bit
misleading. If indeed RDA is related with 2048 key length only (I'll
have to check this one), then giving the user an option to choose 1024
or 4096 might send them on a 2 days wild goose chase with lots on
installation and compilation issues :)
Never mind, there's something to learn from everything.
Until next time..
Avi.
Avi
>
> Just jeff. No pretension here.
Just wanted to say that most of what you wrote is above me at this
point, so I'll take these keywords/buzzwords as pointers for further
reading.
Thanks,
Avi.
Avi
> ... you might also look at RFC 3394: Advanced Encryption
> Does Crypto++ pass its validation test? I believe the command is "cryptest v".
The main problem was the I used RSA-1024 keys.
I'm still not 100% sure why, but RSA-2048 keys solved my problem.
> > P:\CryptoPP\dobrexor\dobclass.cpp(102) : fatal error C1001: INTERNAL
> > COMPILER ERROR
>
> Haven't seen this show its head in quite some time. Last time was with
> VC6.0. If you are using 6.0, have you applied Microsoft's processor
> patch?
Got the above error so I installed VC6 SP6, thinking that it would
solve the problem.
It didn't. But since you asked so nicely, I tried to install the
Microsoft Processor Pack.
Since it will only install on top of VC6 SP5 I reverted back to that
configuration.
After installing the Microsoft Processor Pack I can safely say it
didn't help at all.
Changing the objects construction sequence did the trick.
Just to make sure that this is all related to VC6-only I build
cryptopp and the project for VS2005 and the bug doesn't reproduce (..
I guess I could have skipped this part and just believe that MS
changed something in the past 10 years, but - I'm ".. a good guy, ..
and thorough" ;)
> When you pass variable fs to StringSource, StringSource owns it an
> will delete it (the behavior is noted in ReadMe.txt if I recall
> correctly).
Have to say I enjoy reading the Crypto++ source code - it's been a
while since I last saw a good piece of software with actual thinking
behind it and (*my goodness!*) incorporated design patterns.
It has a very professional look and feel and it's classic C++ (ah, the
nostalgy)...
I love it! :)
Avi
> 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.
I see the rational behind this.
Sound like good practice that should be memorized (Encrypt, then
Authenticate.
Encrypt, then Authenticate. Encrypt, then Authenticate.)
See ya around.
Avi.
Avi
dobrexor) and embedded them instead of the keys in Dillon's original
post (at the beginning of this thread).
Works like a charm.
Nonetheless, Dillon posted a sample that works for him so there is
still a gray area that eludes me - how does it work for him but not
for me.
Anyways, in case you bumped into the same problem as I did, I hope
you'll benefit from my proposed solution.
I'd like to thank Dillon and Jeffrey once again - I learned a lot and
this has been one of the more educated threads I took part in.
Thanks,
Avi.