You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Geoffrey Blake <ge...@gmail.com> on 2020/05/11 15:21:35 UTC
Re: [crypto] Help Releasing new Commons Crypto
All outstanding PR's have been merged to the repository, the code
coverage from coveralls looks good to me at over 80% coverage.
There are some areas that lack coverage, such as static main functions
in some classes, exception paths that guard against failures coming
from the crypto library, internal functions that are not used by the
current implementation, and checking for missing native libraries
again in places that are guarded from being hit higher up in the class
hierarchy. Are there good reasons to push for more coverage for
these cases? i.e. remove the dead code?
Otherwise, can we move forward with getting a new release? Marcelo
merged some build system fixes that should allow us to now collect
artifacts from the various platforms to one primary build machine for
Gary to do the final release.
-Geoff
On Tue, Apr 28, 2020 at 9:31 AM Geoffrey Blake
<ge...@gmail.com> wrote:
>
> I see now, you are correct Alex. My confusion is stemming partly from
> my lack of familiarity with Java (I touch Java code once every few
> years), and not having the API in my head. You can get to
> OpenSslJnaCipher in that way. It really should be included in
> CryptoCipherFactory.CipherProvider as the middle option in the
> fallback list. Currently that enum only exposes JNI and JCE if you
> don't explicitly override those with a properly set Properties
> structure.
>
> I feel the support for LibreSSL in commons-crypto is fine as is.
> Using CryptoCipherFactory.getCryptoCipher() will work and pass back
> the supported engine as expected, JNA support gets disabled as
> expected. I don't think JNA is critical.
>
> -Geoff
>
> On Mon, Apr 27, 2020 at 8:11 PM Alex Remily <al...@gmail.com> wrote:
> >
> > So I did a little homework and JNA appears to be a first class citizen
> > in Commons Crypto. One instantiates a JNA-backed CryptoCipher just as
> > one does JNI or JCE. The OpenSslJna class is exposed for that
> > purpose. I hacked together the below from some JNA test classes to
> > demonstrate and it runs successfully to completion as a stand alone
> > program.
> >
> > I think we're back to asking the question of whether or not to support
> > LibreSSL. I know that Commons Crypto fully supports OpenSSL on a Mac
> > because that is my primary development environment. I also understand
> > the convenience argument and I know it's a PITA to install OpenSSL
> > manually on a Mac, especially a new one. Nevertheless, this build is
> > already complex in large part because of the native interface, so
> > adding yet another native binary to the support list is going to
> > exacerbate the situation. Maybe we put it on the roadmap as a future
> > enhancement and see how many votes it gets.
> >
> > Thoughts?
> >
> > Alex
> >
> > public static void main(final String args[]) throws Exception {
> >
> > final String cipherClass = OpenSslJna.getCipherClass().getName();
> > Properties props = new Properties();
> > props.setProperty(CryptoCipherFactory.CLASSES_KEY, cipherClass);
> > String transformation = "AES/CBC/NoPadding";
> > final byte[] key = DatatypeConverter
> > .parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
> > final byte[] iv = DatatypeConverter
> > .parseHexBinary("000102030405060708090a0b0c0d0e0f");
> > final byte[] inputBytes = DatatypeConverter
> > .parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
> > final byte[] outputBytes = DatatypeConverter
> > .parseHexBinary("7649abac8119b246cee98e9b12e9197d");
> >
> > CryptoCipher enc = Utils.getCipherInstance(transformation, props);
> > enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
> > new IvParameterSpec(iv));
> >
> > CryptoCipher dec = Utils.getCipherInstance(transformation, props);
> > dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
> > new IvParameterSpec(iv));
> >
> > final int blockSize = enc.getBlockSize();
> > byte[] temp = new byte[inputBytes.length + blockSize];
> > final int n = enc.doFinal(inputBytes, 0, inputBytes.length, temp, 0);
> > final byte[] cipherText = new byte[n];
> > System.arraycopy(temp, 0, cipherText, 0, n);
> > Assert.assertArrayEquals("byte array encryption error.", outputBytes,
> > cipherText);
> >
> > temp = new byte[cipherText.length + blockSize];
> > final int m = dec.doFinal(cipherText, 0, cipherText.length, temp, 0);
> > final byte[] plainText = new byte[m];
> > System.arraycopy(temp, 0, plainText, 0, m);
> > Assert.assertArrayEquals("byte array decryption error.", inputBytes,
> > plainText);
> > }
> >
> >
> > On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
> > <ge...@gmail.com> wrote:
> > >
> > > JNA is the middle ground between JNI and JCE in terms of performance
> > > is my understanding without needing any .c files to create linkage.
> > > The problem appears to be that there is no conditional loading and
> > > stubbing of functions like can be done easily in the JNI code and is
> > > why macOS throws that error, LibreSSL lacks the rdrand() function.
> > > Perhaps it was included as a path to get rid of the native binaries
> > > that have to be built for JNI? But wonder if the performance wasn't
> > > there, or the macOS failures prevented its full development?
> > >
> > > -Geoff
> > >
> > > On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
> > > <ad...@googlemail.com.invalid> wrote:
> > > >
> > > > > I think Geoff just answered this question for us.
> > > >
> > > > Yup he was quicker with his reply than me! Thanks :-)
> > > >
> > > >
> > > > --
> > > > Adam Retter
> > > >
> > > > skype: adam.retter
> > > > tweet: adamretter
> > > > http://www.adamretter.org.uk
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
Posted by Geoffrey Blake <ge...@gmail.com>.
Figured you were busy, just wanted to keep this process alive. Let me
know if you need artifacts to be built, I can help there and can stash
them in S3 or somewhere.
-Geoff
On Fri, May 15, 2020 at 1:25 PM Gary Gregory <ga...@gmail.com> wrote:
>
> Work work work
> I'll see if I can take a look this weekend...
>
> Gary
>
> On Fri, May 15, 2020 at 10:19 AM Geoffrey Blake <ge...@gmail.com>
> wrote:
>
> > bump
> >
> > On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
> > <ge...@gmail.com> wrote:
> > >
> > > All outstanding PR's have been merged to the repository, the code
> > > coverage from coveralls looks good to me at over 80% coverage.
> > >
> > > There are some areas that lack coverage, such as static main functions
> > > in some classes, exception paths that guard against failures coming
> > > from the crypto library, internal functions that are not used by the
> > > current implementation, and checking for missing native libraries
> > > again in places that are guarded from being hit higher up in the class
> > > hierarchy. Are there good reasons to push for more coverage for
> > > these cases? i.e. remove the dead code?
> > >
> > > Otherwise, can we move forward with getting a new release? Marcelo
> > > merged some build system fixes that should allow us to now collect
> > > artifacts from the various platforms to one primary build machine for
> > > Gary to do the final release.
> > >
> > > -Geoff
> > >
> > > On Tue, Apr 28, 2020 at 9:31 AM Geoffrey Blake
> > > <ge...@gmail.com> wrote:
> > > >
> > > > I see now, you are correct Alex. My confusion is stemming partly from
> > > > my lack of familiarity with Java (I touch Java code once every few
> > > > years), and not having the API in my head. You can get to
> > > > OpenSslJnaCipher in that way. It really should be included in
> > > > CryptoCipherFactory.CipherProvider as the middle option in the
> > > > fallback list. Currently that enum only exposes JNI and JCE if you
> > > > don't explicitly override those with a properly set Properties
> > > > structure.
> > > >
> > > > I feel the support for LibreSSL in commons-crypto is fine as is.
> > > > Using CryptoCipherFactory.getCryptoCipher() will work and pass back
> > > > the supported engine as expected, JNA support gets disabled as
> > > > expected. I don't think JNA is critical.
> > > >
> > > > -Geoff
> > > >
> > > > On Mon, Apr 27, 2020 at 8:11 PM Alex Remily <al...@gmail.com>
> > wrote:
> > > > >
> > > > > So I did a little homework and JNA appears to be a first class
> > citizen
> > > > > in Commons Crypto. One instantiates a JNA-backed CryptoCipher just
> > as
> > > > > one does JNI or JCE. The OpenSslJna class is exposed for that
> > > > > purpose. I hacked together the below from some JNA test classes to
> > > > > demonstrate and it runs successfully to completion as a stand alone
> > > > > program.
> > > > >
> > > > > I think we're back to asking the question of whether or not to
> > support
> > > > > LibreSSL. I know that Commons Crypto fully supports OpenSSL on a Mac
> > > > > because that is my primary development environment. I also
> > understand
> > > > > the convenience argument and I know it's a PITA to install OpenSSL
> > > > > manually on a Mac, especially a new one. Nevertheless, this build is
> > > > > already complex in large part because of the native interface, so
> > > > > adding yet another native binary to the support list is going to
> > > > > exacerbate the situation. Maybe we put it on the roadmap as a future
> > > > > enhancement and see how many votes it gets.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Alex
> > > > >
> > > > > public static void main(final String args[]) throws Exception {
> > > > >
> > > > > final String cipherClass =
> > OpenSslJna.getCipherClass().getName();
> > > > > Properties props = new Properties();
> > > > > props.setProperty(CryptoCipherFactory.CLASSES_KEY,
> > cipherClass);
> > > > > String transformation = "AES/CBC/NoPadding";
> > > > > final byte[] key = DatatypeConverter
> > > > > .parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
> > > > > final byte[] iv = DatatypeConverter
> > > > > .parseHexBinary("000102030405060708090a0b0c0d0e0f");
> > > > > final byte[] inputBytes = DatatypeConverter
> > > > > .parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
> > > > > final byte[] outputBytes = DatatypeConverter
> > > > > .parseHexBinary("7649abac8119b246cee98e9b12e9197d");
> > > > >
> > > > > CryptoCipher enc = Utils.getCipherInstance(transformation,
> > props);
> > > > > enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > > > new IvParameterSpec(iv));
> > > > >
> > > > > CryptoCipher dec = Utils.getCipherInstance(transformation,
> > props);
> > > > > dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > > > new IvParameterSpec(iv));
> > > > >
> > > > > final int blockSize = enc.getBlockSize();
> > > > > byte[] temp = new byte[inputBytes.length + blockSize];
> > > > > final int n = enc.doFinal(inputBytes, 0, inputBytes.length,
> > temp, 0);
> > > > > final byte[] cipherText = new byte[n];
> > > > > System.arraycopy(temp, 0, cipherText, 0, n);
> > > > > Assert.assertArrayEquals("byte array encryption error.",
> > outputBytes,
> > > > > cipherText);
> > > > >
> > > > > temp = new byte[cipherText.length + blockSize];
> > > > > final int m = dec.doFinal(cipherText, 0, cipherText.length,
> > temp, 0);
> > > > > final byte[] plainText = new byte[m];
> > > > > System.arraycopy(temp, 0, plainText, 0, m);
> > > > > Assert.assertArrayEquals("byte array decryption error.",
> > inputBytes,
> > > > > plainText);
> > > > > }
> > > > >
> > > > >
> > > > > On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
> > > > > <ge...@gmail.com> wrote:
> > > > > >
> > > > > > JNA is the middle ground between JNI and JCE in terms of
> > performance
> > > > > > is my understanding without needing any .c files to create linkage.
> > > > > > The problem appears to be that there is no conditional loading and
> > > > > > stubbing of functions like can be done easily in the JNI code and
> > is
> > > > > > why macOS throws that error, LibreSSL lacks the rdrand() function.
> > > > > > Perhaps it was included as a path to get rid of the native binaries
> > > > > > that have to be built for JNI? But wonder if the performance
> > wasn't
> > > > > > there, or the macOS failures prevented its full development?
> > > > > >
> > > > > > -Geoff
> > > > > >
> > > > > > On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
> > > > > > <ad...@googlemail.com.invalid> wrote:
> > > > > > >
> > > > > > > > I think Geoff just answered this question for us.
> > > > > > >
> > > > > > > Yup he was quicker with his reply than me! Thanks :-)
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Adam Retter
> > > > > > >
> > > > > > > skype: adam.retter
> > > > > > > tweet: adamretter
> > > > > > > http://www.adamretter.org.uk
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
Posted by Gary Gregory <ga...@gmail.com>.
Work work work
I'll see if I can take a look this weekend...
Gary
On Fri, May 15, 2020 at 10:19 AM Geoffrey Blake <ge...@gmail.com>
wrote:
> bump
>
> On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
> <ge...@gmail.com> wrote:
> >
> > All outstanding PR's have been merged to the repository, the code
> > coverage from coveralls looks good to me at over 80% coverage.
> >
> > There are some areas that lack coverage, such as static main functions
> > in some classes, exception paths that guard against failures coming
> > from the crypto library, internal functions that are not used by the
> > current implementation, and checking for missing native libraries
> > again in places that are guarded from being hit higher up in the class
> > hierarchy. Are there good reasons to push for more coverage for
> > these cases? i.e. remove the dead code?
> >
> > Otherwise, can we move forward with getting a new release? Marcelo
> > merged some build system fixes that should allow us to now collect
> > artifacts from the various platforms to one primary build machine for
> > Gary to do the final release.
> >
> > -Geoff
> >
> > On Tue, Apr 28, 2020 at 9:31 AM Geoffrey Blake
> > <ge...@gmail.com> wrote:
> > >
> > > I see now, you are correct Alex. My confusion is stemming partly from
> > > my lack of familiarity with Java (I touch Java code once every few
> > > years), and not having the API in my head. You can get to
> > > OpenSslJnaCipher in that way. It really should be included in
> > > CryptoCipherFactory.CipherProvider as the middle option in the
> > > fallback list. Currently that enum only exposes JNI and JCE if you
> > > don't explicitly override those with a properly set Properties
> > > structure.
> > >
> > > I feel the support for LibreSSL in commons-crypto is fine as is.
> > > Using CryptoCipherFactory.getCryptoCipher() will work and pass back
> > > the supported engine as expected, JNA support gets disabled as
> > > expected. I don't think JNA is critical.
> > >
> > > -Geoff
> > >
> > > On Mon, Apr 27, 2020 at 8:11 PM Alex Remily <al...@gmail.com>
> wrote:
> > > >
> > > > So I did a little homework and JNA appears to be a first class
> citizen
> > > > in Commons Crypto. One instantiates a JNA-backed CryptoCipher just
> as
> > > > one does JNI or JCE. The OpenSslJna class is exposed for that
> > > > purpose. I hacked together the below from some JNA test classes to
> > > > demonstrate and it runs successfully to completion as a stand alone
> > > > program.
> > > >
> > > > I think we're back to asking the question of whether or not to
> support
> > > > LibreSSL. I know that Commons Crypto fully supports OpenSSL on a Mac
> > > > because that is my primary development environment. I also
> understand
> > > > the convenience argument and I know it's a PITA to install OpenSSL
> > > > manually on a Mac, especially a new one. Nevertheless, this build is
> > > > already complex in large part because of the native interface, so
> > > > adding yet another native binary to the support list is going to
> > > > exacerbate the situation. Maybe we put it on the roadmap as a future
> > > > enhancement and see how many votes it gets.
> > > >
> > > > Thoughts?
> > > >
> > > > Alex
> > > >
> > > > public static void main(final String args[]) throws Exception {
> > > >
> > > > final String cipherClass =
> OpenSslJna.getCipherClass().getName();
> > > > Properties props = new Properties();
> > > > props.setProperty(CryptoCipherFactory.CLASSES_KEY,
> cipherClass);
> > > > String transformation = "AES/CBC/NoPadding";
> > > > final byte[] key = DatatypeConverter
> > > > .parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
> > > > final byte[] iv = DatatypeConverter
> > > > .parseHexBinary("000102030405060708090a0b0c0d0e0f");
> > > > final byte[] inputBytes = DatatypeConverter
> > > > .parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
> > > > final byte[] outputBytes = DatatypeConverter
> > > > .parseHexBinary("7649abac8119b246cee98e9b12e9197d");
> > > >
> > > > CryptoCipher enc = Utils.getCipherInstance(transformation,
> props);
> > > > enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > > new IvParameterSpec(iv));
> > > >
> > > > CryptoCipher dec = Utils.getCipherInstance(transformation,
> props);
> > > > dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > > new IvParameterSpec(iv));
> > > >
> > > > final int blockSize = enc.getBlockSize();
> > > > byte[] temp = new byte[inputBytes.length + blockSize];
> > > > final int n = enc.doFinal(inputBytes, 0, inputBytes.length,
> temp, 0);
> > > > final byte[] cipherText = new byte[n];
> > > > System.arraycopy(temp, 0, cipherText, 0, n);
> > > > Assert.assertArrayEquals("byte array encryption error.",
> outputBytes,
> > > > cipherText);
> > > >
> > > > temp = new byte[cipherText.length + blockSize];
> > > > final int m = dec.doFinal(cipherText, 0, cipherText.length,
> temp, 0);
> > > > final byte[] plainText = new byte[m];
> > > > System.arraycopy(temp, 0, plainText, 0, m);
> > > > Assert.assertArrayEquals("byte array decryption error.",
> inputBytes,
> > > > plainText);
> > > > }
> > > >
> > > >
> > > > On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
> > > > <ge...@gmail.com> wrote:
> > > > >
> > > > > JNA is the middle ground between JNI and JCE in terms of
> performance
> > > > > is my understanding without needing any .c files to create linkage.
> > > > > The problem appears to be that there is no conditional loading and
> > > > > stubbing of functions like can be done easily in the JNI code and
> is
> > > > > why macOS throws that error, LibreSSL lacks the rdrand() function.
> > > > > Perhaps it was included as a path to get rid of the native binaries
> > > > > that have to be built for JNI? But wonder if the performance
> wasn't
> > > > > there, or the macOS failures prevented its full development?
> > > > >
> > > > > -Geoff
> > > > >
> > > > > On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
> > > > > <ad...@googlemail.com.invalid> wrote:
> > > > > >
> > > > > > > I think Geoff just answered this question for us.
> > > > > >
> > > > > > Yup he was quicker with his reply than me! Thanks :-)
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Adam Retter
> > > > > >
> > > > > > skype: adam.retter
> > > > > > tweet: adamretter
> > > > > > http://www.adamretter.org.uk
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [crypto] Help Releasing new Commons Crypto
Posted by Geoffrey Blake <ge...@gmail.com>.
bump
On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
<ge...@gmail.com> wrote:
>
> All outstanding PR's have been merged to the repository, the code
> coverage from coveralls looks good to me at over 80% coverage.
>
> There are some areas that lack coverage, such as static main functions
> in some classes, exception paths that guard against failures coming
> from the crypto library, internal functions that are not used by the
> current implementation, and checking for missing native libraries
> again in places that are guarded from being hit higher up in the class
> hierarchy. Are there good reasons to push for more coverage for
> these cases? i.e. remove the dead code?
>
> Otherwise, can we move forward with getting a new release? Marcelo
> merged some build system fixes that should allow us to now collect
> artifacts from the various platforms to one primary build machine for
> Gary to do the final release.
>
> -Geoff
>
> On Tue, Apr 28, 2020 at 9:31 AM Geoffrey Blake
> <ge...@gmail.com> wrote:
> >
> > I see now, you are correct Alex. My confusion is stemming partly from
> > my lack of familiarity with Java (I touch Java code once every few
> > years), and not having the API in my head. You can get to
> > OpenSslJnaCipher in that way. It really should be included in
> > CryptoCipherFactory.CipherProvider as the middle option in the
> > fallback list. Currently that enum only exposes JNI and JCE if you
> > don't explicitly override those with a properly set Properties
> > structure.
> >
> > I feel the support for LibreSSL in commons-crypto is fine as is.
> > Using CryptoCipherFactory.getCryptoCipher() will work and pass back
> > the supported engine as expected, JNA support gets disabled as
> > expected. I don't think JNA is critical.
> >
> > -Geoff
> >
> > On Mon, Apr 27, 2020 at 8:11 PM Alex Remily <al...@gmail.com> wrote:
> > >
> > > So I did a little homework and JNA appears to be a first class citizen
> > > in Commons Crypto. One instantiates a JNA-backed CryptoCipher just as
> > > one does JNI or JCE. The OpenSslJna class is exposed for that
> > > purpose. I hacked together the below from some JNA test classes to
> > > demonstrate and it runs successfully to completion as a stand alone
> > > program.
> > >
> > > I think we're back to asking the question of whether or not to support
> > > LibreSSL. I know that Commons Crypto fully supports OpenSSL on a Mac
> > > because that is my primary development environment. I also understand
> > > the convenience argument and I know it's a PITA to install OpenSSL
> > > manually on a Mac, especially a new one. Nevertheless, this build is
> > > already complex in large part because of the native interface, so
> > > adding yet another native binary to the support list is going to
> > > exacerbate the situation. Maybe we put it on the roadmap as a future
> > > enhancement and see how many votes it gets.
> > >
> > > Thoughts?
> > >
> > > Alex
> > >
> > > public static void main(final String args[]) throws Exception {
> > >
> > > final String cipherClass = OpenSslJna.getCipherClass().getName();
> > > Properties props = new Properties();
> > > props.setProperty(CryptoCipherFactory.CLASSES_KEY, cipherClass);
> > > String transformation = "AES/CBC/NoPadding";
> > > final byte[] key = DatatypeConverter
> > > .parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
> > > final byte[] iv = DatatypeConverter
> > > .parseHexBinary("000102030405060708090a0b0c0d0e0f");
> > > final byte[] inputBytes = DatatypeConverter
> > > .parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
> > > final byte[] outputBytes = DatatypeConverter
> > > .parseHexBinary("7649abac8119b246cee98e9b12e9197d");
> > >
> > > CryptoCipher enc = Utils.getCipherInstance(transformation, props);
> > > enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > new IvParameterSpec(iv));
> > >
> > > CryptoCipher dec = Utils.getCipherInstance(transformation, props);
> > > dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > new IvParameterSpec(iv));
> > >
> > > final int blockSize = enc.getBlockSize();
> > > byte[] temp = new byte[inputBytes.length + blockSize];
> > > final int n = enc.doFinal(inputBytes, 0, inputBytes.length, temp, 0);
> > > final byte[] cipherText = new byte[n];
> > > System.arraycopy(temp, 0, cipherText, 0, n);
> > > Assert.assertArrayEquals("byte array encryption error.", outputBytes,
> > > cipherText);
> > >
> > > temp = new byte[cipherText.length + blockSize];
> > > final int m = dec.doFinal(cipherText, 0, cipherText.length, temp, 0);
> > > final byte[] plainText = new byte[m];
> > > System.arraycopy(temp, 0, plainText, 0, m);
> > > Assert.assertArrayEquals("byte array decryption error.", inputBytes,
> > > plainText);
> > > }
> > >
> > >
> > > On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
> > > <ge...@gmail.com> wrote:
> > > >
> > > > JNA is the middle ground between JNI and JCE in terms of performance
> > > > is my understanding without needing any .c files to create linkage.
> > > > The problem appears to be that there is no conditional loading and
> > > > stubbing of functions like can be done easily in the JNI code and is
> > > > why macOS throws that error, LibreSSL lacks the rdrand() function.
> > > > Perhaps it was included as a path to get rid of the native binaries
> > > > that have to be built for JNI? But wonder if the performance wasn't
> > > > there, or the macOS failures prevented its full development?
> > > >
> > > > -Geoff
> > > >
> > > > On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
> > > > <ad...@googlemail.com.invalid> wrote:
> > > > >
> > > > > > I think Geoff just answered this question for us.
> > > > >
> > > > > Yup he was quicker with his reply than me! Thanks :-)
> > > > >
> > > > >
> > > > > --
> > > > > Adam Retter
> > > > >
> > > > > skype: adam.retter
> > > > > tweet: adamretter
> > > > > http://www.adamretter.org.uk
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org