Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI
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
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
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
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: Biotech Based Cryptogram Challenge
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
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
