Re: [tahoe-dev] a crypto puzzle about digital signatures and future compatibility

2009-09-04 Thread Zooko Wilcox-O'Hearn

On Thursday,2009-08-27, at 19:14 , James A. Donald wrote:


Zooko Wilcox-O'Hearn wrote:
Right, and if we add algorithm agility then this attack is  
possible  even if both SHA-2 and SHA-3 are perfectly secure!
Consider this variation of the scenario: Alice generates a  
filecap  and gives it to Bob.  Bob uses it to fetch a file, reads  
the file and  sends the filecap to Carol along with a note saying  
that he approves  this file.  Carol uses the filecap to fetch the  
file.  The Bob-and- Carol team loses if she gets a different file  
than the one he got.

...
So the leading bits of the capability have to be an algorithm  
identifier.  If Bob's tool does not recognize the algorithm, it  
fails, and he has to upgrade to a tool that recognizes more  
algorithms.


If the protocol allows multiple hash types, then the hash has to  
start with a number that identifies the algorithm.  Yet we want  
that number to comprise of very, very few bits.


Jim, I'm not sure you understood the specific problem I meant -- I'm  
concerned (for starters) with the problems that arise if we support  
more than one secure hash algorithm *even* when none of the supported  
secure hash algorithms ever becomes crackable!


So much so that I currently intend to avoid having a notion of  
algorithm agility inside the current Tahoe-LAFS code base, and  
instead plan for an algorithm upgrade to require a code base upgrade  
and a separate, syntactically distinct, type of file capability.


This is almost precisely the example problem I discuss in http:// 
jim.com/security/prefix_free_number_encoding.html


Hey, that's interesting.  I'll study your prefix-free encoding format  
some time.


Regards,

Zooko

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


Re: Source for Skype Trojan released

2009-09-04 Thread Stephan Neuhaus


On Aug 31, 2009, at 13:20, Jerry Leichter wrote:

It can “...intercept all audio data coming and going to the Skype  
process.”


Interesting, but is this a novel idea? As far as I can see, the  
process intercepts the audio before it reaches Skype and after it has  
left Skype. Isn't that the same as calling a keylogger a PGP Trojan?


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


Re: AES-GMAC as a hash

2009-09-04 Thread Hal Finney
Darren J Moffat darren.mof...@sun.com asks:
 Ignoring performance for now what is the consensus on the suitabilty of 
 using AES-GMAC not as MAC but as a hash ?

 Would it be safe ?

 The key input to AES-GMAC would be something well known to the data 
 and/or software.

No, I don't think this would work. In general, giving a MAC a fixed key
cannot be expected to produce a good hash. With AES-GMAC in particular,
it is unusual in that it has a third input (besides key and data to MAC),
an IV, which makes your well-known-key strategy problematic. And even as a
MAC, it is very important that a given key/IV pair never be reused. Fixing
a value for the key and perhaps IV would defeat this provision.

But even ignoring all that, GMAC amounts to a linear combination of
the text blocks - they are the coefficients of a polynomial. The reason
you can get away with it in GMAC is because the polynomial variable is
secret, it is based on the key. So you don't know how things are being
combined. But with a known key and IV, there would be no security at all.
It would be linear like a CRC.

Hal Finney

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


Re: [Macgpg-users] GPGMail Snow Leopard

2009-09-04 Thread David Shaw

On Aug 28, 2009, at 8:25 PM, R.A. Hettinga wrote:


...and now GPG.

So, Snow Leopard is crypto-less?


To be strictly accurate, the problem is with GPGMail, the plugin that  
integrates GPG with Apple's Mail application (as Mail internals  
changed significantly between Leopard and Snow Leopard).  GPG itself  
seems to work just fine under Snow Leopard, albeit on the command line.


David

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


Re: AES-GMAC as a hash

2009-09-04 Thread Darren J Moffat

Hal Finney wrote:

Darren J Moffat darren.mof...@sun.com asks:
Ignoring performance for now what is the consensus on the suitabilty of 
using AES-GMAC not as MAC but as a hash ?


Would it be safe ?

The key input to AES-GMAC would be something well known to the data 
and/or software.


No, I don't think this would work. In general, giving a MAC a fixed key
cannot be expected to produce a good hash. With AES-GMAC in particular,
it is unusual in that it has a third input (besides key and data to MAC),
an IV, which makes your well-known-key strategy problematic. And even as a
MAC, it is very important that a given key/IV pair never be reused. Fixing
a value for the key and perhaps IV would defeat this provision.

But even ignoring all that, GMAC amounts to a linear combination of
the text blocks - they are the coefficients of a polynomial. The reason
you can get away with it in GMAC is because the polynomial variable is
secret, it is based on the key. So you don't know how things are being
combined. But with a known key and IV, there would be no security at all.
It would be linear like a CRC.


Thanks, that is pretty much what I suspected would be the answer but you 
have more detail than I could muster in my head at a first pass on this.


Thanks.

--
Darren J Moffat

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


Re: AES-GMAC as a hash

2009-09-04 Thread Matt Ball
On Thu, Aug 27, 2009 at 8:45 AM, Darren J Moffat wrote:

 Ignoring performance for now what is the consensus on the suitabilty of using 
 AES-GMAC not as MAC but as a hash ?

 Would it be safe ?

 The key input to AES-GMAC would be something well known to the data and/or 
 software.

 The only reason I'm asking is assuming it can be made to perform on some 
 classes of machine better than or close to SHA256 if it would be worth 
 considering as an available alternate now until SHA-3 is choosen.

In the 2005 Security in Storage Workshop (see
http://ieeeia.org/sisw/2005/), David McGrew proposed using GMAC to
protect large dynamic data sets, such a random access memory (RAM)
(see http://ieeeia.org/sisw/2005/PreProceedings/10.pdf).  The general
idea is to use the linear characteristics of GMAC to dynamically
update the MAC when updating a memory address.  If your use-case is
similar to this approach, then it would be possible to securely use
GMAC.

However, there are many caveats when using GMAC, so it's vitally
important to understand all the constraints.

Cheers,

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717

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


RNG using AES CTR as encryption algorithm

2009-09-04 Thread priya yelgar
Hi all,

I have implemented RNG using AES algorithm in CTR mode.

To test my implementation I needed some test vectors.

How ever I searched on the CSRC site, but found the test vectors for AES_CBC 
not for AES CTR.

Please  can any one tell me where to look for the test vectors to test RNG 
using  AES CTR.


Thanks in advance 
Priya Ainapur






  Love Cricket? Check out live scores, photos, video highlights and more. 
Click here http://cricket.yahoo.com
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-04 Thread Steven Bellovin


On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote:

On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz 
 wrote:
More generally, I can't see that implementing client-side certs  
gives you much
of anything in return for the massive amount of effort required  
because the
problem is a lack of server auth, not of client auth.  If I'm a  
phisher then I
set up my bogus web site, get the user's certificate-based client  
auth
message, throw it away, and report successful auth to the client.   
The browser
then displays some sort of indicator that the high-security  
certificate auth
was successful, and the user can feel more confident than usual in  
entering
their credit card details.  All you're doing is building even more  
substrate

for phishing attacks.

Without simultaneous mutual auth, which -SRP/-PSK provide but PKI  
doesn't,
you're not getting any improvement, and potentially just making  
things worse

by giving users a false sense of security.


I certainly agree that if the problem you are trying to solve is
server authentication, then client certs don't get you very far. I
find it hard to feel very surprised by this conclusion.

If the problem you are trying to solve is client authentication then
client certs have some obvious value.

That said, I do tend to agree that mutual auth is also a good avenue
to pursue, and the UI you describe fits right in with Chrome's UI in
other areas. Perhaps I'll give it a try.



This returns us to the previously-unsolved UI problem: how -- with  
today's users, and with something more or less like today's browsers  
since that's what today's users know -- can a spoof-proof password  
prompt be presented?


--Steve Bellovin, http://www.cs.columbia.edu/~smb





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


so how do *you* manage your keys, then? part 3

2009-09-04 Thread Zooko Wilcox-O'Hearn

So How Do You Manage Your Keys Then, part 3 of 5

In part one of this series [1] I described how Tahoe-LAFS combines  
decryption, integrity-checking, identification, and access into one  
bitstring, called an immutable file read-cap (short for  
capability).  In part two [2] I described how users can build tree- 
like structures of files which contain caps pointing to other files,  
and how the cap pointing to the root of such a structure can reside  
on a different computer than the ciphertext.  (Which is necessary if  
you want someone to store the ciphertext for you but you don't want  
to give them the ability to read the file contents.)


In this installment, consider the question of whether you can give  
someone a cap (which acts as a file handle) and then change the  
contents of the file that the cap points to, while preserving their  
ability to read with the original cap.


This would be impossible with the immutable file read-caps that we  
have been using so far, because each immutable file read cap uses a  
secure hash function to identify and integrity-check exactly one  
file's contents -- one unique byte pattern.  Any change to the file  
contents will cause the immutable file read-cap to no longer match.   
This can be a desirable property if what you want is a permanent  
identifier of one specific, immutable file.  With this property  
nobody -- not even the person who wrote the file in the first place  
-- is able to cause anyone else's read-caps to point to any file  
contents other than the original file contents.


But sometimes you want a different property, namely that an  
authorized writer *can* change the file contents and readers will be  
able to read the new file contents without first having to acquire a  
new file handle.


To accomplish this requires the use of public key cryptography,  
specifically digital signatures.  Using digital signatures, Tahoe- 
LAFS implements a second kind of capability, in addition to the  
immutable-file capability, which is called a mutable file  
capability.  Whenever you create a new mutable file, you get *two*  
caps to it: a write-cap and a read-cap.  (Actually you can always  
derive the read-cap from the write-cap, so for API simplicity you get  
just the write-cap to your newly created mutable file.)


Possession of the read-cap to the mutable file gives you two things:  
it gives you the symmetric encryption key with which you decrypt the  
file contents, and it gives you the public key with which you check a  
digital signature in order to be sure that the file contents were  
written by an authorized writer.  The decryption and signature  
verification both happen automatically whenever you read data from  
that file handle (it downloads the digital signature which is stored  
with the ciphertext).


Possession of the write-cap gives two things: the symmetric key with  
which you can encrypt the ciphertext, and the private key with which  
you can sign the contents.  Both are done automatically whenever you  
write data to that file handle.


The important thing about this scheme is that what we crypto geeks  
call key management is almost completely invisible to the users.   
As far as the users can tell, there aren't any keys here!  The only  
objects in sight are the file handles, which they already use all the  
time.


All users need to know is that a write-cap grants write authority  
(only to that one file), and the read-cap grants read authority.   
They can conveniently delegate some of their read- or write-  
authority to another user, simply by giving that user a copy of that  
cap, without delegating their other authorities. They can bundle  
multiple caps (of any kind) together into a file and then use the  
capability to that file as a handle to that bundle of authorities.


At least, this is the theory that the object-capability community  
taught me, and I'm pleased to see that -- so far -- it has worked out  
in practice.


Programmers and end users appear to have no difficulty understanding  
the access control consequences of this scheme and then using the  
scheme appropriately to achieve their desired ends.


Installment 4 of this series will be about Tahoe-LAFS directories  
(those are the most convenient way to bundle together multiple caps  
-- put them all into a directory and then use the cap which points to  
that directory).  Installment 5 will be about future work and new  
crypto ideas.


Regards,

Zooko

[1] http://allmydata.org/pipermail/tahoe-dev/2009-August/002637.html  
# installment 1: immutable file caps
[2] http://allmydata.org/pipermail/tahoe-dev/2009-August/002656.html  
# installment 2: tree-like structure (like encrypted git)


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


Re: Client Certificate UI for Chrome?

2009-09-04 Thread James A. Donald

Steven Bellovin wrote:
This returns us to the previously-unsolved UI problem: how -- with 
today's users, and with something more or less like today's browsers 
since that's what today's users know -- can a spoof-proof password 
prompt be presented?


When the user clicks on a button generated by a particular special kind 
of html tag, perhaps
loginbutton logintype=SRP 
loginurl=/customers/loginpage.scriptlogin/loginbutton


A not quite rectangular login form which is not an html page rolls out 
of the url, with a motion like a blind or toilet paper unrolling, and 
partially covers the browser chrome, thus associating the form  with the 
browser and the url, rather than the web page.


The form will be decorated and prominently watermarked in manner that is 
customizable by the end user, and if the end user does not customize it, 
which he probably will not, a customization was randomly selected at 
install time.


A phisher could do a flash animation that looks almost like the form 
rolling out, but the flash animation will not roll out of the url, and 
will not partially cover the browser chrome, and is unlikely to match 
the customization.


If the url is http://exampledomain.com/somedirectory/somepage.html

Then the content of the login form is controlled by script at 
login://exampledomain.com//customers/loginpage.script


The login form will be associated with a public key.  If the user has 
logged in before using this browser, there will be an entry in his 
bookmarks list for the url *and* public key


If the login form is the browser's bookmark list, the title on the login 
form will be the petname, that is to say, the name under which it 
appears in the bookmark list.


If the login form is *not* in the browser's bookmark list, the title on 
the login form will be No Previous Login at this site using this 
browser by this user, with script supplied title and or certificate 
supplied title somewhere else in smaller print.


The loginpage.script will tell the browser what fields and fieldnames to 
request from the user - typically username and password, but this needs 
to be scriptable - for example it could be credit card number, etc.  The 
script will tell the server what database table and what database fields 
to associate these user supplied fields with when the client responds.


Peter Gutmann has, he believes, a much simpler solution.

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


Re: Client Certificate UI for Chrome?

2009-09-04 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

This returns us to the previously-unsolved UI problem: how -- with today's
users, and with something more or less like today's browsers since that's
what today's users know -- can a spoof-proof password prompt be presented?

Good enough to satisfy security geeks, no, because no measure you take will
ever be good enough.  However if you want something that's good enough for
most purposes then Camino has been doing something pretty close to this since
it was first released (I'm not aware of any other browser that's even tried).
When you're asked for credentials, the dialog rolls down out of the browser
title bar in a hard-to-describe scrolling motion a bit like a supermarket till
printout.  In other words instead of a random popup appearing in front of you
from who knows what source and asking for a password, you've got a direct
visual link to the thing that the credentials are being requested for.  You
can obviously pepper and salt this as required (and I wouldn't dream of
deploying something like this without getting UI folks to comment and test it
on real users first), but doing this is a tractable UI design issue and not an
intractable business-model/political/social/etc problem.

Peter.

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