changing key lengths

[Jamaal Scarlett]

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?

Thanks Jamaal

[Jeffrey Walton]

On Dec 22, 2:21 am, Jamaal Scarlett <jamaal.scarl...@gmail.com> 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.

Jeff

[Jamaal Scarlett]

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?

Thanks,

Jamaal

[Jeffrey Walton]

On Dec 22, 12:27 pm, Jamaal Scarlett <jamaal.scarl...@gmail.com>
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).

Jeff

[Jamaal Scarlett]

     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

[Mouse]

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

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.

[Jamaal Scarlett]

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.

Jamaal

[Jeffrey Walton]

On Dec 22, 9:02 pm, Jamaal Scarlett <jamaal.scarl...@gmail.com> 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" <jamaal....@gmail.com<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 <jamaal.scarl...@gmail.com>
> >>> 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 <jamaal.scarl...@gmail.com>
> >>> 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 cryptopp-user...@googlegroups.com<javascript:>
> >> .

[Mouse]

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).

If CFB mode is used, it is not recommended to use less than the full block feedback for cryptographic reasons.

I recall that PGP used to have a weird modification of CFB back when.

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 ++.
--
Regards,
Mouse

To unsubscribe, send an email to cryptopp-user...@googlegroups.com.

[Jeffrey Walton]

On Dec 23, 8:08 am, Mouse <mouse...@gmail.com> 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: "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

[Jamaal Scarlett]

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.

Thanks,

Jamaal

[Jeffrey Walton]

On Dec 23, 10:25 am, Jamaal Scarlett <jamaal.scarl...@gmail.com>
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 <mouse...@gmail.com> 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>:

[Mouse]

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

[Jamaal Scarlett]

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

[Jeffrey Walton]

On Dec 23, 4:02 pm, Jamaal Scarlett <jamaal.scarl...@gmail.com> wrote:
> 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.

If you are [will be?] interop'ing with scripting languages, take a
moment to read: http://www.cryptopp.com/wiki/HexEncoder.

It has a topic on converting parameters (such as keys and
initialization vectors) to binary.

Jeff

[Jeffrey Walton]

On Dec 23, 11:09 am, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Dec 23, 10:25 am, Jamaal Scarlett <jamaal.scarl...@gmail.com>
> 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.
>

> ...
>
> 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.

So, there appears to be two sets of vectors available for Rijndael.

First is Dr. Gladman's vectors located at
http://gladman.plushost.co.uk/oldsite/cryptography_technology/rijndael/.
It appears to have the full compliment of Key Size x Block Size (think
Cartesian product). I should have known to check his site (thanks to
richiefr...@gmail.com on sci.crypt).

Second is NESSIE vectors (some found with a little Google-fu after
hitting the vein). Unfortunately, all are named 'unverified'. For
example, Rijndael-128-128.unverified.test-vectors.

https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/rijndael/Rijndael-128-128.unverified.test-vectors
https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/rijndael/Rijndael-192-128.unverified.test-vectors
https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/rijndael/Rijndael-256-128.unverified.test-vectors

https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/rijndael/Rijndael-256-128.unverified.test-vectors
https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/rijndael/Rijndael-256-192.unverified.test-vectors
https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/rijndael/Rijndael-256-256.unverified.test-vectors

Jeff

[Jamaal Scarlett]

Thanks, Jeff.

[Christopher Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Sun, 23 Dec 2012 15:12:11 -0500
Mouse <mous...@gmail.com> 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

How does it make any sense to write completely separate code for the
two? IMO, the ideal situation is to implement only Rijndael, and then
point out in the documentation (or possibly through template
instantiations) that if you want AES you just use Rijndael and set the
block size to 128.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEAREDAAYFAlDXrDQACgkQXUF6hOTGP7etZwCePrvhv9vGw8PcFab2TAs/mdD1
1MoAn1fGflfIJjMEeivY8bDF1ByNdEy4
=5CSs
-----END PGP SIGNATURE-----

[Mouse]

After checking the docs for Crypto++ I regret to report that this library (currently) does NOT support Rijndael, but only AES - using two names for the same algorithm (AES).

Disappointing...
--
Regards,
Mouse

[Mouse]

It doesn't have to be "completely separate code", but clearly AES must not allow any block size besides 16 bytes (must not offer this option), and Rijndael must support three block sizes selectable at the time of use.

I will keep to myself what I think about the suggestion to "point out in the documentation" in general, and especially when cryptographic issues are involved.

Template instantiation could be a good solution.
--
Regards,
Mouse

[Jamaal Scarlett]

I agree, the two names for the same algorithm is confusing.  Especially when the specifications for both are different re. block size.