Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

2009-09-17 Thread Kevin W. Wall
Peter Gutmann wrote:
 David Wagner d...@cs.berkeley.edu writes:
 
 (You could replace AES-CMAC with SHA1-HMAC, but why would you want to?)
 
 The answer to that depends on whether you need to support an existing base of
 crypto software and hardware.  Even though (in this case) it's a new standard,
 it still requires support from the underlying crypto libraries.  If little or
 none of those do AES-CMAC yet (I don't think Windows CryptoAPI does, only very
 recent versions of OpenSSL do... it's not looking good) then you'd want to
 stick with HMAC-SHA1.
 
 (Forestalling the inevitable but developers can implement AES-CMAC 
 themselves 
 from raw AES that I'm sure someone will follow up with, the target audience 
 for this is web application developers, not cryptographers, so you need to 
 give them something that works as required out of the box).

Peter has hit the proverbial nail right on the head. I apologize if I did
not make this clear in my original post, but but one goal of OWASP ESAPI
is to not require a whole lot of dependencies. In the context of Java crypto,
this means that we *ideally* would like to have no other dependency other than
the SunJCE, that is, the Sun reference implementation for JCE. Recently we
decided to required Java 6, but even with that, our choices for cipher
algorithms, cipher modes, and padding schemes are limited. For SunJCE,
this is what we have available to choose from:

Supported symmetric cipher algorithms:
AES, DES, DESede, Blowfish, RC2, ARCFOUR

Supported cipher modes:
CBC, CFB, CTR, CTS, ECB, OFB, PCBC

Supported padding schemes:
NoPadding, PKCS5Padding ISO10126Padding
OAEPPadding, OAEPWithdigestAndmgfPadding
PKCS1Padding, SSL3Padding

(Obviously some of these padding schemes such as OAEP are not suitable
with symmetric ciphers. Or at least I don't think they are.)

So given these limited choices, what are the best options to the
questions I posed in my original post yesterday? As Peter mentioned, we
want to give web app developers something that will work out-of-the-box.
For that reason we don't even want to require that developers use some other
JCE provider like Bouncy Castle, Cryptix, IAIK, etc. even though they may
have more suitable cipher modes or padding schemes.

Lastly, I wanted to respond to one other point that David Wagner brought
up in an earlier reply:

 Advice: Provide one mode, and make it secure.  Try to avoid
 configurability, because then someone will choose a poor configuration.

There's a few reasons for supporting different configurations here. One
is the backward compatibility with previous ESAPI versions, and the second
is to support legacy cases. My experience at my day job is that no one
really changes the crypto defaults anyway if you make it easy enough for them
to use. The main exception is if they have to be compatible with something else
such as some 3rd party vendor software that uses a different mode, etc.
What we can try to do is provide adequate warning in documentation or
in logged warnings if one tries to use anything other then the default.

BTW, thanks to all who replied. I've learned quite a bit from all your
responses, but it looks like I have a lot of research to do before I
understand everything that all of you said.

Regards,
-kevin
-- 
Kevin W. Wall
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.-- Nathaniel Borenstein, co-creator of MIME

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

2009-09-17 Thread Peter Gutmann
Kevin W. Wall kevin.w.w...@gmail.com writes:

(Obviously some of these padding schemes such as OAEP are not suitable with
symmetric ciphers. Or at least I don't think they are.)

You'd be surprised at what JCE developers will implement just because they
can, and what therefore gets used by application developers.  I've seen 
RSA-CBC used on more than one occasion.

(No, that's not a typo, RSA in CBC mode.  The app developers wondered why it
was so slow).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Bringing Tahoe ideas to HTTP

2009-09-17 Thread Alexandre Dulaunoy
On Thu, Aug 27, 2009 at 11:57 PM, Brian Warner war...@lothar.com wrote:

 == Integrity ==

 To start with integrity-checking, we could imagine a firefox plugin that
 validated a PyPI-style #md5= annotation on everything it loads. The rule
 would be that no action would be taken on the downloaded content until
 the hash was verified, and that a hash failure would be treated like a
 404. Or maybe a slightly different error code, to indicate that the
 correct resource is unavailable and that it's a server-side problem, but
 it's because you got the wrong version of the document, rather than the
 document being missing altogether.

On the same idea,
there is an expired Internet-Draft called Link Fingerprints :

http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/

I made some experiments around while used as Machine Tag/Triple Tag[1] :

http://www.foo.be/cgi-bin/wiki.pl/MachineTagLinkFingerprint

to have an extension with OpenPGP detached signature.

Another potential use, it's to benefit from the number of users
checking the integrity and contribute back the computed
value into a tagging system like del.icio.us or any other
collaborative bookmarking.

I especially like the Firefox (or wget,curl) extension that
could compute the hash value and check it against various
contributed hashes. That could give a kind of confidence level
regarding the integrity of the file and its corresponding URL/URI.

Just some ideas,

adulau

[1] http://www.foo.be/cgi-bin/wiki.pl/MachineTag

-- 
--   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
-- http://www.foo.be/cgi-bin/wiki.pl/Diary
-- Knowledge can create problems, it is not through ignorance
--that we can solve them Isaac Asimov

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Biotech Based Cryptogram Challenge

2009-09-17 Thread Jim Windle
http://www.genengnews.com/cryptogramchallenge/

This is contest to decode the message encrypted in the colors of a 96 well
microtiter plate used for an enzyme-linked immunosorbent assay test in which
the color indicate the amount of antigen present.  The first to decode it
gets a $1500 prize.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

2009-09-17 Thread David Wagner
Kevin W. Wall wrote:
 So given these limited choices, what are the best options to the
 questions I posed in my original post yesterday?

Given these choices, I'd suggest that you first encrypt with AES-CBC mode.
Then apply a message authentication code (MAC) to the whole ciphertext
(including the IV).  You then send the ciphertext followed the MAC digest.

SHA1-HMAC would be a reasonable choice of algorithm for message
authentication.  Sun's JCA appears to support SHA1-HMAC.

http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Mac
http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html#Mac

You'll want to use key separation to derive two separate keys.  So
if the key K is the master key, you could use

Kenc  = SHA1-HMAC(K, encrypt)
Kauth = SHA1-HMAC(K, authenticate)

or you could use

Kenc  = AES-ECB(K, all-zeros)
Kauth = AES-ECB(K, all-ones)

(Either is fine.)  Then use Kenc as the crypto key for AES-CBC encryption
and Kauth as the crypto key for SHA1-HMAC authentication.

If you are encrypting messages that will be sent over a two-way channel,
you'll probably want to either use a different crypto key for each
direction or include a direction bit in the inputs to the key separation
step.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Biotech Based Cryptogram Challenge

2009-09-17 Thread Jon Callas


On Sep 17, 2009, at 6:31 AM, Jim Windle wrote:


http://www.genengnews.com/cryptogramchallenge/

This is contest to decode the message encrypted in the colors of a  
96 well
microtiter plate used for an enzyme-linked immunosorbent assay test  
in which
the color indicate the amount of antigen present.  The first to  
decode it

gets a $1500 prize.


Yes, but it has nothing to do with biotech at all, except in the  
presentation. The instructions say that the plaintext is represented  
in the RGB values of each cell, along with the transparency (alpha) of  
each color blob. So each character is represented (wolog, since we  
don't know how deep the alpha channel is) by an integer value of ABGR  
of each color blob.


Cute, but not biotech.

Jon

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

2009-09-17 Thread Jerry Leichter

On Sep 17, 2009, at 1:20 AM, Peter Gutmann wrote:


Kevin W. Wall kevin.w.w...@gmail.com writes:

(Obviously some of these padding schemes such as OAEP are not  
suitable with

symmetric ciphers. Or at least I don't think they are.)


You'd be surprised at what JCE developers will implement just  
because they
can, and what therefore gets used by application developers.  I've  
seen

RSA-CBC used on more than one occasion.

(No, that's not a typo, RSA in CBC mode.  The app developers  
wondered why it

was so slow).
Interesting.  It sounds as if the JCE developers have gone from one  
extreme to another.  I no longer remember the details, but a number of  
years back, in a project I was involved with, we needed to implement  
some particular (sane) combination of a cipher and a mode.  JCE at the  
time had a fixed list of combinations it was willing to let you use;  
ours wasn't on that list.  ECB wasn't an accepted mode, so it wasn't  
easy to build your own mode out of what the API provided.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com