Re: RNG using AES CTR as encryption algorithm

2009-09-08 Thread Jack Lloyd
On Wed, Sep 02, 2009 at 10:58:03AM +0530, priya yelgar wrote:
 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.

NIST SP 800-38A Recommendation for Block Cipher Modes of Operation
contains a set of AES/CTR test vectors in Appendix F.5

http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

-Jack

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Nicolas Williams
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote:
 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.  [...]

Well, if you're willing to reserve screen real estate, keyboard key
combinations, and so on, with said reserved screen space used to
indicate unambiguously the nature of other things displayed, and
reserved input combinations used to trigger trusted software paths, then
yes, you can solve that problem.  That's the premise of trusted
desktops, at any rate.  There are caveats, like just how large the TCB
becomes (including parts of the browser), the complexity of the trusted
information to be presented to users versus the limited amount of screen
real estate available to convey it, the need to train users to
understand the concept of trusted desktops, no fullscreen apps can be
allowed, accessibility issues, it all falls apart if the TCB is
compromised, ...

Nico
-- 

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


Re: [cryptography] AES-GMAC as a hash

2009-09-08 Thread Eric Young
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.

Regarding the speed of GMAC,  Intel has added a
carry-less-multiplication instruction to their next generation CPUs
(PCLMULQDQ)[1].
The core is the Westmere, and is shipping in engineering samples, now. 
This is also the CPU generation to contain the AES instructions.
Unfortunately I'm only running my implementation under the intel
simulator which is not cycle accurate, so I'm not sure just how fast
this hardware support will make things.  My understanding is that the
next generation AMD CPUs, (bulldozer) will also support these instructions.

eric

[1]
http://software.intel.com/en-us/articles/carry-less-multiplication-and-its-usage-for-computing-the-gcm-mode/

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


Re: RNG using AES CTR as encryption algorithm

2009-09-08 Thread David Johnston
NIST doesn't provide specific KAT vectors for AES-CTR because the 
results depend on your specific counter construction.
When you interact with a FIPS test lab, you will provide them with your 
counter construction, they will provide you with the KATs and you will 
then test to those KATs.


This is probably why you are not finding AES-CTR vectors in the same 
places you might find AES-CBC vectors. NIST explains this somewhere in 
their publications.


Convincing yourself that you have implemented AES-CTR correctly usually 
involves first checking that your AES-ECB is correct, then putting the 
output of you counter construction into some other known good AES-CTR 
implementation and comparing the results with your implementation.


Regards,
DJ

priya yelgar wrote:

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


  


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


Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-08 Thread James A. Donald

Nicolas Williams wrote:
  One possible problem: streaming [real-time] content.

Brian Warner wrote:
 Yeah, that's a very different problem space. You need
 the low-alacrity stuff from Tahoe, but also you don't
 generally know the full contents in advance. So you're
 talking about a mutable stream rather than an
 immutable file.

Not mutable, just incomplete.

Immutable streaming content needs a tiger hash or a
patricia hash, which can handle the fact that some of
the stream will be lost in transmission, and that one
needs to validate the small part of the stream that one
has already received rather than waiting for the end.

 upgrade bundles are produced by a very strict process,
 and are rigidly immutable [...] For software upgrades,
 it would reduce the attack surface significantly.

But how does one know which immutable file is the one
that has been blessed by proper authority?  Although
Version 3.5.0 is immutable, what makes it Version 3.5.0,
rather than haxx350, is that some authority says so -
the same authority that said that your current version
is 3.4.7 - and it should not even be possible to get a
file named by some different authority as an upgrade.

Of course, one would like a protocol that committed the
authority to say the same thing for everyone, and the
same thing for all time, saying new things in future,
but never being able to retroactively adjust past things
it has said.

In other words, upgrades should be rooted in an append
only capability.

I suppose this could be implemented as a signed dag of
hashes, in which whenever one upgraded, one checked that
the signed dag that validates the upgrade is consistent
with the signed dag that validated the current version.

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Peter Gutmann
Ian G i...@systemics.com writes:

If one is trying to solve the whole thing, then using the much-commented
secure-bookmarks model would do this.  Within the secure bookmark, record the
user's certificate and cache enough info on the server's cert to deal with
replacements (like, cert, name, CA).

There's a variant of this, the site-specific browser (SSB), that takes you to
(for example) your bank in a strongly sandboxed, hardened environment.  This
reduces the cognitive load on the user from a more or less impossible-to-
follow set of instructions to only ever do your banking by clicking on this
desktop icon.  This isn't by any means a general solution, but by solving for
the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly
large chunk of the problem.  See Breaking out of the Browser to Defend
Against Phishing Attacks by Smetters and Stewart for more details on this.

Others have suggested some ideas, so I'll just add:  the problem isn't IMO
how to do it.  There are lots of good ideas.

Actually that does point out one problem, which I alluded to in my previous 
post: we have lots and lots of good ideas, but little hard data to indicate 
which ones will work and which won't, or which ones work better than others 
(although the cynical response to this might be that almost anything would 
work better than what we've got now).  Specifically, there are a pile of 
papers along the lines of here's an experiment showing that what we're doing 
now doesn't work, here's a completely new security mechanism we've invented 
that involves redesigning the browser and server authentication back-end, and 
as a side-effect here are some UI ideas to go with it.  What we don't have 
however is here's a real-world evaluation of various ideas that have been 
proposed for fixing what we already have built into browsers and servers. 
Unfortunately without this data we (including myself) are to some extent just 
people wanking around with their opinions [0].

It's also not certain how such data would be published.  Which journal or
conference would accept a paper with no new ideas in it, just a
straightforward evaluation of existing material?

Peter.

[0] A Linus quote, brought about by a discussion on the difference between OS
secheduler design and security design: the *discussion* on security seems to
never get down to real numbers. So the difference between them is simple: one
is 'hard science'. The other one is 'people wanking around with their
opinions'.

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Steven Bellovin


On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote:


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.



Several other people made similar suggestions.  They all boil down to  
the same thing, IMO -- assume that the user will recognize something  
distinctive or know to do something special for special sites like  
banks.  Both, to me, are unproven assumptions.  Worse yet, both the  
security literature and what I've seen of user behavior strongly  
suggest to me that neither scenario is true.


Peter, I'm not sure what you mean by good enough to satisfy security  
geeks vs. good enough for most purposes.  I'm not looking for  
theoretically good enough, for any value of theory; my metric -- as  
a card-carrying security geek -- is precisely good enough for most  
purposes.  A review of user studies of many different distinctive  
markers, from yellow URL bars to green partial-URL bars to special  
pictures to you-name-it shows that users either never notice the  
*absence* of the distinctive feature or are fooled by a tailored  
attack (see, e.g., the paper on picture-in-picture attacks).  Maybe  
Camino is really better -- or maybe it just hasn't been properly  
attacked yet, say by a clever flash animation or some AJAX weirdness.   
Given the failure of all previous attempts -- who, amongst the  
proponents of EV certificates, realized that attackers could and would  
use all-green favicon.ico files to fool users -- I think the burden of  
proof is on the proponents.


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





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


Re: Client Certificate UI for Chrome?

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

Peter, I'm not sure what you mean by good enough to satisfy security geeks
vs. good enough for most purposes.  I'm not looking for theoretically good
enough, for any value of theory; my metric -- as a card-carrying security
geek -- is precisely good enough for most purposes.

Here's a real-world example of the problem I was referring to, from a
discussion with some browser developers.  We were going over the above issue -
how to use the results of usability studies to improve the browser security UI
- and I asked why, if they were aware of this work, no-one had done anything
with it.  The response was that if we implement this then attackers will use
XUL to spoof it, and because of that it's not even worth trying.  In other
words because a hypoethetical weakness existed, it wasn't even worth
attempting to improve anything.  Instead of trying to help at least some of
the people some of the time, it was better to leave everyone unprotected all
of the time.

Given the failure of all previous attempts -- who, amongst the proponents of
EV certificates, realized that attackers could and would use all-green
favicon.ico files to fool users -- I think the burden of proof is on the
proponents.

But the problem with these approaches is that they're pretty much all just
random tweaking of the same thing, aimlessly rearranging the UI elements in
the hope that eventually something will work after (as you point out) the
twenty more or less identical previous attempts have failed.  For example the
Firefox password-entry mechanism (a generic popup dialog with a gibberish
title) hasn't changed in at least ten years (possibly even longer, I can't
remember what the Netscape 2.0 one looked like any more), all that's changed
is that every major release a few new bits of flair get added to the browser
chrome.  The previous attempts aren't lots of different approaches, it's the
same failed approach tried over and over and over again, with slight
variations over time in the hope that one of them might work.

What I was advocating was trying new approaches based on ideas from UI
research, not just fiddling with the chrome in the hope that this time it'll
finally start working.

Peter.

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


Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-08 Thread Brian Warner
James A. Donald wrote:
 Nicolas Williams wrote:
One possible problem: streaming [real-time] content.
 
 Brian Warner wrote:
   Yeah, that's a very different problem space. You need
   the low-alacrity stuff from Tahoe, but also you don't
   generally know the full contents in advance. So you're
   talking about a mutable stream rather than an
   immutable file.
 
 Not mutable, just incomplete.
 
 Immutable streaming content needs a tiger hash or a
 patricia hash, which can handle the fact that some of
 the stream will be lost in transmission, and that one
 needs to validate the small part of the stream that one
 has already received rather than waiting for the end.

I was assuming a real-time stream, so the goal would be to provide a
filecap before the source had finished generating all the bits. This
would necessarily be a mutable filecap, unless you've got some way of
predicting the future :-).

If instead, you just have a large file that a client wants to fetch one
piece at a time, well, Tahoe's immutable-file merkle trees already
handle the goal of quickly validating a small part of a large byte
sequence. You could use this in a non-real-time stream, in which you
process the entire input stream, produce and publish the filecap, then a
client fetches pieces of that stream at their own pace.


   upgrade bundles are produced by a very strict process,
   and are rigidly immutable [...] For software upgrades,
   it would reduce the attack surface significantly.
 
 But how does one know which immutable file is the one
 that has been blessed by proper authority?

You're right, I was assuming a pre-existing secure what to upgrade to
channel which could send down an integrity-enhanced download URL. To
actually implement such a channel would require further integrity
guarantees over mutable data.

As I understand it, Firefox actually has a fairly complex upgrade path,
because only certain combinations of from-version/to-version are fully
tested by QA. Sometimes moving from e.g. 3.0.0.8 to 3.5.0.3 requires
going through a 3.0.0.8-3.0.0.9-3.5.0.0-3.5.0.2-3.5.0.3 sort of
path. The upgrade channel basically provides instructions to each older
version, telling them which new version they should move to.

The best sort of integrity guarantees I could think of would be a rule
that says the new version must be signed by my baked-in DSA key and
have a version number that is greater than mine, or maybe just the
upgrade instructions must be signed by that DSA key. It's probably not
a robust idea to make the rules too strict.

cheers,
 -Brian

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Jerry Leichter

On Sep 3, 2009, at 12:26 AM, Peter Gutmann 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?


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
I'm not sure what version of Camino you're running.  The most recent  
versions use a standard Mac OS GUI element to prompt for passwords -  
it's indistinguishable from what you get from Safari.  In both cases,  
a special prompt window scrolls down out of the chrome, covering some  
of the main body of the window.  It has a distinctive look:  After  
it's scrolled down, it appears to be under the chrome but over the  
top of the body.  In Safari - I didn't experiment with Camino - it's  
physically tied to the browser window, moving and iconifying with it,  
and is fully modal at the window level - you can't switch to another  
tab in the same window.  (Curiously, you *can* switch to a different  
window.)  The loading indicator in the address bar remains active  
while you're being prompted.  The *intent* is clearly to create  
something hard to spoof, but I don't know enough Flash to say if one  
could produce an accurate, or even plausible, fake.  (Of course,  
*most* passwords on the Web are entered into some random web page.  A  
distinctive secure prompt that only appears in a minority of cases  
doesn't help much.)


The most common MacOS password prompts are from the keychain program,  
since you typically store your passwords there.  (There are  
configurations in which it just asks for permission, not for a  
password; and configurations in which it just sends the password.  But  
if you want to be careful, you only want keychains unlocked when you  
intend to use them.)  Since *any* program - including programs with no  
visible GUI - can use keychains, these prompts are necessarily stand- 
alone windows at least sometimes (and for uniformity, they are so all  
the time).  Those could be spoofed more easily (though if you're  
really cautious, you can unlock the necessary keychain by hand ahead  
of time and arrange to just give permission to use the entry later, so  
you're never entering your password into a window that just pops up on  
its own).


-- Jerry

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


Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)

2009-09-08 Thread Peter Gutmann
Thor Lancelot Simon t...@rek.tjls.com writes:

I think we're largely talking past one another.  As regards new horrible
problems I meant simply that if there _are_ new horrible problems_ such
that we need to switch away from SHA1 in the TLS PRF, the design mistakes
made in TLS 1.1 will make it much harder.

Well, let's move the TLS 1.2 aspect out of the discussion and look at the
underlying issues.  If you're looking at this purely from a theoretical point
of view then it's possible that the ability to use SHA-2 in the PRF is an
improvement (it may also be a step backwards since you're now relying on a
single hash rather than the dual hash used in the original design).  Since no-
one knows of any attacks, we don't know whether it's a step backwards, a step
forwards, or (most likely) a no-op.

However there's more to it than this.  Once you've got the crypto sorted out,
you need to implement it, and then deploy it.  So looking at the two options
you have:

Old: No known crypto weaknesses.
 Interoperable with all deployed implementations.
 Only one option, so not much to get wrong.

New: No known crypto weaknesses.
 Interoperable with no deployed implementations.
 Lots of flexibioity and options to get wrong.

Removing the common factors (the crypto portion) and the no-op terms
(interoperable with existing implementations) we're left with:

Old: -
New: Non-interoperable.
 Complex - Likely to exhibit security flaws (from the maxim that
   complexity is the enemy of security).

That's a rather high cost to pay just for the ability to make a crypto fashion
statement.  Even if the ability to negotiate hash algorithms had been built in
from the start, this only removes the non-interoperability but doesn't remove
the complexity issue.

As I read Ben's comments, they were _advocating_ those kinds of design
mistakes, advocating hard-wiring particular algorithms or their parameter
sizes into protocols,

You keep asserting that this is a mistake, but in the absence of any
cryptographic argument in support, and with practical arguments against it, it
looks like a feature to me.

In fact, it is radically harder to replace an entire protocol, even with a
related one, than to drop a new algorithm into an existing, properly-designed
protocol.

A properly-designed security protocol is one that's both cryptographically
sound and simple enough that it's hard to get wrong (or at least relatively
easy to get right, admittedly not necessarily the same thing).  Adding a pile
of complexity simply so you can make a crypto fashion statement doesn't seem
to be helping here.

If TLS 1.{0,1} had been designed to make the hash functions pluggagle
everywhere

... like that model of security protocol design IKEv1 was [0], then we'd have
all kinds of interop problems and quite probably security issues based on
exploitation of the unnecessary complexity of the protocol, for a net loss in
security and interoperability, and nothing gained.

Peter.

[0] Apologies to the IPsec folks on the list, just trying to illustrate the
point.

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


Re: Source for Skype Trojan released

2009-09-08 Thread Dave Howe
Stephan Neuhaus wrote:
 
 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?

Not really. more generically, you could call it a VoIP trojan or even
Audio monitoring trojan - presumably a more advanced version could
listen to the mic stream even when the VoIP application is not in use,
in order to obtain information.

However, in context, this was designed to be used for law enforcement to
bug a skype VoIP session, so the name reflects the design goal; yes,
it is a more generalized attack than that, but not in intent or
(presumed) usage.

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


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

2009-09-08 Thread Zooko Wilcox-O'Hearn
[added Cc: tahoe-...@allmydata.org, and I added ke...@guarana.org on  
the whitelist so his posts will go through to tahoe-dev even if he  
isn't subscribed]



On Tuesday,2009-09-08, at 5:54 , Kevin Easton wrote:

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.


How do you prevent someone possessing the read-cap for a mutable  
file from rolling the file back to an earlier version that they  
have seen, without the consent of the write-cap possessor(s)?


You don't even need a read-cap to perform a roll-back attack -- if  
you can control the ciphertext that the reader gets, then you can  
give them a copy of an older ciphertext, even if you yourself are  
incapable of decrypting it.  This is a difficult attack to defend  
against.  In the current version of Tahoe-LAFS we already have one  
interesting defense -- we the reader is communicating with many  
different servers, and if *any* of the servers is honest and up-to- 
date and informs the reader about the existence of a newer version,  
then the reader knows that the older version that he can read is not  
the latest.  Readers in Tahoe-LAFS always download shares of the file  
from multiple servers, and all of the servers that it uses would have  
to agree on the version number.  Therefore, to perform a rollback  
attack you need to control at least that many servers as well as you  
have to control or deny-access-to any other servers which the reader  
would query and which would inform him about the newer version  
number.  See section 5 of [1].


Does that answer your question about rollback?

It would be interesting to build stronger defenses against rollback  
attack.  For starters, if the same reader reads the same file  
multiple times and gets new contents each time, he might as well  
remember the version number so that he will detect whether that file  
rolled back during his inspection of it.  Also, it would be  
interesting if a file handle to a mutable file included the version  
number that the mutable file was at when the file handle was  
created.  Building on that, it would be really cool if, in a future  
version of Tahoe-LAFS, we could make it so that you can take a cheap  
snapshot of the current contents and then give someone a file-handle  
which *both* securely identified the most recent version that you  
can find of this file and *also* the specific (immutable) version  
of this file that existed when I created this file-handle.



Also, am I correct in assuming that once write-caps have been  
distributed, they cannot be revoked, and a new file handle must be  
created?



Currently, yes.  An improvement that I would like to make in the next  
version of Tahoe-LAFS is to allow the holder of a write-cap to revoke  
it.  While some kinds of revocation are tantamount to DRM (Digital  
Restrictions Management) and seem to be sufficiently difficult that  
we're not even going to try to implement them, the specific kind of  
revocation that you asked about seems to be quite doable.  Also, it  
happens to be the kind of revocation that I have already wanted for  
my own personal use of Tahoe-LAFS (to host my blog).  :-)


Here is a letter about that which explains why I needed this and how  
I envision it working: [2]



Stronger defenses against rollback attack, and revocation of write- 
caps -- these are only a few of the many possible extensions to the  
Tahoe-LAFS secure storage design.  We have a rich library of such  
designs documented on our issue tracker and our wiki.  We are  
currently having a detailed design discussion on the tahoe-dev list  
to which several cryptographers are contributing [e.g. 3, 4].  The  
primary goal for the next version of Tahoe-LAFS caps is to reduce the  
size of the caps and improve performance, but we're also cataloguing  
new features such as these to see if we can work them in.  Here is  
the wiki page where we're keeping our notes: [5].


If any smart cryptographer or hacker reading this wants to create  
secure, decentralized storage, please join us!  We could use the  
help!  :-)


Regards,

Zooko

[1] http://allmydata.org/~zooko/lafs.pdf
[2] http://allmydata.org/pipermail/tahoe-dev/2009-June/001995.html
[3] http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html
[4] http://allmydata.org/pipermail/tahoe-dev/2009-September/002808.html
[5] http://allmydata.org/trac/tahoe/wiki/NewCapDesign

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Jerry Leichter

On Sep 7, 2009, at 8:58 AM, Jerry Leichter wrote:

...standard Mac OS GUI element to prompt for passwords ...
I should expand on that a bit:  This GUI element is used for all kinds  
of things tied to a window, not just passwords.  For example, if you  
try to close a window that contains stuff you haven't saved, the same  
element is used to ask you to confirm, save now, or cancel.  So it's a  
pretty familiar thing to Mac users

-- Jerry

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