[crypto] Last 16 bytes not being consumed?
I've posted this at SO as well where it has nicer formatting, but I'll
include the question here as well. See
http://stackoverflow.com/questions/42147559/java-cryptocipher-doesnt-consume-all-input-bytes
I'm trying to convert from using Chilkat's proprietary decryption library
to Apache's commons codec.
I have 2 example encrypted inputs I'm working with. The first is 16 bytes
and the second is 96 bytes. The first one works great, but on the second
one the CryptoCipher doesn't appear to be consuming the last 16 bytes.
Here's some example code of the setup and decryption and the output:
Properties properties = new Properties();
CryptoCipher crypt =
CryptoCipherFactory.getCryptoCipher("AES/CBC/PKCS5Padding", properties);
MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] hashedKeyBytes = digest.digest("SHARED_SECRET".getBytes(
StandardCharsets.UTF_8));
MessageDigest ivDigest = MessageDigest.getInstance("MD5");
byte[] ivBytes =
ivDigest.digest("SHARED_SECRET".getBytes(StandardCharsets.UTF_8));
final SecretKeySpec key = new SecretKeySpec(hashedKeyBytes, "AES");
IvParameterSpec iv = new IvParameterSpec(ivBytes);
crypt.init(Cipher.DECRYPT_MODE, key, iv);
ByteBuffer encBuffer = ByteBuffer.allocateDirect(enc.length);
System.out.println("--" + enc.length);
encBuffer.put(enc);
encBuffer.flip();
System.out.println("encln " + encBuffer.limit());
ByteBuffer decoded = ByteBuffer.allocateDirect(bufferSize);
CryptoCipher crypt = init();
System.out.println("consume " + crypt.update(encBuffer, decoded));
System.out.println("finish " + crypt.doFinal(encBuffer, decoded));
decoded.flip();
return asString(decoded);
This produces these 2 outputs for the 2 inputs:
Short input:
--16
encln 16
consume 0
finish 13
Long input:
--96
encln 96
consume 80
finish 3
As you can see it's only consuming 80 bytes out of the input... Since the
shorter input produces the correct output as compared to what Chilkat
produced, I'm not sure where to approach this to get it to work with the
longer input.
When I print out the string representation of the decrypted contents, there
are 33 characters missing from the end that should be there.
[ANNOUNCE] Apache Commons JCS 2.1 Released
The Apache Commons Team is pleased to announce the availability of: Apache Commons JCS 2.1 Apache Commons JCS is a distributed, versatile caching system. The release notes can be reviewed at: http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt Distribution packages can be downloaded from: https://commons.apache.org/proper/commons-jcs/download_jcs.cgi When downloading, please verify signatures using the KEYS file available at: http://www.apache.org/dist/commons More information and comprehensive documentation is available at: https://commons.apache.org/proper/commons-jcs/ Maven artifacts are also available in the central Maven repository: http://repo1.maven.org/maven2/org/apache/commons/ The Apache Commons Team - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[ANNOUNCE] Apache Commons Configuration 2.1.1 released!
The Apache Commons team is happy to announce the release of Commons Configuration 2.1.1! The Commons Configuration software library provides a generic configuration interface which enables a Java application to read configuration data from a variety of sources. Commons Configuration provides typed access to single, and multi-valued configuration parameters. Commons Configuration 2.1.1 ist a bugfix release with no API changes. It requires at least Java 1.6. Users of the 2.x line should upgrade to the new release. Users of the 1.x line should inspect the migration guide on the project’s website (http://commons.apache.org/proper/commons-configuration/userguide/upgradeto2_0.html) Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/proper/commons-configuration/download_text.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Alternatively the release can be pulled via Maven: org.apache.commons commons-configuration2 2.1.1 Full details of all the changes in 2.1.1 can be found in the changelog: http://commons.apache.org/proper/commons-configuration/changes-report.html The release notes can be reviewed at: http://www.apache.org/dist/commons/configuration/RELEASE-NOTES.txt For complete information on Commons Configuration, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Configuration website: http://commons.apache.org/proper/commons-configuration/ Have fun! Benedikt, on behalf of the Apache Commons Community - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [pool] preparePool that only registers key, doesn't create new object
On 06/02/17 10:55, Mark Thomas wrote: On 05/02/17 22:21, Gary Gregory wrote: Anyone care to opine? I think there is a bug in ensureMinIdle. If the objectDeque is null, it needs to obtain a reference to the objectDeque once created in the for loop. Otherwise the call from preparePool will always create minIdlePerKey objects regardless of any objects created by the evictor. Fixed in r1782329 for 2.4.3 onwards. Mark Mark G On Fri, Jan 20, 2017 at 7:38 AM, Martin Klepsch < martinklep...@googlemail.com> wrote: Hey, With a KeyedObjectPool I can use `setMinIdlePerKey` & `preparePool` to "bootstrap" an object pool. Now `preparePool` creates new objects synchronously and the evictor thread doesn't seem to ensure min idle objects if there are none yet (since it can't know the keys I guess). Because of that I run into the situation that the evictor thread creates objects for keys that are currently being created by `preparePool`. It's not an absolute deal breaker but it would be nice to be able to register keys without synchronously creating the minimum idle objects. Instead I'd like to wait for the evictor thread to pick up newly registered keys and create the required objects for it. Unfortunately `register` is private and I don't see another way to trigger key-registering. (Calling `preparePool` with `minIdlePerKey` set to 0 will short circuit and not register the key). Any suggestions welcome! Cheers :) - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
