Github user omalley commented on a diff in the pull request: https://github.com/apache/orc/pull/278#discussion_r202470866 --- Diff: java/core/src/java/org/apache/orc/impl/InStream.java --- @@ -173,33 +203,208 @@ private static ByteBuffer allocateBuffer(int size, boolean isDirect) { } } + /** + * Manage the state of the decryption, including the ability to seek. + */ + static class EncryptionState { + private final String name; + private final EncryptionAlgorithm algorithm; + private final Key key; + private final byte[] iv; + private final Cipher cipher; + private ByteBuffer decrypted; + + EncryptionState(String name, StreamOptions options) { + this.name = name; + algorithm = options.algorithm; + key = options.key; + iv = options.iv; + cipher = algorithm.createCipher(); + } + + /** + * We are seeking to a new range, so update the cipher to change the IV + * to match. This code assumes that we only support encryption in CTR mode. + * @param offset where we are seeking to in the stream + */ + void changeIv(long offset) { + int blockSize = cipher.getBlockSize(); + long encryptionBlocks = offset / blockSize; --- End diff -- No, we always start decryption on a block boundary and throw away the leading bytes. See InStream.EncryptionState.changeIv(long offset) and the "extra" and "wasted" variables.
---