Re: Do You Need a Digital ID?

2005-03-25 Thread Anne Lynn Wheeler
minor addenda ... ref:
http://www.garlic.com/~lynn/aadsm19.htm#1 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
there are 2nd order implementations of public/private key authentication 
business process where keeping the private key private might involve

* keeping the private key in an encrypted file and a pin/password is 
required to decrypt a file. this could be considered a possibly weak 
form of two-factor authentication: 1) possession of the encrypted file 
and 2) possession of the key to decrypt the file (it may in fact be 
considered so weak that many might considerd it only one-factor 
authentication, the knowledge of the key to decrypt the file).

* keeping the private key in a token ... where the characteristics of 
the private key and the token holding the private key are taken as 
equivalent. the simple token/private-key equivalence is then one-factor 
something you have authentication ... aka a) digital signature is an 
expression of access and use of the private key and b) access and use of 
the private key is an expression of the possession of the token.

* a private key token that requires PIN and/or biometrics to operate in 
specific manner ... a relying party with business process certification 
of the private key only existing in a specific token and that the 
specific token is also certified as to requiring specific PIN and/or 
biometrics then possibly the relying party can assume some form of two 
factor authentication (or even three factor authentication); the digital 
signature is an expression of the access and use of the private key, the 
access and use of the private is an expression of a combination of a) 
possession of a specific hardware token, b) corresponding PIN for that 
specific hardware token to operate in a specific manner and/or c) 
biometric for that specific hardware token to operate in a specific manner.

note in the old fashion identity digital certificates from the early 90s 
... there was frequently little or no discussion as to the integrity 
requirements regarding the ability to access and use a specific private 
key (which is what the whole private/public key business process is 
fundamentally built on). there was frequently lots of documentation on 
what a certification authority might do in the integrity around the 
generation of an identity digital certificate  but very little or 
nothing about what the key owner was required to do in order to enable 
the whole fundamental public/private key business process to operate 
correctly.

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


Re: Do You Need a Digital ID?

2005-03-25 Thread Anne Lynn Wheeler
now, i've said that all of these comments are within the 3 factor 
authentication paradigm ... if you back up a couple paragraphs in the 
original postings ... you will find the comments:

 given 3-factor authentication:

 * something you have
 * something you know
 * something you are
aka the comments/postings are within the framework/paradigm of 3-factor 
authentication. so is the issue with the 3-factor authentication 
framework ... or is the issue that the comments are inconsistent given a 
3-factor authentication framework?

I assert (as stated in the original posting) that the comments/posting 
is within the context of 3-factor authentication framework and the 
definition of the public/private key business process. you are free to 
define something other than 3-factor authentication framework  or a 
totally different business process for the treatment of asymmetric 
cryptography keys.

a digital signature is something that is supposedly hard to counterfeit 
 and just represents the application of a private key to some data
(the digital signature is an indication/expression that a private key 
has been accessed and used). for most entities, a private key is not 
something that is memorized, but rather it is contained by something 
that the human has. the integrity of the process is based on the 
integrity of the infrastructure that controls the access and use of that 
private key ... therefor a digital signature infrastructure typically 
represents a something you have technology.

the whole asymmetric cryptography technology (of which a digital 
signature is just a part) has been taken and a business process wrapped 
afound it which is frequently referred to as public/private key 
cryptography (an abbreviation frequently to simple public key 
technology). the foundation of the public/private key (or public key 
technology for short) business process is based on keeping the private 
key actually private. If everybody is allowed to have as free access 
to the private keys as there is access to the public key ... the 
whole infrastructure (including digital signatures) falls apart.

So if you are looking at a threat assessement ... the public/private key 
business process allows for both digital signatures and public keys to 
be readily known ... the whole foundation that holds the whole public 
key business process together is based on keeping the private key 
actually unknown and unaccessable to others than the authorized entities.

so i've haven't seen any private key deployments which are based on a 
human actually memorizing the private key ... so it can't be a (at least 
directly) a something you know operation. of the private key 
deployments i've seen, there has been the requirement that an entity 
possesses a private key and is able to access and make use of that 
private key ... since it isn't something you know (and since a 
private key is also not typically something you are biometrics) then 
that leaves a private key representing something you have.

so if you look at typical something you have infrastructures, their 
integrity is based on the protection of the operations that access and 
utilize the something you have.

as i pointed out in one of the earlier postings, much of the literature 
in the mid-90s grossly confused the the terms digital signature and 
digital certificates and private key ... to the point that it sometimes 
represented that a digital ceritifcate was responsible for generating a 
digital signature (or by implication the public key included in a 
digital certificate). Since the public/private key business process 
allows for both digital signatures and public keys to be readily known, 
it is fairly obvious that they can't be the integrity/security 
foundation for the business process.

so when a digital signature is validated with a public key ... what is 
it doing ... it is validating that the private key (of a public/private 
key pair from asymmetric cryptography) generated that digital signature.
private key isn't a characteristic of asymmetric cryptography ... it 
is a characteristic of public/private key business process requiring 
that the private key be kept private. a digital signature is just an 
expression of the business process use of that private key.

so from 3-factor authentication paradign there are three things:
* something you know authentication
* something you have authentication
* something you are authentciation
now, i know of no public/private key business process deployments that
require humans to memorize the private key ... that eliminates (at least
direct use of) something you know authentication.
the most common deployments of public/private key business process 
deployment aren't based on biometrics ... which then eliminates 
something you are authentication.

that just leaves private keys as a type of something you have 
technology ... (since it isn't memorized or biometrics). therefor the 
foundation of public/private key 

Re: Do You Need a Digital ID?

2005-03-25 Thread Jerrold Leichter
| now, i've said that all of these comments are within the 3 factor
| authentication paradigm ... if you back up a couple paragraphs in the
| original postings ... you will find the comments:
| 
|  given 3-factor authentication:
| 
|  * something you have
|  * something you know
|  * something you are
| 
| aka the comments/postings are within the framework/paradigm of 3-factor
| authentication. so is the issue with the 3-factor authentication framework
| ...  or is the issue that the comments are inconsistent given a 3-factor
| authentication framework?
I don't think the 3-factor authentication framework is nearly as well-defined
as people make it out to be.

Here is what I've always taken to be the core distinctions among the three
prongs:

Something you know
Can be copied.
If copied illicitly, you can't tell (except by noticing
illicit uses).

Something you have
Cannot be copied.
Can be transferred (i.e., you can give it to someone
else, but then you no longer have it)
Hence, if transferred illicitly, you can quickly detect it.

Something you are
Cannot be transferred.
Cannot be changed.
Inherently tied to your identity, not your role.

This classification, useful as it is, certainly doesn't cover the space of
possible authentication techniques.  For example, an RFID chip embedded under
the skin and designed to destroy itself if removed doesn't exactly match any
of these sets of properties:  It's not something you have because it can't
be transferred, but it's not something you are because it can be changed.
Attempting to force-fit everything into an incomplete model doesn't strike me
as a useful exercise.

| I assert (as stated in the original posting) that the comments/posting is
| within the context of 3-factor authentication framework and the definition of
| the public/private key business process. you are free to define something
| other than 3-factor authentication framework  or a totally different
| business process for the treatment of asymmetric cryptography keys.
| 
| a digital signature is something that is supposedly hard to counterfeit 
| and just represents the application of a private key to some data (the
| digital signature is an indication/expression that a private key has been
| accessed and used). for most entities, a private key is not something that
| is memorized, but rather it is contained by something that the human
| has. the integrity of the process is based on the integrity of the
| infrastructure that controls the access and use of that private key
| ... therefor a digital signature infrastructure typically represents a
| something you have technology.
Yes, this *entire system* - a private key embedded in a device that protects
the secret key embedded in it - is properly described as something you have.
But people use the phrase digital signature to describe other systems as
well.  The laws on acceptable digital signatures are broad enough to include
way more than this - in fact, way more than is really reasonable.  If my
secret key is stored en clair in a file on a general-purpose computer that
provides no protection against copying, it still acts in some ways like
something I have, but it lacks the cannot be copied attribute that seems
central to the notion.  On the other hand, if the secret key is stored in a
file encrypted using a pass phrase that I memorize, the entire system takes on
the security properties of something I know, even though it has a physical
embodiment.

| the whole asymmetric cryptography technology (of which a digital signature
| is just a part) has been taken and a business process wrapped afound it
| which is frequently referred to as public/private key cryptography (an
| abbreviation frequently to simple public key technology). the foundation of
| the public/private key (or public key technology for short) business process
| is based on keeping the private key actually private. If everybody is
| allowed to have as free access to the private keys as there is access to
| the public key ... the whole infrastructure (including digital signatures)
| falls apart.
| 
| So if you are looking at a threat assessement ... the public/private key
| business process allows for both digital signatures and public keys to be
| readily known ... the whole foundation that holds the whole public key
| business process together is based on keeping the private key actually
| unknown and unaccessable to others than the authorized entities.
| 
| so i've haven't seen any private key deployments which are based on a human
| actually memorizing the private key ... so it can't be a (at least directly)
| a something you know operation. of the private key deployments i've seen,
| there has been the requirement that an entity possesses a private key and
| is able to access 

Re: Do You Need a Digital ID?

2005-03-25 Thread Matt Crawford
Now that the taxing bodies (US  states) have learned not to print the 
SSN on the mailing label, Illinois has gone further and requires a 
state-assigned PIN to file or access your tax information over the 
internet.  They helpfully provide you the PIN ... on the mailing label.

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


Re: Do You Need a Digital ID?

2005-03-25 Thread Anne Lynn Wheeler
Jerrold Leichter wrote:
I don't think the 3-factor authentication framework is nearly as well-defined
as people make it out to be.
Here is what I've always taken to be the core distinctions among the three
prongs:
Something you know
Can be copied.
If copied illicitly, you can't tell (except by noticing
illicit uses).
Something you have
Cannot be copied.
Can be transferred (i.e., you can give it to someone
else, but then you no longer have it)
Hence, if transferred illicitly, you can quickly detect it.
Something you are
Cannot be transferred.
Cannot be changed.
Inherently tied to your identity, not your role.
This classification, useful as it is, certainly doesn't cover the space of
possible authentication techniques.  For example, an RFID chip embedded under
the skin and designed to destroy itself if removed doesn't exactly match any
of these sets of properties:  It's not something you have because it can't
be transferred, but it's not something you are because it can be changed.
Attempting to force-fit everything into an incomplete model doesn't strike me
as a useful exercise.
but business rules for public(/private) key infrastructure can describe 
that only the associated authenticating entity is the only one in 
possession of the private key (something you have)  as a way of 
relating the objective of having a specific entity's exclusive ability 
to access and utilize a private key to three factor authentication.

almost all of the existing something you have authentication objects 
are capable of being counterfeited to a greater or lesser degree. 
possibly the widest deployed something you have authentication objects 
are magstripe plastic cards ... and it turns out they have been proven 
to be remarkably easy to counterfeit/copied. the distinction between the 
ease or difficulty of counterfeiting/copying a magstripe plastic card 
vis-a-vis a private key ... depends on the level of security used to 
prevent it from being copied. obviously a private key can be copied with 
relative ease (possibly much easier than a magstripe plastic card).

in general, you will find that almost all something you have 
authentication objects are subject to being copied ... the issue is the 
degree to which security processes are in place to prevent them from 
being copied. just because a private key ... represented by some 
sequence of bits can be easily copied ... when no protections are in 
force ... doesn't mean that there can't be security procedures put into 
place that would make it extremely difficult to achieve copying of a 
private key.

most models serve a useful purpose until somebody comes up with a better 
or more applicable model.

many of the 3-factor authentication implementations actually use some 
representation that allows the actual occurence to be implied by 
something else.

for instance something you know authentication can be done as a 
shared-secret where both the originator and the relying party are both 
in possession of the shared-secret. an example are keys in symmetric key 
cryptography.

however, it is possible to have something you know authentication 
where the secret is not shared. For instance if there is a hardware 
token that is certified to only operate when the correct PIN has been 
entered  the PIN represents something you know authentication w/o 
having to share the secret with any other party (the relying party 
assumes that the correct PIN has been entered by a) being confident of 
the operation of the particular hardware token and b) the hardware
token having done something known  expected).

similarly, biometrics systems are frequently implemented as a form of 
shared-secret. an entity's biometric template is registered with some 
relying party  and subsequent transactions are authenticated by
checking a new biometric template with the biometric template on file.
the x9.84 biometric standard devotes a great deal to the security for 
centrally stored biometric templates  treating them as a greater 
security risk than traditional something you know shared-secrets. the 
threat is that somebody can obtain files of registered biometric 
templates and be able to subsequently retransmit them electronicly 
attempting to impersonate the associated person. The issue in the 
traditional 'something you know shared-secret is that a PIN compromise 
can be reported and a new, replacement PIN/password created.
However, it is somewhat more difficult to replace a thumb or iris when 
there has been a reported compromise of something you are shared secret.

in any case, for all of the deployed existing authentication systems 
involving any one of the three factor authentication paradigms, all of 
the methods are vulnerable to copying to one degree or another. as a 
result, I would 

Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Michael Silk
If it's just HMAC with K = h(m) then it's currently (or just recently)
been discussed on cfrg: http://www.irtf.org/cfrg/, starting here:
http://www1.ietf.org/mail-archive/web/cfrg/current/msg00708.html.

-- Michael


On Mon, 21 Mar 2005 11:56:44 +, Ben Laurie [EMAIL PROTECTED] wrote:
 It was suggested at the SAAG meeting at the Minneapolis IETF that a way
 to deal with weakness in hash functions was to create a new hash
 function from the old like so:
 
 H'(x)=Random || H(Random || x)
 
 However, this allows an attacker to play with Random (the advice I've
 seen is that if one is going to use an IV with a hash function, then one
 should transfer the IV with integrity checks to deny attackers this
 freedom).
 
 Another objection is that this construction changes the API at the
 sender end, which could lead to a great deal of complexity when the use
 of the hash API is deeply embedded.
 
 A third is that the length of the hash is changed, which could break
 existing protocols.
 
 Musing on these points, I wondered about the construction:
 
 H'(x)=H(H(x) || H(H(x) || x))
 
 which doesn't allow an attacker any choice, doesn't change APIs and
 doesn't change the length of the hash. Does this have any merit? Note
 that this is essentially an HMAC where the key is H(x). I omitted the
 padding because it seems to me that this actually makes HMAC weaker
 against the current attacks.
 
 Cheers,
 
 Ben.
 
 --
 http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
 
 There is no limit to what a man can do or how far he can go if he
 doesn't mind who gets the credit. - Robert Woodruff
 
 -
 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: how to phase in new hash algorithms?

2005-03-25 Thread Dan Kaminsky
Steven M. Bellovin wrote:

We all understand the need to move to better hash algorithms than SHA1. 
At a minimum, people should be switching to SHA256/384/512; arguably, 
Whirlpool is the right way to go.  The problem is how to get there from 
here.
  

I've been rather continually pinging people, asking them for an
explanation as to the design decisions of Whirlpool (namely -- it's
similar but noticably not identical to AES/Rijndael, and isn't just a
straightforward expansion of the block size up to 512 bits).  I'm not
saying anything bad about Whirlpool, but I get alot of people
approaching me about the hash and I don't really know what to tell them.

--Dan


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


Re: Security is the bits you disable before you ship

2005-03-25 Thread Jonathan Thornburg
On Wed, 16 Mar 2005, Russell Nelson wrote:
I've seen Dan Bernstein (and you don't get much
more careful or paranoid about security than Dan) write code like
this:
static char line[999];
 len = 0;
 len += fmt_ulong(line + len,rp);
 len += fmt_str(line + len, , );
 len += fmt_ulong(line + len,lp);
 len += fmt_str(line + len,\r\n);
Of course, the number of characters that fmt_ulong will insert is
limited by the number of bits in an unsigned long, and both strings
are of constant length.
Ick.  Why not the simpler/clearer (and hence safer -- complexity makes
it harder to find bugs of any sort, including security ones) snprintf()
call:
   #define N_LINE  999
   static char line[N_LINE];
   len = snprintf(line, N_LINE, %ul , %ul\r\n, rp, lp);
snprintf() first appeared in 4.4BSD and is now in C99, so any modern
system should support it by now.
ciao,
--
-- Jonathan Thornburg [EMAIL PROTECTED]
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html
   Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral.
  -- quote by Freire / poster by Oxfam
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Propping up SHA-1 (or MD5)

2005-03-25 Thread David Wagner
Ben Laurie writes:
It was suggested at the SAAG meeting at the Minneapolis IETF that a way 
to deal with weakness in hash functions was to create a new hash 
function from the old like so:

H'(x)=Random || H(Random || x)

Yes.  Suppose we use this for signing.  The crucial part is to have
the *signer* choose the Random value when computing the signature.
This may be secure even if H fails to be collision-resistant, because
even if an attacker finds a collision for H, he doesn't know which
Random value the signer is going to use.

More generally, we could try to use any universal one-way hash function
(UOWHF).  This concept is also known as target collision resistant (TCR).
It is natural to conjecture that H' is a UOWHF, i.e., is TCR, and this
may be true even if H is not collision-resistant.  Of course, there is
no proof of this, and this conjecture is speculative, but it does weaken
the assumptions we are making about our hash.

I have been advocating this kind of construction ever since hearing about
the hash cryptanalysis results last August.  Not everyone agrees with me,
and there is a lengthy discussion going on about this on the IRTF CFRG
working group.
  http://www1.ietf.org/mail-archive/web/cfrg/current/threads.html
  http://www1.ietf.org/mail-archive/web/cfrg/current/thrd2.html
  http://www1.ietf.org/mail-archive/web/cfrg/current/thrd3.html

However, this allows an attacker to play with Random (the advice I've 
seen is that if one is going to use an IV with a hash function, then one 
should transfer the IV with integrity checks to deny attackers this 
freedom).

No, not if you use it right.  The way to use this is to have the signer
choose the value of Random, not anyone else.  A signer can play with Random
and maybe find collisions M,M', but in this case the signer will be viewed
as having signed both M and M', so this doesn't help the signer at all.

Another objection is that this construction changes the API at the 
sender end, which could lead to a great deal of complexity when the use 
of the hash API is deeply embedded.

Shouldn't be a big deal for signing.  A much bigger deal is that this
changes the on-the-wire format.

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


Time for a second thought about SDLH

2005-03-25 Thread ralf


On Sun, 20 Mar 2005, Steven M. Bellovin wrote:

 Dominated?  No, of course not.  But a hash function based on discrete
 log will be slow enough that no one will use it.

This is simply not true, because we are _not always_ going to sign
megabytes, and SDLH is more than fast enough for sensibly crafted texts.
At the end of the day we might consider the option that we don't need
a single hash function for everything.

There is a place for a high end hash function.

I insist on a second thought.

Kind regards

Ralf Senderek


*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
* Ralf Senderek  [EMAIL PROTECTED] http://senderek.com*  What is privacy  *
* Sandstr. 60   D-41849 Wassenberg  +49 2432-3960   *  without  *
* PGP: AB 2C 85 AB DB D3 10 E7  CD A4 F8 AC 52 FC A9 ED *Pure Crypto?   *
49466008763407508762442876812634724277805553224967086648493733366295231438448

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


Re: how to phase in new hash algorithms?

2005-03-25 Thread Peter Gutmann
Steven M. Bellovin [EMAIL PROTECTED] writes:

We all understand the need to move to better hash algorithms than SHA1. At a 
minimum, people should be switching to SHA256/384/512; arguably, Whirlpool is 
the right way to go.  The problem is how to get there from here.

So -- what should we as a community be doing now?

Kick it upstairs to the political layer.  Someone else's problem, we've already
shown them what the solution is, our job is done.

Peter :-).

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


Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Dan Kaminsky wrote:
Ben,
x can equal either test vector released by Wang, and H(x) will be
identical.  With H(x) identical, the rest of the HMAC stays identical too. 
This does not appear to be correct - in my construction, i.e. without 
padding, then the fact that x and x' differ means that the first blocks 
are different, but not the colliding kind of different (since the first 
blocks will be 20 bytes of H(x) and blocksize-20 bytes of x or x' [or, 
to be pedantic, the first 20 bytes of the next block will be 
different]). Even if padding were included, x and x' would still not 
collide, because the chaining values would not be as needed at the start 
of the second block.

As a couple people pointed out, it's OK that HMAC is vulnerable to
the Wang attack, since in order to execute the attack the key is
required (and like AES, if the key is compromised, all bets are off). 
But you're not using HMAC as a MAC; you're using it to prop up a broken
hash. 

Regarding the Random appendage, people don't seem to realize how
important syncronized initial states are to many hashing algorithms. 
One of the major uses of a hashing algorithm is to act as an
*exchangable* handle to data, in other words, you and I can both hash
our respective datasets and see if they're identical.  If we're each
using different initial states, that process fails utterly.
Obviously. But I don't understand your point.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


FSTC-FS/ISAC Survey on Use of Encryption

2005-03-25 Thread R.A. Hettinga

--- begin forwarded text


From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: FSTC-FS/ISAC Survey on Use of Encryption
Date: Tue, 22 Mar 2005 05:16:10 -0600

Colleagues,

FSTC and FS/ISAC have teamed together to conduct a survey on the use of
encryption in the financial services sector. The survey is being sent to
member-FS/ISAC and FSTC institutions and industry technology providers. The
results of the survey will be combined and posted to the FSTC and FS/ISAC
sites for all members.

The purpose of this survey is to benchmark current security controls among
FSTC and FS/ISAC members. Your input is totally voluntary and will be
anonymous. All results must be posted by end-of-day Friday, March 25, 2005,
when the survey will close. Thank you for your participation.

Please contact me with any questions.

Here is a link to the survey:
http://www.surveymonkey.com/s.asp?A=67540432E27560

Regards,

Zach Tumin
Executive Director
FSTC


Please note: If you do not wish to receive further emails from us regarding
this survey, please click the link below, and you will be automatically
removed from the survey mailing list.
http://www.surveymonkey.com/r.asp?A=67540432E27560

--- end forwarded text


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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


DOT neg rulemaking re ID standardization (call for membership of advisory committee)

2005-03-25 Thread John Gilmore
[Here's where an unconstitutional National ID will get created by the
back door.  Do we have anybody in this community who cares?  I can't
participate, because I can't travel to Washington for meetings,
because I don't have the proper ID documents.  I note that they did
not think to include a representative of undocumented people...
  -- John]

[Federal Register: February 23, 2005 (Volume 70, Number 35)]
[Proposed Rules]
[Page 8756-8761]
 From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr23fe05-18]

===
---

DEPARTMENT OF TRANSPORTATION
Office of the Secretary
49 CFR Subtitle A

[Docket No. OST-2005-20434]


Driver's Licenses and Personal Identification Cards
AGENCY: Office of the Secretary (OST), DOT.
ACTION: Notice of intent to form a negotiated rulemaking advisory
committee.

---

SUMMARY: Pursuant to the portion of the Intelligence Reform and
Terrorism Prevention Act of 2004 known as the 9/11 Commission
Implementation Act of 2004, the Office of the Secretary, DOT, is
establishing a committee to develop, through negotiated rulemaking
procedures, recommendations for minimum standards to tighten the
security for driver's licenses and personal identification cards issued
by States, in order for these documents to qualify for use by Federal
agencies for identification purposes. The committee will consist of
persons who represent the interests affected by the proposed rule,
i.e., State offices that issue driver's licenses or personal
identification cards, elected State officials, the Departments of
Transportation and Homeland Security, and other interested parties. The
purpose of this document is to invite interested parties to submit
comments on the issues to be discussed and the interests and
organizations to be considered for representation on the committee.

DATES: You should submit your comments or applications for membership
or nominations for membership on the negotiated rulemaking committee
early enough to ensure that the Department's Docket Management System
(DMS) receives them not later than March 25, 2005. Late-filed comments
will be considered to the extent practicable.

ADDRESSES: You should mention the docket number of this document in
your comments or application/nomination for membership and submit them
in writing to: Docket Management System (DMS), Room PL-401, 400 Seventh
Street, SW., Washington, DC 20590. Commenters may also submit their
comments electronically. Instructions for electronic submission may be
found at the following Web address: http://dms.dot.gov/submit/.
 You may call the Docket at 202-366-9324, and visit it from 10 a.m.
to 5 p.m., Monday through Friday. Interested persons may view docketed
materials on the Internet at any time. Instructions for doing so are
found at the end of this notice.
 You may read the comments received by DMS at the address given
above under ADDRESSES. The hours of the Docket are indicated above in
the same location.
 You may also review all documents in the docket via the internet.
To read docket materials on the internet, take the following steps:
 1. Go to the DMS Web page of the Department of Transportation
(http://dms.dot.gov/).
 2. On that page, click on ``search.''
 3. On the next page (http://dms.dot.gov/search/), type in the four-
digit docket number shown at the beginning of this document. Example:
If the docket number were OST-2005-1234,'' you would type ``1234.''
After typing the docket number, click on ``search.''
 4. On the next page, which contains docket summary information for
the

[[Page 8757]]

docket you selected, click on the desired comments. You may download
the comments. The comments are word searchable.
 Please note that even after the comment closing date, we will
continue to file relevant information in the Docket as it becomes
available. Further, some people may submit late comments. Accordingly,
we recommend that you periodically check the Docket for new material.

FOR FURTHER INFORMATION CONTACT: Robert C. Ashby, Deputy Assistant
General Counsel for Regulation and Enforcement, Office of the General
Counsel, at 202-366-9310 ([EMAIL PROTECTED]), or Steve Wood, Assistant
Chief Counsel for Vehicle Safety Standards and Harmonization, Office of
the Chief Counsel, National Highway Traffic Safety Administration, 202-
366-2992 ([EMAIL PROTECTED]) Their mailing addresses are at the
Department of Transportation, 400 7th Street, SW., Washington, DC
20590, at rooms 10424 and 5219, respectively.

SUPPLEMENTARY INFORMATION:

I. Background

 On December 17, 2004, the President signed into law the
Intelligence Reform and Terrorism Prevention Act of 2004. (Public Law
No. 108-458). Title VII of that Act is known as the 9/11 Commission
Implementation Act of 2004 (the 

Re: [saag] Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Nicolas Williams wrote:
On Mon, Mar 21, 2005 at 11:56:44AM +, Ben Laurie wrote:
It was suggested at the SAAG meeting at the Minneapolis IETF that a way 
to deal with weakness in hash functions was to create a new hash 
function from the old like so:

H'(x)=Random || H(Random || x)

Eric proposed sending Random, Signature(H(Random || M)) and I then
proposed sending Random || Signature(H(Random || M)) to avoid having to
add a slot in existing protocols for Random.
Another alternative: send Random-Key || Signature(HMAC(H(), Random-Key, M).

However, this allows an attacker to play with Random (the advice I've 
seen is that if one is going to use an IV with a hash function, then one 
should transfer the IV with integrity checks to deny attackers this 
freedom).

This proposal is specific to the use of hashes in signatures.

Another objection is that this construction changes the API at the 
sender end, which could lead to a great deal of complexity when the use 
of the hash API is deeply embedded.

Yes.

A third is that the length of the hash is changed, which could break 
existing protocols.

Tie this to new algorithm OIDs and this problem goes away.  You still
have to figure out how to deploy new software.

Musing on these points, I wondered about the construction:
H'(x)=H(H(x) || H(H(x) || x))

Note that this is not on-line.

which doesn't allow an attacker any choice, doesn't change APIs and 
doesn't change the length of the hash. Does this have any merit? Note 
that this is essentially an HMAC where the key is H(x). I omitted the 
padding because it seems to me that this actually makes HMAC weaker 
against the current attacks.

Yes.
Now that we know that the attack is a differential cryptanalysis where
the attacker has to control the first pair of blocks of the original
message anything that makes it hard for the attacker to do this helps.
H'(x) = H(H(x))) might do that trick, and on-line, but surely there's
problems with that too (IANAC).
This construction cannot solve the problem since H(x)=H(x') = 
H(H(x))=H(H(x')).

Note that the attack implies that there exist weak messages, and Wang
et. al. explicitly mention this in the paper on breaking MD4, and they
mention the use of weak messages in second pre-image computation -- if a
given message begins with a weak block pair then you can construct
second pre-images.  It'd be nice to know what the weak message
distribution is for MD5 and SHA-1...
Wouldn't it?
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [saag] Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Ken Raeburn wrote:
On Mar 22, 2005, at 11:51, Ben Laurie wrote:
This can be fixed quite easily:
H'(x)=H(H(x || H(x)) || H(x))

Doesn't this take us back to the original problem, by factoring in x 
only at the start of hash computations, so H'(x') will generate the same 
H(x') and the same internal state for H(x'||...) as for H(x||...) and 
thus the same H(x'||H(x')) etc, resulting in the same final value?
Doh. Yes. Slightly less elegantly, then:
H'(x)=H(H(x || H(0 || x) || H(0 || x))
Then you need two hashes running in parallel, but at least it is still 
online. Or, with three parallel streams:

H'(x)=H(H(x || H(0 || x) || H(1 || x))
I don't feel as comfortable with either as the original construction, 
though.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [saag] Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Nicolas Williams wrote:
On Tue, Mar 22, 2005 at 05:31:44PM +, Ben Laurie wrote:
Nicolas Williams wrote:
Now that we know that the attack is a differential cryptanalysis where
the attacker has to control the first pair of blocks of the original
message anything that makes it hard for the attacker to do this helps.
H'(x) = H(H(x))) might do that trick, and on-line, but surely there's
problems with that too (IANAC).
This construction cannot solve the problem since H(x)=H(x') = 
H(H(x))=H(H(x')).

But it changes the attacker's problem.
Currently the attacker has to find a first block of a weak message, then
find the second block of the same, then he can generate collisions at
will.  The weak message generation requires some effort, and surely --
huge assumption here -- it takes more effort to find a weak message
whose hash is also a weak message.
The hash does not need to be weak, since the two hashes are the same, 
and so their hashes are also the same.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Encryption plugins for gaim

2005-03-25 Thread Michael P. Soulier
On 14/03/05 Adam Fields said:

 Given what may or may not be recent ToS changes to the AIM service,
 I've recently been looking into encryption plugins for gaim. 

If you use jabber, note that the Psi client supports 2-person PGP encrypted
conversations. I sometimes find it useful. 

http://psi.affinix.com/

Mike

-- 
Michael P. Soulier [EMAIL PROTECTED]
http://www.digitaltorque.ca
http://opag.ca  python -c 'import this'
Jabber: [EMAIL PROTECTED]


signature.asc
Description: Digital signature


What is to be said about pre-image resistance?

2005-03-25 Thread Ian G
Collision resistance of message digests is effected by the birthday
paradox, but that does not effect pre-image resistance.  (correct?)
So can we suggest that for pre-image resistance, the strength of
the SHA-1 algorithm may have been reduced from 160 to 149?  Or can
we make some statement like reduced by some number of bits that may
be related to 11?
Or is there no statement we can make?
iang
PS: There is a nice description (with a bad title) here for the
amateurs like myself:
http://www.k2crypt.com/sha1.html
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: NSA warned Bush it needed to monitor networks

2005-03-25 Thread John Kelsey
...
Obviously any bureaucrat with the authority to categorize
something as secret will more or less automatically so stamp
any information that passes through his hands, to inflate his
importance, and thus his job security and prospects for
promotion.  

I think a bigger issue here is a sort of rational (to the bureaucrat) risk 
aversity: if he declassifies something and it turns out he's leaked something 
valuable (in the eyes of his boss), he's in trouble.  As long as there's no 
cost to stamping secret or FOUO on every document his office produces, this 
is safer for him than any other course of action.   Along with this, going 
through a document to make sure there's nothing secret in there is a lot more 
work than just classifying it.  The same logic works in the private world--how 
much of the stuff you've seen under NDA was genuinely going to cause a problem 
to the company that produced it, if someone just posted it to their website?

...
This results in top secret information being treated as not
very secret at all, as documented by Richard Feynman, which in
turn results in ever higher secrecy classifications, more top
than top, a process of classification inflation and debasement. 

I suspect something very similar happens with the watchlists.  I wonder how 
many different layers of watchlist there are by now

--digsig
 James A. Donald

--John Kelsey

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


Re: Do You Need a Digital ID?

2005-03-25 Thread Anne Lynn Wheeler
Jerrold Leichter wrote:
That's fine for *describing* the system, and useful for analyzing its usability
or acceptability.  But it's not the whole story.
3-factor authentication paradigm obviously doesn't take into account 
whether the authentication material is treated as a secret or a 
shared-secret i.e. both biometrics and something you know can be 
implemented as either secret or shared-secret  shared-secret 
tends to have copies of the authentication material in the possession of 
the relying party ... while secret tends to be an infrastructure where 
the relying-party can infer the existance of the secret by other 
characteristics. it is one of the reasons that the x9.84 biometric 
standard goes to great deal of description when biometrics are 
implemented as shared-secrets ... with the biometric templates stored 
at a central site.

3-factor authentication paradigm obviously also doesn't cover whether 
the authentication is direct fact-to-face or that the relying party is 
infering authentication taking place by the existance of other kinds of 
evidence. for instance, a relying party validating a digital signature 
with a public key will infer that the other party is in possession of 
the corresponding private key. the relying party may not have direct 
knowledge of the other party being in possession of the corresponding 
private key ... the relying party just infers it from the validation of 
a digital signature with the public key.

which then takes us back to your original response:
 This is a rather bizarre way of defining things.  Something you have
 is a physical object.  On the one hand, any physical object can
 be copied to an arbitrary degree of precision; on the other hand,
 no two physical objects are *identical*.  So a distinction based
 on whether a replacement is identical to the original gets
 you nowhere.
ref:
http://www.garlic.com/~lynn/aadsm19.htm#2 Do you Need a Digital ID?
or
http://www.mail-archive.com/cryptography%40metzdowd.com/msg03734.html
3-factor authentication paradigm obviously also doesn't cover all the 
sort of business rules that allow a relying party to infer something to 
be true ... even when they don't have direct evidence that it is true
aka for a public/private key infrastructure where the relying party
normally is inferring that the private key owner has in fact attempted 
to consistantly and reliably maintained the confidentiality and privacy 
of the private key and therefor its usefullness as part of any 3-factor 
authentication paradigm.

3-factor authentication paradigm might also help people designing and/or 
analysing authentication infrastructures. something you know 
operations may be some what more vulnerable to electronic sniffing, 
phishing, and/or  information harvesting attacks. something you have 
hopefully are more resistant to electronic sniffing, phishing, and/or 
information harvesting attacks ... although the transmission of static 
data in non-face-to-face operations that allow the relying party to 
infer the possession of the something you have has been shown to be 
extremely vulnerable to skimming attacks (that enable the manufactor of 
counterfeit magstripe plastic cards). Obviously sniffing and skimming 
exploits involve very similar threat model.

One application would be to choose a multi-factor authentication 
implementation where the different factors represent countermeasure to 
different threats. A multi-factor authentication implementation, where 
the different factors are vulnerable to the same threats, doesn't 
provide a great deal of additional security. However, there are 
obviously a lot of variouscharactistics like

* face-to-face or non-face-to-face
* direct evidence or inferring based on other evidence
* static or non-static data
* central store or remote inferrance
* treat models
* represents what kind of countermeasures
* resistance to counterfeiting/impersonation
* human factors
a difficult human factors has been the issue of something you know 
shared-secrets. shared-secret pin/passwords have had two kinds of 
guidelines 1) make it hard to guess (which tends to make it difficult to 
memorize) 2) different shared-secret for every security domain (where 
most institutions viewed that they were the only security domain, but in 
reality many people now are faced with scores of different security 
domains with scores of extremely difficult to remember shared-secrets).

lots of past posts on threats, vulnerabilities, exploits
http://www.garlic.com/~lynn/subpubkey.html#fraud
and lots of 3-factor authentication posts:
http://www.garlic.com/~lynn/subpubkey.html#3factor
and various past posts on general subject of designing high-assurance
systems
http://www.garlic.com/~lynn/subpubkey.html#assurance
we have somewhat viewed assurance and high-availability as similar ... 
where a system needs to be resistant to all kinds of failures ... 
regardless of whether they were failures due to attacks/exploits or just 
plain simple 

Re: Do You Need a Digital ID?

2005-03-25 Thread Anne Lynn Wheeler
Anne  Lynn Wheeler wrote:
3-factor authentication paradigm obviously also doesn't cover whether 
the authentication is direct fact-to-face or that the relying party is 
infering authentication taking place by the existance of other kinds of 
evidence. for instance, a relying party validating a digital signature 
with a public key will infer that the other party is in possession of 
the corresponding private key. the relying party may not have direct 
i.e.
http://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID?
one of the possible side-effects of applying 3-factor authentication 
paradigm ... and observing that

1) the verification of a digital signature is just a method
of inferring the possession of a specific private key
2) the possession of a private key obviously (theoritically possible, 
but i know of not instances of people memorizing private keys) isn't 
something you know authentication and a private key isn't something 
you are authentication ... leaving it to be something you have 
authentication (aka in your possession)

3) private keys in their simplest form are just electronic bits that are 
relatively easy to copy

then in order for a private key to be useful in a something you have 
authentication, it follows fairly staight-forwardly that significant 
security procedures and countermeasures are required to prevent such 
copying (in order to provide some level of assurance that the assumed 
entity is consistantly and uniquely in possession of the specific 
private key).

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


RE: Propping up SHA-1 (or MD5)

2005-03-25 Thread Charlie Kaufman
All hash functions I'm aware of consist of an inner compression function
that hashes a fixed size block of data into a smaller fixed size block
and an outer composition function that applies the inner function
iteratively to the variable length data to be hashed. Essentially you're
proposing a modification to the outer layer of the hash construction.

All of the standard hash functions since MD4 have been constructed so
that a collision in the inner compression function is likely to lead to
a collision in the hash function. MD2 did not have that property. It
computed a cheap checksum of the variable length data in parallel with
the digesting process and digested the checksum following the data. I
have often wondered whether such a cheap addition would strengthen the
newer hashes. (It would fix the suffixing attacks that motivated the
development of HMAC).

It's not obvious whether this would make the functions more secure or
just make them harder to analyze. Perhaps someone from the research
community could comment on why the checksum was removed in the evolution
from MD2 to MD4.

Your proposed encoding has the disadvantage that it would require two
passes over the message being digested. This would be bad news for
hardware implementations and should be avoided if possible.

You note with the construction:

H'(x)=Random || H(Random || x)

(reminiscent of the salted hash calculation for UNIX passwords) that the
hash gets longer. The hash need not get longer. If you have 40 random
bits and the first 120 bits of H(Random || x), you match the size of
SHA-1 and get improved security against most practical attacks. If your
system depends on a fixed length hash, you're in trouble already because
the fixed length is probably 128 bits and the world is headed toward
256.

A problem that does exist with this construction is that some uses of
hash functions assume that if you hash the same data you get the same
hash (or indirectly, that if you sign the same data you get the same
signature). In particular, you now need separate functions for
generating a hash and for checking one.

--Charlie Kaufman

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie
Sent: Monday, March 21, 2005 3:57 AM
To: Cryptography; [EMAIL PROTECTED]
Subject: Propping up SHA-1 (or MD5)

It was suggested at the SAAG meeting at the Minneapolis IETF that a way 
to deal with weakness in hash functions was to create a new hash 
function from the old like so:

H'(x)=Random || H(Random || x)

However, this allows an attacker to play with Random (the advice I've 
seen is that if one is going to use an IV with a hash function, then one

should transfer the IV with integrity checks to deny attackers this 
freedom).

Another objection is that this construction changes the API at the 
sender end, which could lead to a great deal of complexity when the use 
of the hash API is deeply embedded.

A third is that the length of the hash is changed, which could break 
existing protocols.

Musing on these points, I wondered about the construction:

H'(x)=H(H(x) || H(H(x) || x))

which doesn't allow an attacker any choice, doesn't change APIs and 
doesn't change the length of the hash. Does this have any merit? Note 
that this is essentially an HMAC where the key is H(x). I omitted the 
padding because it seems to me that this actually makes HMAC weaker 
against the current attacks.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
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: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Charlie Kaufman wrote:
All hash functions I'm aware of consist of an inner compression function
that hashes a fixed size block of data into a smaller fixed size block
and an outer composition function that applies the inner function
iteratively to the variable length data to be hashed. Essentially you're
proposing a modification to the outer layer of the hash construction.
All of the standard hash functions since MD4 have been constructed so
that a collision in the inner compression function is likely to lead to
a collision in the hash function. MD2 did not have that property. It
computed a cheap checksum of the variable length data in parallel with
the digesting process and digested the checksum following the data. I
have often wondered whether such a cheap addition would strengthen the
newer hashes. (It would fix the suffixing attacks that motivated the
development of HMAC).
It's not obvious whether this would make the functions more secure or
just make them harder to analyze. Perhaps someone from the research
community could comment on why the checksum was removed in the evolution
from MD2 to MD4.
Your proposed encoding has the disadvantage that it would require two
passes over the message being digested. This would be bad news for
hardware implementations and should be avoided if possible.
I suggested in a later version these two constructions:
H'(x)=H(H(x || H(0 || x) || H(0 || x))
or:
H'(x)=H(H(x || H(0 || x) || H(1 || x))
which only require a single pass (but, unfortunately, two or three 
different instances of the hash). This seems similar to the mechanism 
used in MD2, except the checksum is expensive.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


REMINDER: CFP - ESORICS 2005: Deadline extension (April 1)

2005-03-25 Thread R.A. Hettinga

--- begin forwarded text


From: Claudio Agostino Ardagna [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Thu, 24 Mar 2005 12:24:21 +0100
Subject: [p2p-hackers] REMINDER: CFP - ESORICS 2005: Deadline extension
(April 1)
Reply-To: Peer-to-peer development. [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]

[Apologies if you receive multiple copies of this message]

CALL FOR PAPERS
ESORICS 2005
10TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY
Milan, Italy - September 14-16, 2005

http://esorics05.dti.unimi.it/http://esorics05.dti.unimi.it/



Due to several requests the deadline is extended to April 1, 2005 (firm)



Papers offering novel research contributions in any aspect of computer
security are solicited for submission to the Tenth European Symposium
on Research in Computer Security (ESORICS 2005). Organized in a series
of European countries, ESORICS is confirmed as the European research
event in computer security. The symposium started in 1990 and has been
held on alternate years in different European countries and attracts
an international audience from both the academic and industrial
communities. From 2002 it has been held yearly. The Symposium has
established itself as one of the premiere, international gatherings on
information assurance. Papers may present theory, technique,
applications, or practical experience on topics including:

- access control   
- accountability   
- anonymity
- applied cryptography 
- authentication   
- covert channels  
- cryptographic protocols  
- cybercrime   
- data and application security
- data integrity   
- denial of service attacks 
- dependability
- digital right managament 
- firewalls  
- formal methods in security   
- identity management  
- inference control
- information dissemination control
- information flow control 
- information warfare 
- intellectual property protection   
- intrusion tolerance 
- language-based security
- network security
- non-interference
- peer-to-peer security
- privacy-enhancing technology
- pseudonymity
- secure electronic commerce
- security administration
- security as quality of service
- security evaluation
- security management
- security models
- security requirements engineering
- security verification
- smartcards
- steganography
- subliminal channels
- survivability
- system security
- transaction management
- trust models and trust management policies
- trustworthy user devices

The primary focus is on high-quality original unpublished research,
case studies and implementation experiences. We encourage submissions
of papers discussing industrial research and development. Proceedings
will be published by Springer-Verlag in the Lecture Notes in Computer
Science series. 


INSTRUCTIONS FOR PAPER SUBMISSIONS
Submitted papers must not substantially overlap papers that have been
published or that are simultaneously submitted to a journal or a
conference with proceedings. Papers should be at most 15 pages
excluding the bibliography and well-marked appendices (using 11-point
font), and at most 20 pages total. Committee members are not required
to read the appendices, and so the paper should be intelligible
without them.

To submit a paper, send to
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] a plain ASCII text
email containing the title and abstract of your paper, the authors'
names, email and postal addresses, phone and fax numbers, and
identification of the contact author. To the same message, attach
your submission (as a MIME attachment) in PDF or portable postscript
format. Do NOT send files formatted for word processing packages
(e.g., Microsoft Word or WordPerfect files). Submissions not meeting
these guidelines risk rejection without consideration of their merits.

Submissions must be received by March 25, 2005 in order to be
considered. Notification of acceptance or rejection will be sent to
authors by May 30, 2005. Authors of accepted papers must be prepared
to sign a copyright statement and must guarantee that their paper
will be presented at the conference. Authors of accepted papers must
follow the Springer Information for Authors' guidelines for the
preparation of the manuscript and use the templates provided there. 


GENERAL CHAIR
Pierangela Samarati
University of Milan
email: mailto:[EMAIL PROTECTED][EMAIL PROTECTED]


PROGRAM CHAIRS
Sabrina De Capitani di Vimercati
University of Milan   
email: mailto:[EMAIL PROTECTED][EMAIL PROTECTED]  

Paul Syverson
Naval Research Laboratory
url: http://www.syverson.orgwww.syverson.org


PUBLICATION CHAIR
Dieter Gollman
TU 

DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service

2005-03-25 Thread Linda Casals

*
 
DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service 
  
  April 14 - 15, 2005
  DIMACS Center, Rutgers University, Piscataway, NJ

Organizers: 
   Drew Dean, SRI International, [EMAIL PROTECTED]  
   Markus Jakobsson, Indiana University, [EMAIL PROTECTED] 
 
Presented under the auspices of the Special Focus on Communication
Security and Information Privacy and is sponsored by RSA Security. 


This workshop is focusing on Theft in E-Commerce (of content, identity
and service). While theft is an old problem, the automated nature of
e-commerce introduces new opportunities for traditional forms of
theft, as well as entirely new forms of theft. The centrality of
computation makes these threats a part of computer security. This is
an area of research where we are seeing a lot of activity, and where
we believe there is a great potential for valuable research
contributions. While our primary interest is in defenses against
theft, we are also interested in novel attacks and real data about
attacks, as the defenders need to know what to defend against. It is
our hope that we could stimulate such research by bringing together
the leaders in this area, which is the very intention of this
workshop.

**
Workshop Program:
This is a preliminary program subject to change.

Thursday, April 14, 2005

 8:00 -  8:30 Registration and Breakfast

 8:30 -  8:45 Welcome and Opening Comments
  Fred Roberts, DIMACS Director

 8:45 -  9:45 Identity Theft: A Risk to Be Managed
  Richard A Parry, Consumer Risk Management, JPMorganChase

 9:45 - 10:15 Identity Theft and Legitimately - Minted Fraudulent Credentials
  Paul Van Oorschot, Carleton University, Canada

10:15 - 10:30 Break

10:30 - 11:15 Some are not thieves!
  Alexandr Andoni, MIT

11:00 - 11:30 Using Mutual Authentication to Fight Phishing
  Steve Myers, IUB

11:30 - 12:00 Building a Cryptovirus Using Microsoft's Cryptographic API
  Adam L: Young, LECG, LLC

12:00 -  1:30 Break

 1:30 -  2:00 An open - source USB token
  Hein Roehrig, University of Calgary

 2:00 -  2:30 Passwords Don't Get No Respect - - Or, How to Make the
  Most of (Weak) Shared Secrets
  Burt Kaliski, RSA Security 

 2:30 -  3:00 Blocking Phishing Spam: Pitfalls and Future Directions
  Minaxi Gupta, IUB  
 
 3:00 -  3:15 Break

 3:15 -  3:45 Phishing Countermeasures
  Aaron Emigh, Radix Labs

 3:45 -  4:15 Messin' with Texas: Deriving Mother's Maiden Names 
  Using Public Records
  Virgil Griffith, IUB 

Friday, April 15, 2005
 
 8:00 -  8:30 Breakfast and Registration

 8:30 -  9:15 Identity Theft: Methods and Prevention
  John Black, University of Colorado

 9:00 -  9:30 Preventing Theft in the Open
  Naftaly Minsky, Rutgers University

 9:30 - 10:15 Expressing Human Trust in Distributed Systems: the
  Mismatch Between Tools and Reality
  Sean Smith, Dartmouth College

10:00 - 10:15 Break

10:15 - 10:45 Separable Identity - Based Ring Signatures: Theoretical
  Foundations for Fighting Phishing Attacks
  Susan Hohenberger, MIT

10:45 - 11:15 Fighting Phishing Attacks: A Lightweight Trust
  Architecture for Detecting Spoofed Emails
  Ben Adida, MIT

11:15 - 11:45 How to Search Privately on Streaming Data
  Rafail Ostrovsky, UCLA

11:45 - 12:15 Distributed Phishing Attacks
  Markus Jakobsson, IUB, CACR

12:15 -  1:45 Lunch

 1:45 -  2:15 Are Peripheral Security Indicators Effective to 
  Prevent Phishing Attacks? 
  Min Wu, MIT

 2:15 -  2:45 Kleptography: The Outsider Inside Your Crypto Devices, 
  and its Trust Implications
  Moti Yung, Columbia University

 2:45 -  3:15 Safeguarding wireless service access
  Panos Papadimitratos,  Virginia Tech

 3:15 -  3:30 Break

 3:30 -  4:00 Social Networks and Trust Networks
  Jean Camp, IUB
 
 4:00 -  4:30 Fraud and Fraud Reduction on the Internet
  Bezalel Gavish, Southern Methodist University


**
Registration:

Pre-registration deadline: April 7, 2005

Please see website for registration information

  http://dimacs.rutgers.edu/Workshops/Intellectual/

*
Information on participation, registration, accomodations, and travel 
can be found at:

http://dimacs.rutgers.edu/Workshops/Intellectual/

   **PLEASE BE SURE TO PRE-REGISTER EARLY**






Re: [saag] Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Blumenthal, Uri wrote:
 Ernie Brickell suggested the following construct:
H'(x) = H( H(x) || H(0 || x) )
Like him, I see no reason in going (H(x) || H(0||x) || ... || H(n||x)).
Sorry, I got my parentheses wrong. I meant...
H'(x)=H(H(x || H(0 || x)) || H(0 || x))
or:
H'(x)=H(H(x || H(0 || x)) || H(1 || x))
the former being almost the same construction as suggested, except that 
H(0 || x) is appended to the first inner hash. I used this construction 
because nested keyed hashes have provable security properties (which is 
why HMAC is made the way it is). The second form is the one required to 
get those properties, I should point out.

I will confess that I have punted on whether those properties are 
actually useful.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Propping up SHA-1 (or MD5)

2005-03-25 Thread Charlie Kaufman
Whether these various tricks help depends on the technical details of
the attacks found. I hope that the bit twiddling crypto types who are
finding the attacks are going to propose something to fix them.

There are probably cheaper fixes than the 2x or 3x performance loss of
your algorithm down in the inner loops of these algorithms (such as the
change from SHA to SHA-1) and that these will come out. I'm reluctant to
jump on the SHA-256 bandwagon or to come up with some ad hoc fix until a
more thorough analysis is done. SHA-256 was designed before these
attacks were known and probably has related flaws (though they are even
less likely to be practically exploitable). We have the luxury of having
the current break being largely theoretical, so waiting even a year for
the mathematicians is probably OK. But it's never too early to start
preparing for a new algorithm - perhaps with a new hash size - in our
protocols. Further, given that lots of attacks (past and present) are
not exploitable if every hashed quantity includes some value chosen by a
trusted party and unpredictable by an attacker, it seems reasonable to
consider that as a desirable characteristic as we design our protocols.

--Charlie Kaufman

p.s. Your formulae below have unbalanced parentheses, but I can guess
what you probably meant.

-Original Message-
From: Ben Laurie [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 24, 2005 2:39 AM
To: Charlie Kaufman
Cc: Cryptography; [EMAIL PROTECTED]
Subject: Re: Propping up SHA-1 (or MD5)

Charlie Kaufman wrote:
 All hash functions I'm aware of consist of an inner compression
function
 that hashes a fixed size block of data into a smaller fixed size block
 and an outer composition function that applies the inner function
 iteratively to the variable length data to be hashed. Essentially
you're
 proposing a modification to the outer layer of the hash construction.
 
 All of the standard hash functions since MD4 have been constructed so
 that a collision in the inner compression function is likely to lead
to
 a collision in the hash function. MD2 did not have that property. It
 computed a cheap checksum of the variable length data in parallel with
 the digesting process and digested the checksum following the data. I
 have often wondered whether such a cheap addition would strengthen the
 newer hashes. (It would fix the suffixing attacks that motivated the
 development of HMAC).
 
 It's not obvious whether this would make the functions more secure or
 just make them harder to analyze. Perhaps someone from the research
 community could comment on why the checksum was removed in the
evolution
 from MD2 to MD4.
 
 Your proposed encoding has the disadvantage that it would require two
 passes over the message being digested. This would be bad news for
 hardware implementations and should be avoided if possible.

I suggested in a later version these two constructions:

H'(x)=H(H(x || H(0 || x) || H(0 || x))

or:

H'(x)=H(H(x || H(0 || x) || H(1 || x))

which only require a single pass (but, unfortunately, two or three 
different instances of the hash). This seems similar to the mechanism 
used in MD2, except the checksum is expensive.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

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


Petname Tool version 0.5

2005-03-25 Thread Bill Frantz
Tyler Close has written an anti-phishing tool for the Firefox browser called 
the Petname tool.  It works with SSL sites, including those with self-signed 
certificates, and is available at http://www.waterken.com/user/PetnameTool/.

Mark Stiegler has written an overview of petname systems, including a list of 
existing examples, available at: 
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html.  Note that Amir 
Herzberg and Ahmad Gbara's Trustbar system is an example of a pet name system.

From the Petname Tool web site, Need help avoiding phishing and spoofing 
attacks? The petname tool can help you keep it all straight by clearly 
distinguishing your online relationships.

Using the petname tool, you can save a reminder note about a relationship you 
have with a site. The petname tool will then automatically display this 
reminder note every time you visit the site. After following a hyperlink, you 
need only check that the expected reminder note is being displayed. If so, you 
can be sure you are using the same site you have in the past.

Cheers - Bill

-
Bill Frantz| The first thing you need   | Periwinkle 
(408)356-8506  | when using a perimeter | 16345 Englewood Ave
www.pwpconsult.com | defense is a perimeter.| Los Gatos, CA 95032

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


Banks and Online Retailers Lose Customers to the Fear of ID Theft

2005-03-25 Thread R.A. Hettinga
http://online.wsj.com/article_print/0,,SB63038793988394,00.html

The Wall Street Journal


 March 24, 2005

 PERSONAL JOURNAL


Banks and Online Retailers Lose
 Customers to the Fear of ID Theft

By KATHY CHU
DOW JONES NEWSWIRES
March 24, 2005; Page D2


Banks and online retailers are losing customers who fear they will become
victims of identity theft, according to a new study.

The study, conducted by Financial Insights, of Framingham, Mass., said that
nearly 6% of consumers have changed banks and about 18% have stopped
shopping online due to concerns that their personal information will be
stolen. This means that, overall, about 12 million U.S. consumers have
likely switched banks and 39 million have ceased online shopping, according
to Financial Insights.

The results come in the wake of high-profile database breaches where
consumer information was lost or stolen. The survey was actually conducted
before these incidents occurred, so it's likely that banks are at risk of
losing even more customers now, according to Sophie Louvel, a Financial
Insights analyst.

It's not just the banks that have experienced data compromises that need to
worry. Consumers may also leave if they perceive that banks don't have
adequate security systems or if data breaches have occurred at partner
institutions, according to the research firm.

This clearly shows that customers are taking action, said Ms. Louvel, who
has written an identity-theft report based on the data. I think the
fundamental issue is that some customers don't have confidence in their
bank's ability to protect them.

Separate research conducted last year by Unisys Corp. revealed that nearly
half of consumers would be willing to switch their accounts to financial
institutions they perceived as having stronger theft detection and alert
services.

To the extent that consumers think of their personal information as
property and assets, banks need to think this way, too, said Frank Liddy,
a partner at Unisys in Blue Bell, Pa.

John Hall, a spokesman at the American Bankers Association, said banks take
the threat of security breaches very seriously. Institutions already have
tough security standards in place for online banking and debit-card usage
and will continue doing everything they can to prevent identity theft, Mr.
Hall said.


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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


Off-list request

2005-03-25 Thread Lance James
I don't know if it's inappropriate to ask on this list, but regarding 
http://www.securescience.net/ciphers/csc2/

Can I get off-list quotes regarding a formal professional review and 
possible assistance in the steps taken to establish this cipher into the 
review process.

Thank you.
--
Best Regards,
Lance James
Secure Science Corporation
[Have Phishers stolen your customers' logins? Find out with DIA]
https://slam.securescience.com/signup.cgi - it's free!
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


and constrained subordinate CA costs? (Re: SSL Cert prices ($10 to $1500, you choose!))

2005-03-25 Thread Adam Back
The URL John forwarded gives survey of prices for regular certs and
subdomain wildcard certs/super certs (ie *.mydomain.com all considered
valid with respect to a single cert).

Does anyone have info on the cost of sub-ordinate CA cert with a name
space constraint (limited to issue certs on domains which are
sub-domains of a your choice... ie only valid to issue certs on
sub-domains of foo.com).

Maybe the answer is a lot of money... CA operators probably view
users of this kind of tech to be corporations with big infrastructure
to secure.  It sounds like the http://www.thawte.com/spki/ offers this
kind of service.  However it sounds like its web based so they have
really just bundled a more streamlined way to create lots of certs.

(Thawte spki means starter PKI (not simple pki)).

Adam

On Fri, Mar 04, 2005 at 03:53:51PM -0800, John Gilmore wrote:
 For the privilege of being able to communicate securely using SSL and a
 popular web browser, you can pay anything from $10 to $1500.  Clif
 Cox researched cert prices from various vendors:
 
   http://neo.opn.org/~clif/SSL_CA_Notes.html

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


RE: Propping up SHA-1 (or MD5)

2005-03-25 Thread Pablo Abad
Ben,

 I believe the fatal flaw here is not the crypto, but losing the ability
 to hash a stream without keeping all of it.  Both the hashes and HMAC
 have this sometimes-vital property.

This can be fixed quite easily:

H'(x)=H(H(x || H(x)) || H(x))

I think this construction doesn't provide any additional security. If
someone manages to find x1 and x2 such that H(x1)=H(x2), he will have also
broken H'(X).

If you get h=H(x1)=H(x2) (of course we are talking about hash functions
using the same iterative model as SHA-1), then you would end calculating
H(H(x1 || h) || h) vs H(H(x2 || h) || h), but since both x1 and x2 leave the
internal state of the hash function the same, H(x1 || h) = H(x2 || h) and
hence H'(x1) = H'(x2)

Cheers,
Pablo


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


Re: Secure Science issues preview of their upcoming block cipher

2005-03-25 Thread Adam Shostack
Really?  How does one go about proving the security of a block cipher?

My understanding is that you, and others, perform attacks against it,
and see how it holds up.  Many of the very best minds out there
attacked AES, so for your new CS2 cipher to be provably just as
secure as AES-128, all those people would have had to have spent as
much time and energy as they did on AES.  That strikes me as unlikely,
there's a lot more interest in hash functions today.

Adam

PS: I've added the cryptography mail list to this.  Some of the folks
over there may be interested in your claims.

On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote:
| Secure Science is offering a preview of one of the 3 ciphers they will 
| be publishing througout the year. The CS2-128 cipher is a 128-bit block 
| cipher with a 128 bit key. This cipher is proposed as an alternative 
| hardware-based cipher to AES, being that it is more efficient in 
| hardware, simpler to implement, and provably just as secure as AES-128.
| 
| http://www.securescience.net/ciphers/csc2/
| 
| -- 
| Best Regards,
| Secure Science Corporation
| [Have Phishers stolen your customers' logins? Find out with DIA]
| https://slam.securescience.com/signup.cgi - it's free!
| 

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


Re: Secure Science issues preview of their upcoming block cipher

2005-03-25 Thread Lance James
Adam Shostack wrote:
Really?  How does one go about proving the security of a block cipher?
My understanding is that you, and others, perform attacks against it,
and see how it holds up.  Many of the very best minds out there
attacked AES, so for your new CS2 cipher to be provably just as
secure as AES-128, all those people would have had to have spent as
much time and energy as they did on AES.  That strikes me as unlikely,
there's a lot more interest in hash functions today.
We will be proposing 2 hashes as well.
Adam
PS: I've added the cryptography mail list to this.  Some of the folks
over there may be interested in your claims.
On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote:
| Secure Science is offering a preview of one of the 3 ciphers they will 
| be publishing througout the year. The CS2-128 cipher is a 128-bit block 
| cipher with a 128 bit key. This cipher is proposed as an alternative 
| hardware-based cipher to AES, being that it is more efficient in 
| hardware, simpler to implement, and provably just as secure as AES-128.
| 
| http://www.securescience.net/ciphers/csc2/
| 
| -- 
| Best Regards,
| Secure Science Corporation
| [Have Phishers stolen your customers' logins? Find out with DIA]
| https://slam.securescience.com/signup.cgi - it's free!
| 



--
Best Regards,
Lance James
Secure Science Corporation
[Have Phishers stolen your customers' logins? Find out with DIA]
https://slam.securescience.com/signup.cgi - it's free!
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Information Incognito

2005-03-25 Thread R.A. Hettinga
http://online.wsj.com/article_print/0,,SB45546123985866,00.html

The Wall Street Journal


 March 22, 2005

 MEDIA  MARKETING


Information Incognito
In War on Terror, U.S. Tries
 To Make Public Data Secret;
 The Almanac Under Wraps?

By ROBERT BLOCK
Staff Reporter of THE WALL STREET JOURNAL
March 22, 2005; Page B1


Ever since Sept. 11, 2001, the federal government has advised airplane
pilots against flying near 100 nuclear power plants around the country or
they will be forced down by fighter jets. But pilots say there's a hitch in
the instructions: aviation security officials refuse to disclose the
precise location of the plants because they consider that SSI --
Sensitive Security Information.

The message is; 'please don't fly there, but we can't tell you where there
is,'  says Melissa Rudinger of the Aircraft Owners and Pilots Association,
a trade group representing 60% of American pilots.

Determined to find a way out of the Catch-22, the pilots' group sat down
with a commercial mapping company, and in a matter of days plotted the
exact geographical locations of the plants from data found on the Internet
and in libraries. It made the information available to its 400,000 members
on its Web site -- until officials from the Transportation Security
Administration asked them to take the information down. Their concern was
that [terrorists] mining the Internet could use it, Ms. Rudinger says.

The pilots' experience underscores one of the great policy clashes of the
early 21st century: the War on Terror vs. the Information Age. In the 31Ž2
years since al Qaeda operatives studied commercial airlines schedules in
preparation for flying jetliners into the World Trade Center and the
Pentagon, the Bush administration has moved aggressively to keep
once-easily accessible data under wraps. Some of that information could
well be of use to would-be terrorists, but keeping other information secret
strikes some observers as absurd.

For example, when a top Federal Aviation Administration official testified
last year before the 9/11 commission, his remarks were broadcast live
nationally. But when the administration included a transcript in a recent
report on threats to commercial airliners, the testimony was heavily
edited. How do you redact something that is part of the public record?
asked Rep. Carolyn Maloney, (D., N.Y.) at a recent hearing on the problems
of government overclassification. Among the specific words blacked out were
the seemingly innocuous phrase: we are hearing this, this, this, this and
this.

Government officials could not explain why the words were withheld, other
than to note that they were designated SSI.

The concept of Sensitive Security Information originated in a 1974
statute, which kept things like airport security plans out of public view.
But the Homeland Security Act of 2002 greatly expanded the scope of SSI to
include any data that could help someone defeat transportation security
systems, including records of security inspections, work schedules,
training materials and the regulations authorizing screeners to poke around
in carry-on baggage.

SSI is actually one of some 60 categories of SBU, or Sensitive But
Unclassified information, a designation reserved for information that
isn't top-secret, but which the government still doesn't want released
publicly. Other pseudo-classifications, as they're called by Congress and
some experts, include FOUO (For Official Use Only) and UCNI (Unclassified
Controlled Nuclear Information). Every government agency has the ability to
create its own form of SBU and any official can declare something
sensitive. Under such labels, officials have ordered a wide range of
information removed from public libraries and Web sites.

Critics say there are signs that these designations are now being overused.
One internal memo to Federal Air Marshals in Las Vegas last year stamped
FOUO announced a farewell breakfast party for a colleague and invited
co-workers for doughnuts and coffee.

So has the Pentagon's city-size phone directory, which was once on sale at
the U.S. government printing office, and is no longer offered to the
public. It contains information about the specific locations of DoD
officials, and other personnel, within the Pentagon, says spokesman Lt.
Col. Gary L. Keck.

Many officials involved in the new secrecy effort say such measures are
vital to national security -- and that just because information has
appeared in the public domain, doesn't mean it should be made more readily
available. We don't want to disclose vulnerabilities of the nation to our
adversaries, says Jack Johnson Jr., the former chief security officer for
the Department of Homeland Security, who until last month oversaw the
process of deciding what information was suitable for public consumption
and what was too risky to let out.

Some of the information that Mr. Johnson has deemed worthy of lock down
included the fact that Casio brand wrist watches are popular with al 

Re: Secure Science issues preview of their upcoming block cipher

2005-03-25 Thread Jerrold Leichter
| Really?  How does one go about proving the security of a block cipher?
They don't claim that:

This cipher is ... provably just as secure as AES-128.

I can come up with a cipher provably just as secure as AES-128 very quickly

(Actually, based on the paper a while back on many alternative ways to
formulate AES - it had a catchy title something like How Many Ways Can You
Spell AES?, except that I can't find one like that now - one could even
come up with a formulation that is (a) probably as secure as AES-128; (b)
actually faster in hardware or simpler to implement or whatever...)

-- Jerry :-) 

| My understanding is that you, and others, perform attacks against it,
| and see how it holds up.  Many of the very best minds out there
| attacked AES, so for your new CS2 cipher to be provably just as
| secure as AES-128, all those people would have had to have spent as
| much time and energy as they did on AES.  That strikes me as unlikely,
| there's a lot more interest in hash functions today.
| 
| Adam
| 
| PS: I've added the cryptography mail list to this.  Some of the folks
| over there may be interested in your claims.
| 
| On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote:
| | Secure Science is offering a preview of one of the 3 ciphers they will 
| | be publishing througout the year. The CS2-128 cipher is a 128-bit block 
| | cipher with a 128 bit key. This cipher is proposed as an alternative 
| | hardware-based cipher to AES, being that it is more efficient in 
| | hardware, simpler to implement, and provably just as secure as AES-128.
| | 
| | http://www.securescience.net/ciphers/csc2/
| | 
| | -- 
| | Best Regards,
| | Secure Science Corporation
| | [Have Phishers stolen your customers' logins? Find out with DIA]
| | https://slam.securescience.com/signup.cgi - it's free!
| | 
| 
| -
| The Cryptography Mailing List
| Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
| 

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


What is to be said about pre-image resistance?

2005-03-25 Thread David Wagner
Ian G writes:
Collision resistance of message digests is effected by the birthday
paradox, but that does not effect pre-image resistance.  (correct?)

So can we suggest that for pre-image resistance, the strength of
the SHA-1 algorithm may have been reduced from 160 to 149?

Well, I'm not sure that the difference between 2^160 and 2^149
would be very significant in practice, even if there were some
redunction like this, but--

As far as I can tell, the pre-image resistance of SHA1 has not been
significantly threatened by these attacks, or at least, the authors
do not claim any results on pre-image resistance of SHA1.

http://www1.ietf.org/mail-archive/web/cfrg/current/msg00790.html

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


Secure Science issues preview of their upcoming block cipher

2005-03-25 Thread David Wagner
Jerrold Leichter writes:
They don't claim that:

   This cipher is ... provably just as secure as AES-128.

I can come up with a cipher provably just as secure as AES-128 very quickly

Actually, I think Adam is totally right.

Have you looked at their scheme?
  http://www.securescience.net/ciphers/csc2/
The way to come up with a cipher provably as secure as AES-128 is to use
AES-128 as part of your cipher -- but their scheme does not do anything
like that.

I am very skeptical about claims that they have a mathematical proof that
CS2-128 is as secure as AES-128.  I want to see the proof.

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


Re: Secure Science issues preview of their upcoming block cipher

2005-03-25 Thread Jerrold Leichter
| Jerrold Leichter writes:
| They don't claim that:
| 
|  This cipher is ... provably just as secure as AES-128.
| 
| I can come up with a cipher provably just as secure as AES-128 very 
quickly
| 
| Actually, I think Adam is totally right.
| 
| Have you looked at their scheme?
|   http://www.securescience.net/ciphers/csc2/
I was responding in jest to the text Adam actually quoted - and indeed was
refering to:

| The way to come up with a cipher provably as secure as AES-128 is to use
| AES-128 as part of your cipher 
[Remind self once more:  Ironic humor doesn't work in mail]

|-- but their scheme does not do anything
| like that.
| 
| I am very skeptical about claims that they have a mathematical proof that
| CS2-128 is as secure as AES-128.  I want to see the proof.
I didn't see that claim on their site, but then again I only glanced at it
quickly.  Unless they have some entirely new kind of reduction, I'm guessing
that what they are really claiming is that the same proofs of security that
are available for AES - against generalized differential attacks, for example -
are also available for CSC2.  *That* much is certainly possible.

-- Jerry

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


Re: Secure Science issues preview of their upcoming block cipher

2005-03-25 Thread Ralf-Philipp Weinmann
Jerrold Leichter wrote:
I can come up with a cipher provably just as secure as AES-128 very quickly
(Actually, based on the paper a while back on many alternative ways to
formulate AES - it had a catchy title something like How Many Ways Can You
Spell AES?, except that I can't find one like that now - one could even
come up with a formulation that is (a) probably as secure as AES-128; (b)
actually faster in hardware or simpler to implement or whatever...)
You're probably looking for [1] by Barkan and Biham. What they do is 
replacing the irreducible polynomial and all the constants involved in 
Rijndael to get what they call dual ciphers; basically those ciphers 
are isomorphic to Rijndael. All in all they get 240 dual ciphers which 
are listed in [2]. What I found more interesting back then was that they 
also give square dual and log dual ciphers of Rijndael. I.e. let E be 
the Rijndael encryption and E' be the encryption function of the 
square/log dual Rijndael construction. Furthermore let f be a function 
that either performs bytewise squaring in GF(2^8) or replaces each byte 
with a logarithmic representation (relative to a generator g. you also 
need to fix log_g(0) = -\infty for this to make sense). Then

 E'(f(plaintext), f(key)) = f(E(plaintext, key))
holds. The squaring construction then also naturally extends to what 
they call higher-order self dual ciphers: meaning you can apply the 
squaring multiple times.

In 2004 Wu, Lu and Laih then demonstrated that using Barkan's and 
Biham's method can indeed lead to more efficient implementations of 
AES/Rijndael in hardware.

Cheers,
Ralf
[1] Elad Barkan and Eli Biham:
In How Many Ways Can You Write Rijndael?
ASIACRYPT 2002, Springer
note: also on ePrint as http://eprint.iacr.org/2002/157
if you don't have Springer Link access
[2] Elad Barkan and Eli Biham:
The Book of Rijndaels
http://eprint.iacr.org/2002/158
[3] Shee-Yau Wu and Shih-Chuan Lu and Chi Sung Laih:
Design of AES Based on Dual Cipher and Composite Field
Topics in Cryptology, CT-RSA 2004, Springer
--
Ralf-P. Weinmann [EMAIL PROTECTED]
TU Darmstadt, FB Informatik, FG Theoretische Informatik
Tel: +49-(0)6151-16-6628
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: and constrained subordinate CA costs?

2005-03-25 Thread Florian Weimer
* Adam Back:

 Does anyone have info on the cost of sub-ordinate CA cert with a name
 space constraint (limited to issue certs on domains which are
 sub-domains of a your choice... ie only valid to issue certs on
 sub-domains of foo.com).

Is there a technical option to enforce such a policy on subordinated
CAs?

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


Re: What is to be said about pre-image resistance?

2005-03-25 Thread Dan Kaminsky
Ian,

The Wang attack does nothing (yet) for second preimages.

The best attack I know of against them refers is in Kelsey and
Schneier's *Second Preimages on n-bit Hash Functions for Much Less than
2^n Work.*  It's at:  http://eprint.iacr.org/2004/304

Once you cut through the verbiage, it's really pretty simple:  The
bigger a file, the more intermediate hashes there are inside of it.  The
more intermediate hashes, the more points there are to collide against. 
So, a 700MB CD image vs. a hash with a 512 bit blocksize will have
734,003,200 bytes / 64 bytes = 11,468,800 intermediate hashes that may
be collided against.  That's a little more than 2^23.  Against MD5,
you're looking at 2^105 for a CD; against SHA-1, you're looking at
2^137.  This is of course work that's far outside the range of
feasibility (and, in a small ahem to the paper, 2^60 byte messages are
equally ridiculous).

You may say this isn't a true second preimage attack, because you
only acquire an intermediate collision.  But all intermediate collisions
can be appended to with legitimate data until they return to the correct
final hash state.  So you generate your malicious data, search for
random garbage that, when appended, equals one of the 11M potential
states, and then append the rest of the legitimate file from that point.

MD Hardening, i.e. the conclusion of a data stream with its own
length, *does* create a problem though.  We cannot alter the final
length of the file, or the hash will fail.  So if we find an
intermediate collision at an earlier point in the file than our
malicious payload requires, we must discard it.  For large malicious
payloads (say, replacing one CD entirely with another), this eliminates
our attack window entirely.

Of course, again, 2^105 work is ridiculous.

--Dan


Ian G wrote:


 Collision resistance of message digests is effected by the birthday
 paradox, but that does not effect pre-image resistance.  (correct?)

 So can we suggest that for pre-image resistance, the strength of
 the SHA-1 algorithm may have been reduced from 160 to 149?  Or can
 we make some statement like reduced by some number of bits that may
 be related to 11?

 Or is there no statement we can make?

 iang

 PS: There is a nice description (with a bad title) here for the
 amateurs like myself:

 http://www.k2crypt.com/sha1.html



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