Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green
From: Maaartin on 20 Feb 2010 14:25
On Feb 19, 5:20 pm, Thomas Pornin <por...(a)bolet.org> wrote:
> According to Maaartin  <grajc...(a)seznam.cz>:
>
> > byte[] and int[] at the same time, which is easy (although not
> > portable) in C using pointer casts.
>
> Actually it is not that easy, because it creates aliasing issues, which
> means that the code is prone to break when newer compiler versions
> decide to implement more aggressive optimization. These issues can be
> avoided but not easily.

I forgot. But would nou using unions solve it? This is what unions are
for, isn't it?

> As for the decoding of bytes into 32-bit values, I find it to be a
> minor part of the performance cost in a typical Java implementation
> of hash functions. I have measured, see sphlib.

Actually, there're hardly any bytewise operations in the hashes I
know, I was thinking about AES, what I failed to mention.

> > Wouldn't using something like Poly1305 in Java be a good idea? I've
> > seen no implementation, but I'm quite sure it could be done without
> > much effort.
>
> There may be usability issues. Poly1305 requires a 128-bit nonce. Proper
> encryption (whether CTR or CBC mode) also requires a nonce (usually
> called "IV"). As far as I know, using the same nonce for both usages
> could be a problem. So that you have to attach two 128-bit nonces to the
> encrypted message, instead of one for GCM or AES/CTR+HMAC. Depending on
> the situation, the extra nonce may or may not be a problem.

I'd say, using the same nonce is insecure, but attaching two nonces is
unnecessary. What about using a counter just like in
http://en.wikipedia.org/wiki/File:GCM.png, i.e., using X for
authentication and X+1, X+2, ... for the CTR mode (For the next
message X+N+1 should be used where N is the number of blocks)?

> Also, GCM appears to be able to do its complete job with a single AES
> key for both encryption and MAC. Poly1305 requires its own 32-byte key,
> so you must have three times the key material. Expanding a 128-bit key
> into 384 bits worth of key material can be done with a PRF (a hash
> function with a 384-bit output would do the trick) but that's additional
> code.

AFAIK, GCM does a sort of key expansion as well, it computes H =
encrypt_K(0), which can be (after clearing some bits) done for
Poly1305, too, or can't it? My knowledge is quite limited.

I believe to have read that using the same key for Poly1305 and for
encryption is fine as long as all the plaintext blocks are guaranteed
to be distinct, which can be achieved easily.

> For code compactness, simplicity and verifiability (GCM has a
> standard which precisely tells where each bit goes, and that's a very
> valuable asset), GCM seems best. Conceptually, GCM is the offspring of
> both CTR mode and Poly1305-style MAC, with all the pesky details ironed
> out, so it seems best to use it rather than its moral ancestors.

Sure. The good news for the OP is that he can use
org.bouncycastle.crypto.modes.GCMBlockCipher (although the speed
doesn't seem to be optimal at first sight).
From: Kristian Gj�steen on 20 Feb 2010 15:40
Thomas Pornin <pornin(a)bolet.org> wrote:
>Poly1305 requires a 128-bit nonce. Proper
>encryption (whether CTR or CBC mode) also requires a nonce (usually
>called "IV"). As far as I know, using the same nonce for both usages
>could be a problem.

I don't that would be a problem. I suspect it would be possible to
prove this, if necessary.

But GCM is probably better, though.

--
Kristian Gj�steen
From: Paul Rubin on 22 Feb 2010 21:07
"Kevin W. Wall" <kevin.w.wall(a)gmail.com> writes:
> around before committing to that. As usual, lots to do and not enough
> volunteers to do it. So if you'd like to help, we certainly could use the
> assistance.

Are you even still reading this thread? I'm not enough of a Java
programmer to be of much use reviewing the implementation, but I looked
at the API docs a little bit and could make some further comments.
From: Kevin W. Wall on 22 Feb 2010 23:32
On Feb 22, 9:07 pm, Paul Rubin <no.em...(a)nospam.invalid> wrote:
> "Kevin W. Wall" <kevin.w.w...(a)gmail.com> writes:
>
> > around before committing to that.  As usual, lots to do and not enough
> > volunteers to do it. So if you'd like to help, we certainly could use the
> > assistance.
>
> Are you even still reading this thread?  I'm not enough of a Java
> programmer to be of much use reviewing the implementation, but I looked
> at the API docs a little bit and could make some further comments.

;-) Yes, I am. And actually if you can read C++, you will find
yourself
reading Java in only a couple of days. That and the fact that our
ESAPI
javadoc links to the standard Javadoc would have you going in no time.

Of course, if you're only used to C code, ... well, learning will take
a great
deal longer. (Although Java is an easy transition from C# too.)

Also, I just counted up the lines of code. Here are the results.
(Apologies in advance if this comes out looking mangled. I'm
posting it through Google's interface, not through a real USENET news
reader. Think they could at least use a constant width font. Sigh...)

Total lines (w/ comments and blank lines):
Classes in package org.owasp.esapi.crypto: 2194 LOC
Classes in package org.owasp.esapi.reference.crypto: 1075 LOC
ByteConversionUtil in package org.owasp.esapi.util: 127 LOC
Encryptor interface: 432 LOC
EncryptedProperties interface: 107 LOC
===========
Total: 3935 LOC

Non-Commentary Source Lines (NCSL)
Classes in package org.owasp.esapi.crypto: 1073 NCSL
Classes in package org.owasp.esapi.reference.crypto: 560 NCSL
ByteConversionUtil in package org.owasp.esapi.util: 55 NCSL
Encryptor interface: 24 NCSL
EncryptedProperties interface: 13 NCSL
===========
Total: 1725 NCSL


Conclusion:
43% is non-commentary source lines!
57% are either comments or blank lines!!!

Hope the fact that there is less than total of 2K NCSL will encourage
reviewers.

Thanks,
-kevin
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green