RE: Crypto dongles to secure online transactions

2009-11-25 Thread Scott Guthery
The FINREAD smart card reader was a European run at moving trust-bearing
transactions to an outboard device. It was a full Java VM in a
tamper-resistant box with a modest GUI, biometrics, lots of security on the
I/O ports and much attention to application isolation. FINREAD readers were
produced and an attempt was made to make its specifications into an ISO/IEC
standard. I don't know why it didn't get any traction but suspect that it
was more on business grounds than on technical grounds.  Telling folks they
had to buy a $100 card reader that was controlled and monetized by one
particular bank wasn't exactly a compelling offer.  

Recently GlobalPlatform has reinvigorated the STIP reader effort which is
from 35K feet the same thing.  GP took over STIP in 2004.  Google or Bing
for details.

As Dan Geer as observed over the years, reducing bank risk is not a consumer
benefit.

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


RE: security questions

2008-08-07 Thread Scott Guthery
Another useful piece of research on the topic:

V. Griffith and M. Jakobsson.
Messin' with Texas, Deriving Mother's Maiden Names Using Public Records.
ACNS '05, 2005 and CryptoBytes Winter '07

http://www.informatics.indiana.edu/markus/papers.asp

Cheers, Scott

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: New result in predicate encryption: disjunction support

2008-05-05 Thread Scott Guthery
[Moderator's Note: Top posting is discouraged. --Perry]


What I meant was that the crypogram decrypted with a correct f(I)=1 key
yields the encrypted message Meet you at Starbucks at noon 0
whereas decryption with a wrong, f(I)=0, key yields Let's go down to Taco
Bell at midnight.  Padding with 0's doesn't help.

Cheers, Scott 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Katz
Sent: Sunday, May 04, 2008 1:20 PM
To: cryptography@metzdowd.com
Subject: RE: New result in predicate encryption: disjunction support

On Sun, 4 May 2008, Scott Guthery wrote:

 One useful application of the Katz/Sahai/Waters work is a counter to 
 traffic analysis.  One can send the same message to everyone but 
 ensure that only a defined subset can read the message by proper key 
 management.  What is less clear is how to ensure that decrytion with 
 the wrong key doesn't yield an understandable (and actionable) message.

This is actually pretty easy to do by, e.g., padding all valid messages with
sufficiently-many 0s. Decryption with an incorrect key will result in
something random that is unlikely to end with the requisite number of 0s
(and so will be discarded).
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Scott Guthery
 
 but also a proof that the source code one has is the source of the
implementation.

This is an unsolved problem for code in tamper-resistant devices.  There are
precious few procedures to, for example, determine that the CAC card that
was issued to Pfc. Sally Green this morning bears any relationship
whatsoever to the code that went through FIPS certification. (A hash of the
code is meaningless since the card will simply burp up the right answer.)  I
have seen one such procedure but I have never seen any such procedure
implemented in real cards.

And to Marcos' point, not only do certification labs not look for backdoors
but I once had an employee of such a lab tell me that even if they found one
the are not obliged to enter this in their report unless, of course, they
had been explicitly requested to test for the absence of backdoors.  In that
regard, I have never seen a security profile that contained a claim of no
backdoors.  And I guess you know who is paying big bucks for the
certification report. 

Smart cards from F.  TPMs from C.  A 'sleep at the wheel.

Cheers, Scott

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: New result in predicate encryption: disjunction support

2008-05-04 Thread Scott Guthery
A group member asked me to elaborate on:

 - No knowledge of which groups can be successfully authenticated is 
 known to the verifier

What this tries to say is that the verifier doesn't need to have a list of
all authenticable groups nor can the verifier draw any conclusions about
other authenticable groups based on authenticating one group.

One useful application of the Katz/Sahai/Waters work is a counter to traffic
analysis.  One can send the same message to everyone but ensure that only a
defined subset can read the message by proper key management.  What is less
clear is how to ensure that decrytion with the wrong key doesn't yield an
understandable (and actionable) message.

Cheers, Scott

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: New result in predicate encryption: disjunction support

2008-05-03 Thread Scott Guthery
Those interested in predicate encryption might also enjoy 

Group Authentication Using The Naccache-Stern Public-Key Cryptosystem 

http://arxiv.org/abs/cs/0307059

which takes a different approach and handles negation.

A group authentication protocol authenticates pre-defined groups of
individuals such that: 
- No individual is identified 
- No knowledge of which groups can be successfully authenticated is known to
the verifier 
- No sensitive data is exposed 
The paper presents a group authentication protocol based on splitting the
private keys of the Naccache-Stern public-key cryptosystem in such a way
that the Boolean expression defining the authenticable groups is implicit in
the split

Shamelessly, Scott

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: more on malicious hardware

2008-04-28 Thread Scott Guthery
 
Adding a backdoor to chips is a different story, though, since that would
require cutting a second set of masks. 
I am assuming that there must be no backdoor in the legitimately produced
chips since the client would detect 
it as a slight violation of some of their timing simulations. The client
also often inspects the masks before 
the chips are produced and basically reverse-engineers the whole chip on
that level.

A backdoor -- hardware or software -- in a smart card or TPM would be
difficult to detect by either of these means.  In the case that nation A is
buying these from nation F, don't you think that nation F would be motivated
to slip in a couple extra lines of code or a couple extra 100 gates just in
case?  If A got into a tangle with C, F would in a very strong position.  

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Is there any future for smartcards?

2005-09-11 Thread Scott Guthery
1) GSM/3G handsets are networked card readers that are pretty
successful.  They are I'd wager about as secure as an ATM or a POS,
particularly with respect to social attacks.

2) ISO is currently writing a standard for a secure home card reader.
The starting point is FINREAD. See JTC1/SC17/SG4/TF10.

Cheers, Scott




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: the limits of crypto and authentication

2005-07-11 Thread Scott Guthery
Amex Blue was a market success in the sense that its ROI exceeded
expectations, rational and otherwise.  It yielded thousands of new
accounts at a cost of acquisition far less than average, even when
taking into account the Windows driver support calls and the discarded
readers. That said, you might have been able to achieve the same result
with a gold stickie except the geeks that were the majority of the new
accounts probably would have peeled it off and grumped.

The winner will be the dude that can make authentication into a Mustang.
Like it or not, Amex Blue pointed the way.

IMHO as always.

Cheers, Scott

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Saturday, July 09, 2005 6:32 PM
To: cryptography@metzdowd.com
Subject: Re: the limits of crypto and authentication 


Nick Owen writes:
 | I think that the cost of two-factor authentication will plummet in
the  | face of the volumes offered by e-banking.

Would you or anyone here care to analyze what I am presuming is the
market failure of Amex Blue in the sense of its chipcard and reader
combo?

--dan


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Papers about Algorithm hiding ?

2005-05-31 Thread Scott Guthery
Isn't this what Rivest's Chaffing and Winnowing is all about?

http://theory.lcs.mit.edu/~rivest/chaffing.txt

Cheers, Scott

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hadmut Danisch
Sent: Thursday, May 26, 2005 5:51 PM
To: cryptography@metzdowd.com
Subject: Papers about Algorithm hiding ?

Hi,

you most probably have heard about the court case where the presence of
encryption software on a computer was viewed as evidence of criminal
intent.

http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.ht
m
http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-10
30_3-5718978.html



Plenty of research has been done about information hiding.
But this special court case requires algorithm hiding as a kind of
response. Do you know where to look for papers about this subject?

What about designing an algorithm good for encryption which someone can
not prove to be an encryption algorithm?


regards
Hadmut


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Choosing an implementation language

2003-10-03 Thread Scott Guthery
Ah, the joys of diversity.  Implementations
of all your favorite protocols in all your
favorite programming languages by all your
favorite programmers in all your favorite
countries on all your favorite operating
systems for all your favorite chips.  

Continuous debugging certainly is the path 
to secure computing.

Cheers, Scott

-Original Message-
From: Tyler Close [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 4:31 PM
To: [EMAIL PROTECTED]
Subject: Choosing an implementation language


On Thursday 02 October 2003 09:21, Jill Ramonsky wrote:
 I was thinking of doing a C++ implentation with classes and
 templates and stuff.  (By contrast OpenSSL is a C
 implementation). Anyone got any thoughts on that?

Given the nature of recent, and past, bugs discovered in the
OpenSSL implementation, it makes more sense to implement in a
memory-safe language, such as python, java or squeak. Using a VM
hosted language will limit the pool of possible users, but might
create a more loyal user base.

I know the squeak community http://www.squeak.org/ does not have
SSL and would very much like to have it. An implementation of SSL
in squeak would also be of interest to the Squeak-E project,
related to the E project http://www.erights.org/.

Tyler

-- 
The union of REST and capability-based security:
http://www.waterken.com/dev/Web/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: fyi: bear/enforcer open-source TCPA project

2003-09-11 Thread Scott Guthery
There are roughly 1B GSM/3GPP/3GPP2 
SIMs in daily use and the number of 
keys extracted from them is diminishingly 
small.

-Original Message-
From: bear [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 3:43 AM
To: Sean Smith
Cc: [EMAIL PROTECTED]
Subject: Re: fyi: bear/enforcer open-source TCPA project 




On Wed, 10 Sep 2003, Sean Smith wrote:


 So this doesn't
 work unless you put a speed limit on CPU's, and that's ridiculous.

Go read about the 4758.  CPU speed won't help unless
you can crack 2048-bit RSA, or figure out a way around
the physical security, or find a flaw in the application.

You propose to put a key into a physical device and give it
to the public, and expect that they will never recover
the key from it?  Seems unwise.

Bear

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]