Re: Bringing Tahoe ideas to HTTP

2009-09-18 Thread Peter Gutmann
Alexandre Dulaunoy adu...@gmail.com writes:

On the same idea, there is an expired Internet-Draft called Link
Fingerprints :
http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/

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?

(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...).

Peter.

-
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-18 Thread Joseph Ashwood

--
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

2009-09-18 Thread Alexandre Dulaunoy
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

2009-09-18 Thread Alec Muffett
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

2009-09-18 Thread Ian G

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

2009-09-18 Thread Peter Gutmann
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

2009-09-18 Thread Steve Furlong
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