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 <alex.rem...@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
> <geoffrey.w.bl...@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
> > <adam.ret...@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-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
