Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI
-- From: Kevin W. Wall kevin.w.w...@gmail.com Subject: Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI 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. It isn't difficult to implement CMAC and CTR modes in pure Java. The NIST specs for CMAC and CTR are plenty clear. You'll be looking for the AES/ECB/NoPadding option. From there use update it returns a byte []. I've used the standard JCE implementation in this way to implement unsupported modes before, it works. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Fri, Sep 18, 2009 at 6:27 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Although the draft has expired, the concept lives on in various tools. For example DownThemAll for Firefox supports this. There was some discussion about including it into FF3, but then the draft was dropped and the FF support never appeared, does anyone know what happened? It was a SoC project within Mozilla but seeing the following discussion : https://bugzilla.mozilla.org/show_bug.cgi?id=377245 The state looks a bit unclear to me... (The cynic in me would say it's such a simple, straightforward, easy-to- implement idea, of course it'll never be adopted when there are things like EV certs to be pushed instead, but who knows...). mode type=cynic Right... When I see the EV audit process[1], it looks to me like PCI DSS without the technical aspect... /mode [1] http://cabforum.org/WebTrustAuditGuidelines.pdf -- -- 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
From Ivory Tower to Iron Bars: Scientists Risk Jail Time for Violating Export Laws
Perry: plasma physics is wildly OT but I believe the relevance will be obvious to those who remember the crypto wars, especially when they hit the fifth paragraph: It’s a difficult subject: many people I interviewed felt Roth showed blatant disregard for the law — he was warned his work fell under the State Department’s munitions list — but they expressed deep frustration with the ambiguity of the laws. http://www.wired.com/dangerroom/2009/09/from-ivory-tower-to-iron-bars-academics-risk-jail-time-for-violating-export-laws/ short: http://is.gd/3pd0d There but for the grace of Bernstein? Or something like that... :-) -a - 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 17/09/2009 21:42, David Wagner wrote: 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. I have to add vote+1 on this selection. For various reasons, today's safe choice seems to be: * CBC * AES-128 * HMAC-SHA-1 on the outside of the ciphertext What is left is padding so that the message is clearly deliminated. I suggest you treat this as a software engineering thing, not a crypto thing, and make sure that you have a length in your packet layout so that it is totally clear what is the packet and what is not. If you want to see such a design exercise, following Dave's prescription, have a look at SDP1 which Zooko and I did a few years back. http://www.webfunds.org/guide/sdp/sdp1.html http://www.webfunds.org/guide/sdp/ It's a straight forward secret-key encrypted packet layout. It has one novelty in it, which is how it solves the padding / IV issues. Other than that it should be boring. iang PS: you are on the right track in trying to avoid any sensitivity to JCE. As long as you can design your layout without any dependency on JCE it should work. JCE is basically a slock design that was put in place for market- and crypto-control reasons, it has no place in software engineering. I speak from experience, I managed the Cryptix project, which was the first Java crypto engine. PPS: you haven't said enough about the application (or I missed it) to be able to comment on keys. Generally, try to separate the protocol around the key: every good protocol divides into two parts, the first of which says to the second, trust this key completely. Software engineering ... http://iang.org/ssl/h2_divide_and_conquer.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] Bringing Tahoe ideas to HTTP
Brian Warner war...@lothar.com writes: From what I can tell, the Sparkle update framework (for OS-X)[1] is doing something like what I want for firefox: the Sparkle-enabled application will only accept update bundles which are signed by a DSA privkey that matches a pubkey embedded in the app. You can extend this further to make it tolerant of key loss by embedding multiple public keys and allowing a quorum of them to replace an existing key. So say you have five keys, you can decide that any three of them can vote out an existing key, allowing compromised keys to be replaced and existing keys to be rolled over. This creates a kind of fault-tolerant PKI which does away with the need to have a CA vouch for key replacements, once you've got the initial keys established (for example on first install) you can recover from anything short of a total compromise, upgrade to larger keys sizes and hashes, and so on. It'd be nice if Firefox could do the same. And if Firefox were to establish a quietly-backwards-compatible convention (i.e. the hash-mark trick) for strong URL-based authentication of HTTP resources, then other applications could start using it too, and a significant class of current web security problems (like the mixed-content one where an HTTPS page loads a javascript library via HTTP) could be fixed. See my previous post, there was an attempt made to do this in the past but it never got anywhere. It'd be interesting to hear the reasons why. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: From Ivory Tower to Iron Bars: Scientists Risk Jail Time for Violating Export Laws
On Fri, Sep 18, 2009 at 4:32 AM, Alec Muffett alec.muff...@gmail.com wrote: Perry: plasma physics is wildly OT but I believe the relevance will be obvious to those who remember the crypto wars, especially when they hit the fifth paragraph: It’s a difficult subject: many people I interviewed felt Roth showed blatant disregard for the law — he was warned his work fell under the State Department’s munitions list — but they expressed deep frustration with the ambiguity of the laws. Hypothetically, if I were to write an open source library or application involving crypto, I'd send the source and docn through an anonymizing remailer to someone overseas who could then put it on appropriate websites. Or I'd go through a web anonymizer and post on appropriate sites myself. Time was, hypothetically, that I'd anonymously put source on alt.* Usenet groups, but they're dead in the US. Even with relaxed interpretation of the crypto export laws, anyone in the US would be a fool to rely on that interpretation. Never never never put your name on publicly available crypto unless you've jumped through all the hoops written into the law. (And I wouldn't do so even then.) Regards, SRF -- Neca eos omnes. Deus suos agnoscet. -- Arnaud-Amaury, 1209 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
