I was able to plug the memory leak in mcrypt, but I appreciate the
assistance. I will definately be using Crypto++ for my next encryption
project.
Jamaal
On Sunday, December 23, 2012 3:12:11 PM UTC-5, Mouse wrote:
>
> AES is not Rijndael. It's a shame if Wei collapsed the two into one. Since
> Rijndael supports any combination of key and block sizes from the set
> {128, 192, 256} (with algorithmic implications), the only correct solution
> in my opinion is to divorce the code bases for them and provide separate
> implementations.
> --
> Regards,
> Mouse
> On Dec 23, 2012 11:09 AM, "Jeffrey Walton" <[email protected]<javascript:>>
> wrote:
>
>>
>>
>> On Dec 23, 10:25 am, Jamaal Scarlett <[email protected]>
>> wrote:
>> > From looking at the header file for rijndael it looks like the
>> blocksize is
>> > still 16, maybe I'm missing it but I didn't see a function to set the
>> > blocksize. I'm going to keep digging and thank you Jeffrey and Mouse for
>> > your help, I really appreciatie it.
>> You are going to need to do something like this:
>>
>> struct Rijndael_Info32 : public FixedBlockSize<32>, public
>> VariableKeyLength<16, 16, 32, 8>
>> {
>> CRYPTOPP_DLL static const char * CRYPTOPP_API
>> StaticAlgorithmName() {return "Rijndael32";}
>> }
>>
>> class CRYPTOPP_DLL Rijndael32 : public Rijndael_Info32, public
>> BlockCipherDocumentation
>> {
>> ....
>> }
>>
>> I'm having trouble locating test vectors, though. Obviously, you
>> cannot trust the PHP implementation in this case since you want to
>> interoperate with it. You need an independent verification.
>>
>> Jeff
>>
>> > On Sunday, December 23, 2012 8:22:10 AM UTC-5, Jeffrey Walton wrote:
>> >
>> > > On Dec 23, 8:08 am, Mouse <[email protected]> wrote:
>> > > > Rijndael specification allows 32-byte block size (AES standard
>> doesn't),
>> > > > don't know about Rijndael Crypto++ implementation (since in general
>> this
>> > > > block size is supported by the library, see no reason why not).
>> > > Indeed (I had to go look at their original paper). From cs.ucsb.edu/
>> > > ~koc/cs178/docs/rijndael.pdf<
>> http://cs.ucsb.edu/~koc/cs178/docs/rijndael.pdf>:
>> > > "Rijndael is an iterated block cipher
>> > > with a variable block length and a variable key length. The block
>> > > length and the key length can be independently specified to 128, 192
>> > > or 256 bits."
>> >
>> > > > ...
>> > > > To the Original Poster: you can't do what you want with AES,
>> period. If
>> > > you
>> > > > can't reconfigure that server to use a standard algorithm - you're
>> stuck
>> > > > with Rijndael, which is supported by Crypto ++.
>> > > Jamaal might also be able to provide an appropriate Rijndael_Info
>> > > (http://www.cryptopp.com/docs/ref/rijndael_8h_source.html). I have
>> > > never attempted it, and don't know if it works (or would work). Wei
>> > > would probably be the best person to answer short of an implementation
>> > > trial.
>> >
>> > > Jeff
>> >
>> > > > > On Dec 22, 9:02 pm, Jamaal Scarlett <[email protected]>
>> > > wrote:
>> > > > > > I wrote a test program and the output for the mcrypt function
>> > > > > > : mcrypt_module_get_algo_block_size(MCRYPT_RIJNDAEL_256, NULL)
>> is
>> > > 32.
>> > > > > The
>> > > > > > key lengths from all three libraries is 32.
>> > > > > No. The key length is 32 byte in the case of AES-256. Its 24 bytes
>> > > > > with AES-192, and 16 bytes with AES-128. The block size is always
>> 16
>> > > > > bytes. csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
>> >
>> > > > > Rijndael may allow for a 32 byte block size. I don't know about
>> > > > > additional configurations because I don't use it in non-NIST
>> > > > > configurations.
>> >
>> > > > > mcrypt has a unique feedback size, if I recall correctly. It has
>> had
>> > > > > interop problems since the time I can remember.
>> > > > >http://www.google.com/#q=cryptopp+mcryptt+feedback+size.
>> >
>> > > > > Jeff
>> > > > > > On Saturday, December 22, 2012 8:47:15 PM UTC-5, Mouse wrote:
>> >
>> > > > > > > The simple answer for AES is you can't. AES allows three key
>> > > lengths
>> > > > > (128,
>> > > > > > > 192, 256 bits), but only one block size (128 bits). AES
>> prototype
>> > > > > Rijndael
>> > > > > > > allowed three block sizes as well.
>> >
>> > > > > > > Perhaps by Rijndael-256 they meant only the key length? In
>> that
>> > > case I
>> > > > > > > would check the encryption mode, padding, etc. match what that
>> > > server
>> > > > > is
>> > > > > > > set up with.
>> > > > > > > --
>> > > > > > > Regards,
>> > > > > > > Mouse
>> > > > > > > On Dec 22, 2012 8:30 PM, "Jamaal Scarlett" <
>> [email protected]
>> > > > > <javascript:>>
>> > > > > > > wrote:
>> >
>> > > > > > >> I need to use AES, the server I am communicating with is
>> > > using
>> > > > > > >> mcrypt with the encryption mode set to RIJNDAEL_256. From
>> what I
>> > > have
>> > > > > > >> found online, this is a non-standard algorithm. I have tried
>> > > both
>> > > > > crypto++
>> > > > > > >> and OpenSSL's crypto library and while their encrypted
>> outputs
>> > > match,
>> > > > > I
>> > > > > > >> cannot get either to match the output from mcrypt. I would
>> use
>> > > > > mcrypt, but
>> > > > > > >> there is a memory leak in the init function of the version I
>> am
>> > > > > > >> using(2.5.7) and I am unable to find the lib(libmcrypt.lib)
>> file
>> > > for
>> > > > > any
>> > > > > > >> more recent version of the mcrypt library.
>> >
>> > > > > > >> Thanks for the help,
>> > > > > > >> Jamaal
>> >
>> > > > > > >> On Saturday, December 22, 2012 4:05:32 PM UTC-5, Jeffrey
>> Walton
>> > > wrote:
>> >
>> > > > > > >>> On Dec 22, 12:27 pm, Jamaal Scarlett <
>> [email protected]>
>> >
>> > > > > > >>> wrote:
>> > > > > > >>> > Thank you for the reply. Upon further reading, it looks
>> like
>> > > the
>> > > > > 256
>> > > > > > >>> in
>> > > > > > >>> > mcrypts RIJNDAEL_256 refers to the block cipher size.
>> Does
>> > > > > cryptopp
>> > > > > > >>> aes
>> > > > > > >>> > support a 32-bit block cipher size?
>> > > > > > >>> No, AES is a 16 byte block size. SHACAL2 has a larger block
>> size
>> > > if
>> > > > > > >>> you need it.
>> >
>> > > > > > >>> I believe Zooko (correct me here) needed a cipher with a
>> larger
>> > > block
>> > > > > > >>> size and used SHACAL2 for Tahoe-LFS (
>> > >http://en.wikipedia.org/wiki/
>> > > > > > >>> Tahoe-LAFS <http://en.wikipedia.org/wiki/Tahoe-LAFS>).
>> >
>> > > > > > >>> Jeff
>> >
>> > > > > > >>> > On Saturday, December 22, 2012 4:11:58 AM UTC-5, Jeffrey
>> > > Walton
>> > > > > wrote:
>> >
>> > > > > > >>> > > On Dec 22, 2:21 am, Jamaal Scarlett <
>> > > [email protected]>
>> > > > > > >>> wrote:
>> > > > > > >>> > > > Is it possible to change key lengths. On the wiki it
>> > > states
>> > > > > that
>> > > > > > >>> > > 16,24&32 byte keys are supported in aes but I cannot
>> find
>> > > any
>> > > > > > >>> documentation
>> > > > > > >>> > > on changing itbftomvthe default of 16. I am attempting
>> to
>> > > > > > >>> encrypt/decrypt
>> > > > > > >>> > > data to communicate with a server using mcrypt rijndael
>> 256,
>> > > > > > >>> however there
>> > > > > > >>> > > is a memory leak in the version of mcrypt we are using.
>> Is
>> > > 256
>> > > > > bit
>> > > > > > >>> > > supported?
>> >
>> > > > > > >>> > > Yes. All relevant objects take a key and key size. See,
>> for
>> > > > > example,
>> > > > > > >>> > >http://www.cryptopp.com/wiki/**CBC_mode<
>> > > > >http://www.cryptopp.com/wiki/CBC_mode>.
>>
>> --
>> You received this message because you are subscribed to the "Crypto++
>> Users" Google Group.
>> To unsubscribe, send an email to
>> [email protected]<javascript:>
>> .
>> More information about Crypto++ and this group is available at
>> http://www.cryptopp.com.
>>
>
--
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.
