我已经使用内置的 Cipher 类在 Android 上实现了 AES/CTR。就我的目的而言，解密似乎太慢了，一个 128KB 的 block 在模拟器上解密大约需要 6 秒，在 Samsung Galaxy 硬件上需要 2.6 秒。

我想知道使用 NDK 构建 OpenSSL 并调用其方法是否会更快。有人对这个有经验么？我的一部分想要相信 Cipher( "AES/CTR/NoPadding") 方法只是 native OpenSSL 调用的包装器，因为支持 Android 的 Linux 操作系统应该安装了 libcrypto。如果是这种情况，那么尝试使用 NDK 只会浪费时间，因为预期不会提高性能。

我没有费心在 iOS 上计时，但即使是 3G 硬件解密也非常快，以至于 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, 0, iv, 0, 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++ 编写此函数，速度会明显加快。

关于java - Android 上的 AES 解密太慢而无法使用。 NDK会更快吗？其他想法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6257945/