-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/03/14 19:30, Yuriy Kaminskiy wrote:
Note that all above variants may be NOT actually branchless and
thus NOT really constant-time (depending on architecture, jvm
implementation and options, etc). Most likely, resulting time
difference
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21/03/14 12:52, Michael Rogers wrote:
Thanks for the pointer. The Javadoc doesn't say whether this is a
constant-time comparison. In OpenJDK 6 it isn't. In OpenJDK 7 it
does something similar to my original suggestion. So unfortunately
it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Michael,
What you're trying to do is very similar to ECIES. You should probably
use ECIES, which has received more review than your design. It's
implemented in BouncyCastle, and there was recently a thread on the
BouncyCastle mailing list about
On 03/20/14 14:17, Michael Rogers wrote:
You should use a constant-time comparison here to avoid timing
attacks. Something like:
boolean matches = true;
for (i = 0; i 32; i++) {
matches = (digest[i] == decoded[i + 32]);
}
if (!matches) {
// incorrectly decoded: we're not the
Hi Michael.
Great points, and thanks for them.
If you look back a few revisions, you can see we had been using ECIES until
recently. The main motivation for switching was that it's not available in a
lot of other toolkits, there is incompatibility among toolkits that do
implement it, and
This seems as good a time as any to try to get some eyes on the encryption part
of Trsst. I've been soliciting feedback on this from the various crypto lists
as we're expanding our testing in the next day or so, but haven't yet gotten
any takers.
Background:
Trsst is a convention for using
Hi Michael. Some comments inline...
On Wed, Mar 19, 2014 at 9:01 AM, Michael Powers mich...@mpowers.net wrote:
For a private message, we generate a random 256-bit key and encrypt with
AES. Then for each recipient, we use a hash of the shared ECDH secret and
the message-id to encrypt the key
Thanks, Steve, for your quick response.
This is just the key exchange; not trying to sign or otherwise authenticate
here. The containing XML document is what gets signed via ECDSA as specified
by XML-SIG.
In this part, we're trying to distribute the same randomly-generated 256-bit
key to
