java – Android上的AES解密太慢而无法使用. NDK会更快吗?其他想法?

前端之家收集整理的这篇文章主要介绍了java – Android上的AES解密太慢而无法使用. NDK会更快吗?其他想法?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我使用内置的Cipher类在 Android上实现了AES / CTR.对于我的目的来说,解密似乎太慢了,128KB的块在仿真器上解密大约需要6秒,而在三星Galaxy硬件上需要2.6秒.

我想知道是否使用NDK构建OpenSSL并调用方法会更快.有人对这个有经验么?部分我想要相信Cipher(“AES / CTR / NoPadding”)方法只是本机OpenSSL调用的包装器,因为支持Android的Linux操作系统应该安装了libcrypto.如果是这种情况,那么尝试使用NDK只会浪费时间,因为不会出现性能提升.

我没有费心在iOS上计算时间,但即便是3Gs硬件解密得如此之快,以至于10MB解密似乎对最终用户来说是即时的.我发现很难相信Android的实现确实更糟糕,但也许这就是现实.

如果这真的是我面临的问题,是否有人对其他实施策略有任何想法,这些策略会为最终用户提供难以察觉的响应(在10Mb文件上)?我办公室的另一位开发人员用一种诙谐的方式建议我只使用XOR加密,这让我想要自己面对,但我认为(除了安全问题)如果我这样做,它会起作用.

谢谢!

这里有一些简化的参考代码

public class ResourceDecryptor {
    private static ThreadLocal<Cipher>      mCipher;
    private byte[]                          mIV = new byte[ 8 ];
    private SecretKeySpec                   mKey;
    private String                          mResourcePath;

    private static final int                kAESBlockSize = 16;

    public ResourceDecryptor( String resourcePath,String decryptionKey ) throws UnsupportedOperationException {
        // initialization of mKey,mIV,& mResourcePath,elided 

        // store mCipher as a thread local because Cipher.getInstance() is so slow,// ResourceDecryptor is a static object that persists for the app lifetime
        // so this leak is intentional and ok.
        mCipher = new ThreadLocal<Cipher>() {
            protected Cipher initialValue() {
                try { return Cipher.getInstance( "AES/CTR/NoPadding" ); } catch ( Exception e ) { }

                return null;
            }
        };
    }

    public ByteBuffer read( long offset,int length ) throws GeneralSecurityException,IOException {
        Cipher                      cipher;
        byte[]                      data,iv;
        FileInputStream             input;
        int                         prefix,readLength;

        input = null;
        prefix = (int)( offset % kAESBlockSize );
        readLength = ( prefix + length + kAESBlockSize - 1 ) / kAESBlockSize * kAESBlockSize;
        data = new byte[ readLength ];
        iv = new byte[ 16 ];

        try {
            input = new FileInputStream( mResourcePath );
            input.skip( offset -= prefix );

            if ( input.read( data ) != readLength ) throw new IOException( "I/O error: unable to read " + readLength + " bytes from offset " + offset );

            System.arraycopy( mIV,iv,8 );

            offset /= kAESBlockSize;

            iv[  8 ] = (byte)( offset >> 56 & 0xff );
            iv[  9 ] = (byte)( offset >> 48 & 0xff );
            iv[ 10 ] = (byte)( offset >> 40 & 0xff );
            iv[ 11 ] = (byte)( offset >> 32 & 0xff );
            iv[ 12 ] = (byte)( offset >> 24 & 0xff );
            iv[ 13 ] = (byte)( offset >> 16 & 0xff );
            iv[ 14 ] = (byte)( offset >>  8 & 0xff );
            iv[ 15 ] = (byte)( offset       & 0xff );

            if ( ( cipher = mCipher.get() ) == null ) throw new GeneralSecurityException( "Unable to initialize Cipher( \"AES/CTR/NoPadding\" )" );
            cipher.init( Cipher.DECRYPT_MODE,mKey,new IvParameterSpec( iv ) );

            long startTime = System.currentTimeMillis();
            data = cipher.doFinal( data );
            System.out.println( "decryption of " + data.length + " bytes took " + ( ( System.currentTimeMillis() - startTime ) / 1000.0 ) + "s" );

            // cipher.doFinal() takes 5.9s on Samsung Galaxy emulator for 128kb block
            // cipher.doFinal() takes 2.6s on Samsung Galaxy hardware for 128kb block
        } finally {
            if ( input != null ) try { input.close(); } catch ( Exception e ) { }
        }

        // the default order of ByteBuffer is BIG_ENDIAN so it is unnecessary to explicitly set the order()

        return ByteBuffer.wrap( data,prefix,length );
    }
}

解决方法

是的,像所包含的功能那样的繁重提升正是NDK会发光的地方.请记住,Java是被解释的,并且在2.2之前的Android上,没有JIT,所以每次都会解释每条指令 – 这是一个巨大的开销.

即使使用JIT,每个数组访问都会进行隐式边界检查,因此会产生大量的开销.

如果用C语言编写这个函数,它会明显加快.

原文链接:https://www.f2er.com/android/128757.html

猜你在找的Android相关文章