(feature) Android.mk to build CryptoPP using android NDK

[Alex Afanasyev]

For my android project, I'm using CryptoPP library that is build using NDK (with CrystaX NDK https://www.crystax.net/, as google-provided NDK has a few issues).

I think it would be useful to incorporate a simple Android.mk file into the main repository.  Please see the pull request on github (https://github.com/weidai11/cryptopp/pull/3) for more details.

---

Alex

[YoungJin Shin]

For Android platform, I think that it would be useful to merge following code into main repository.


#if defined(__ANDROID__)
# include <sys/select.h>
#endif

- http://www.cryptopp.com/wiki/Android_(Command_Line)

Thanks,
YoungJin

[Jeffrey Walton]

That has already been added. See https://github.com/weidai11/cryptopp/commit/54d72d091e68b4845c058a763463ed6193de2561 and https://sourceforge.net/p/cryptopp/code/543/.

[Jeffrey Walton]

On Sunday, June 28, 2015 at 9:58:15 PM UTC-4, Alex Afanasyev wrote:

For my android project, I'm using CryptoPP library that is build using NDK (with CrystaX NDK https://www.crystax.net/, as google-provided NDK has a few issues).

I think it would be useful to incorporate a simple Android.mk file into the main repository.  Please see the pull request on github (https://github.com/weidai11/cryptopp/pull/3) for more details.

Alex, I'm not a Git expert, so I'm not sure about merge requests. Can you provide a diff or email the Android.mk and Application.mk?

The Android.mk should build a static version of the library, a shared object version of the library, and cryptest.exe. We need both versions of the library to ensure users have a choice. We need cryptest.exe to push to a device and ensure the library built correctly. For me, I'll know it works if I can use ndk-build from the command line and it works and creates those three artifacts. (This has been on my TODO list for some time).

I'm also interested in getting a hold of a CmakeList.txt if you are proficient in Cmake.

[Mobile Mouse]

Considering that cmake builds are quite difficult to adjust beyond the narrow range the script writer prepared for - I strongly oppose moving crypto++ to cmake.

Sent from my iPad

--
--
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.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Walton]

On Mon, Jun 29, 2015 at 7:05 AM, Mobile Mouse wrote:
> Considering that cmake builds are quite difficult to adjust beyond the
> narrow range the script writer prepared for - I strongly oppose moving
> crypto++ to cmake.

Oh, my bad. I would not recommend a move to it.

But I think it would be good to offer users a choice. Those who like Make can continue to use it. Those who like Cmake can use it (its Its just one text file, as I understand it).

Jeff

[Alex Afanasyev]

On Sunday, June 28, 2015 at 8:35:44 PM UTC-7, Jeffrey Walton wrote:

On Sunday, June 28, 2015 at 9:58:15 PM UTC-4, Alex Afanasyev wrote:

For my android project, I'm using CryptoPP library that is build using NDK (with CrystaX NDK https://www.crystax.net/, as google-provided NDK has a few issues).

I think it would be useful to incorporate a simple Android.mk file into the main repository.  Please see the pull request on github (https://github.com/weidai11/cryptopp/pull/3) for more details.

Alex, I'm not a Git expert, so I'm not sure about merge requests. Can you provide a diff or email the Android.mk and Application.mk?

In theory, merging pull request could be as simple as clicking button in github UI, though I usually don't do it this way.

Here is a link to an updated patch https://github.com/cawka/cryptopp-1/commit/a462cf825b5859e30306bcb16e5301cd735f06c4.patch, which includes Android.mk, Application.mk for building stand-alone library and test suite, as well as two other .mk files (cryptopp-shared.mk and cryptopp-static.mk) for integration of the library in other project (if application includes Android.mk, it may unnecessarily build both library versions).

 

The Android.mk should build a static version of the library, a shared object version of the library, and cryptest.exe. We need both versions of the library to ensure users have a choice. We need cryptest.exe to push to a device and ensure the library built correctly. For me, I'll know it works if I can use ndk-build from the command line and it works and creates those three artifacts. (This has been on my TODO list for some time).

I'm also interested in getting a hold of a CmakeList.txt if you are proficient in Cmake.

Unfortunately, I haven't worked with cmake a lot.

---

Alex 

[Mobile Mouse]

> On Jun 29, 2015, at 7:27 , Jeffrey Walton <nolo...@gmail.com> wrote:
> On Mon, Jun 29, 2015 at 7:05 AM, Mobile Mouse wrote:
> > Considering that cmake builds are quite difficult to adjust beyond the
> > narrow range the script writer prepared for - I strongly oppose moving
> > crypto++ to cmake.
>
> Oh, my bad. I would not recommend a move to it.

Good! :-)

> But I think it would be good to offer users a choice. Those who like Make can continue to use it. Those who like Cmake can use it (its Its just one text file, as I understand it).

I believe that normally a person should have enough rope to hang himself, if that’s his choice. But adding Cmake capability is likely to negatively affect the rest of the distro. Also, do you find so much free time on your hands that you need to fill it with taking upon yourself maintenance of Cmake part of crypto++?

I oppose adding Cmake support. I have it in one of my projects at work, and it’s nothing short of nightmare.

[Jeffrey Walton]

>> But I think it would be good to offer users a choice. Those who like Make can continue to use it. Those who like Cmake can use it (its Its just one text file, as I understand it).
>
> I believe that normally a person should have enough rope to hang himself, if that’s his choice. But adding Cmake capability is likely to negatively affect the rest of the distro. Also, do you find so much free time on your hands that you need to fill it with taking upon yourself maintenance of Cmake part of crypto++?
>
> I oppose adding Cmake support. I have it in one of my projects at work, and it’s nothing short of nightmare.

OK, points taken.

How do you feel about providing it at the Patch page (http://www.cryptopp.com/wiki/Category:Patch)? This way, its available to those who want it, but it falls into the "provided, unknown quality, and maybe not maintained" category. (This assumes we will actually get our hands on a CmakeList.txt :).

Jeff

[Mobile Mouse]

On Jul 1, 2015, at 20:35 , Jeffrey Walton <nolo...@gmail.com> wrote:

> I oppose adding Cmake support. I have it in one of my projects at work, and it’s nothing short of nightmare.

OK, points taken.

How do you feel about providing it at the Patch page (http://www.cryptopp.com/wiki/Category:Patch)? This way, its available to those who want it, but it falls into the "provided, unknown quality, and maybe not maintained" category. (This assumes we will actually get our hands on a CmakeList.txt :).

My concern is that if it is there - a bonehead is bound to pop up that would create something useful and make it dependent on cmake.

Repeating myself - there are enough of useful things that are missing to inundate this project with something of adverse (IMHO) usefulness.

For example, how about adding support for Kalina block cipher? https://eprint.iacr.org/2015/650.pdf

[Jean-Pierre Münch]

Am 02.07.2015 um 23:21 schrieb Mobile Mouse:

On Jul 1, 2015, at 20:35 , Jeffrey Walton <nolo...@gmail.com> wrote:

> I oppose adding Cmake support. I have it in one of my projects at work, and it’s nothing short of nightmare.

OK, points taken.

How do you feel about providing it at the Patch page (http://www.cryptopp.com/wiki/Category:Patch)? This way, its available to those who want it, but it falls into the "provided, unknown quality, and maybe not maintained" category. (This assumes we will actually get our hands on a CmakeList.txt :).

My concern is that if it is there - a bonehead is bound to pop up that would create something useful and make it dependent on cmake.

Repeating myself - there are enough of useful things that are missing to inundate this project with something of adverse (IMHO) usefulness.

A short list ?:

• Skein
• BLAKE2
• bcrypt
• scrypt
• McBits (?)
• PHC-winner(s) (TBA)

For example, how about adding support for Kalina block cipher? https://eprint.iacr.org/2015/650.pdf

1. It think it's "Kalyna".
2. Who should implement this? I certainly couldn't. The problem with this cipher is that it is AES-like meaning we (may) have to fear cache-timing attacks, which have been mitigated for AES, but for Kalyna? I think we could implement, but maybe we shouldn't because chances are we're getting it wrong (only speaking for myself though).

BR

JPM

[Mobile Mouse]

1. My opinion - yes to BLAKE2 and Skein, not sure about McBits and PHC, abstain wrt. crypt and scrypt.

2. Yes, it is Kalyna (Ukrainian vs Russian pronunciation :). Timing attacks could probably be mitigated - the logic of doing so is reasonably well-known... Also, I personally find cache-timing attacks rather exaggerated, for symmetric ciphers at least. Now, AES has a distinct advantage here, because Intel put it in hardware - good luck timing cache :). Kalyna or any other software-based implementation wouldn't be so lucky, so more work for us, and worse performance...

Sent from my iPad

[Jean-Pierre Münch]

Am 03.07.2015 um 03:33 schrieb Mobile Mouse:

1. My opinion - yes to BLAKE2 and Skein, not sure about McBits and PHC, abstain wrt. crypt and scrypt.

Sorry forgot two (three) on my list:

• ChaCha (we already have salsa20, so shouldn't be too hard)
  
• Poly1305
• StreamCipher + Poly1305 (AEAD cipher, with stream cipher templatizable)

McBits isn't a must-have, although it looks a lot easier to implement than standard Niederreiter or McEliece.

I'd do Skein (+ Threefish as underlying construction), but it's inconvenient for me at the moment, I'll go through the my CryptoJPM files and propose a merge request on this list for the Skein+Threefish (Skein: full packet, hash, mac, KDF). ETA: September '15, (as soon as there's a Skylake R13)
I'll get Visual Studio 2015 around the same time and will see if I can fix the SSE related errors occurring with VS2012 (meaning I can provide scrypt + BLAKE2 family of MAC & hash).
I think it'll also be possible to me to dive into the Salsa20 code and adapt it for ChaCha.

I think as soon as PHC has winner(s) (Q3 '15?), we should implement them, because they'll be (far) better than (even) scrypt and bcrypt and our current only choice PBKDF2 (!).

2. Yes, it is Kalyna (Ukrainian vs Russian pronunciation :). Timing attacks could probably be mitigated - the logic of doing so is reasonably well-known... Also, I personally find cache-timing attacks rather exaggerated, for symmetric ciphers at least. Now, AES has a distinct advantage here, because Intel put it in hardware - good luck timing cache :). Kalyna or any other software-based implementation wouldn't be so lucky, so more work for us, and worse performance...

Again, I certainly won't implement it. If you can implement it securely I think we can include it as it's the libraries aim to provide as many algorithms as possible - in a high quality manner.

BR

JPM

[Mobile Mouse]

On Jul 3, 2015, at 6:08 , Jean-Pierre Münch <jean-pier...@web.de> wrote:

Am 03.07.2015 um 03:33 schrieb Mobile Mouse:

1. My opinion - yes to BLAKE2 and Skein, not sure about McBits and PHC, abstain wrt. crypt and scrypt.

Sorry forgot two (three) on my list:

• ChaCha (we already have salsa20, so shouldn't be too hard)
  
• Poly1305
• StreamCipher + Poly1305 (AEAD cipher, with stream cipher templatizable)

Oh yes, absolutely. All of the above would be welcome additions.

McBits isn't a must-have, although it looks a lot easier to implement than standard Niederreiter or McEliece.

Well, it would be nice to have something of that ilk… :)

I'd do Skein (+ Threefish as underlying construction), but it's inconvenient for me at the moment, I'll go through the my CryptoJPM files and propose a merge request on this list for the Skein+Threefish (Skein: full packet, hash, mac, KDF). ETA: September '15, (as soon as there's a Skylake R13)
I'll get Visual Studio 2015 around the same time and will see if I can fix the SSE related errors occurring with VS2012 (meaning I can provide scrypt + BLAKE2 family of MAC & hash).
I think it'll also be possible to me to dive into the Salsa20 code and adapt it for ChaCha.

Perfect! You’re the man! :)

I think as soon as PHC has winner(s) (Q3 '15?), we should implement them, because they'll be (far) better than (even) scrypt and bcrypt and our current only choice PBKDF2 (!).

:-) Let’s wait till the winner is picked, and see what it looks like?

2. Yes, it is Kalyna (Ukrainian vs Russian pronunciation :). Timing attacks could probably be mitigated - the logic of doing so is reasonably well-known... Also, I personally find cache-timing attacks rather exaggerated, for symmetric ciphers at least. Now, AES has a distinct advantage here, because Intel put it in hardware - good luck timing cache :). Kalyna or any other software-based implementation wouldn't be so lucky, so more work for us, and worse performance…

Again, I certainly won't implement it. If you can implement it securely I think we can include it as it's the libraries aim to provide as many algorithms as possible - in a high quality manner.

OK, when I have time I’ll look at both Kalyna and Grasshopper.