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

Reply via email to