NSA posts notice about faster, lighter crypto

[Anne & Lynn Wheeler]

NSA posts notice about faster, lighter crypto
http://www.fcw.com/article91669-12-09-05-Web

The National Security Agency wants federal agencies to consider using a
group of algorithms it refers to as Suite B to satisfy future
cryptographic requirements. Suite B contains NSA-approved cryptographic
algorithms of various key sizes to protect classified and unclassified
but sensitive information. NSA has posted a notice about Suite B on its
Web site.

... snip ..

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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[Anne & Lynn Wheeler]

Ed Gerck wrote:
> I think that's where PKI got it wrong in several parts and not
> just the CPS. It started with the simplest (because it was meant to
> work for a global RA -- remember X.500?) and then complexity was
> added. Today, in the most recent PKIX dialogues, even RFC authors
> often disagree on what is meant in the RFCs. Not to mention the
> readers.

the baseline analysis, threat/vulnerability models, etc ... start with
the simplest and then build the incremental pieces  frequently
looking at justification for the additional complexity.

when doing the original design and architecture you frequently start
with the overall objective and do a comprehensive design (to try and
avoid having things fall thru the cracks).

i would contend that the issue with PKI isn't as much that they started
with simple and then did incremental piece-meal design (rather than
complete, comprehensive design) ... but they actually did design
something for a specific purpose ... and subsequently it was frequently
tried to force-fit it for purposes for which it wasn't originally
designed for.

for example the traditional business model tends to have relying parties
contracting directly with the parties they rely on (and there is
contractual obligation between the two parties). the evolution of the
trusted third party certification authority model violates most standard
business practices that have grown up over hundreds of years.

the trusted third party certification authority is selling digital
certificates to key owners for the benefit of relying parties. there is
a large disconnect where the parties that are supposedly going to rely
on and benefit from the digital certificates aren't the ones contracting
for the digital certificates. this disconnect from standard business
practices can be considered the motivating factor for the invention of
CPS ... even tho there may not be a direct business and contractual
relationship between the relying parties and the certification
authorities ... a CPS tries to fabricate a sense of comfort for the
relying parties. A contractual relationship would otherwise provide for
this sense of trust... the relying party pays the certification
authority for something, and the certification authority then has some
obligation to provide something in return to the relying party.
In most trusted third party certification authority operations there is
no legal, business or otherwise binding relationship between the
relying party and the TTP/CA ... it is between the key owner and the TTP/CA.

This could be further aggravated by RFC authors who possibly have no
familiarity with standard business practices and attempt to write
something just because they want it to be that way.

Another example could be considered OCSP. Basically digital certificates
are stale, static, r/o, armored copies of some information located
someplace. A business process model has relying parties, relying on the
information in stale, static, r/o copies of the information because they
have no means for directly accessing the real, original information
(basically the letters of credit/introduction from sailing ship days ...
aka offline with no local resources). OCSP provides for a online
transaction which asks whether the stale, staic information is still
usuable, attempting to preserve the facade that digital certificates
serve some useful purpose when there is online, direct access
capability. The alternative is to eliminate the digital certificates all
together and rather than doing an OCSP transaction, do a direct, online
transaction.

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

[Clips] MIT Real ID Conference a Success: Participate in New Virtual Civic Conversation

[R. A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Sat, 10 Dec 2005 17:48:40 -0500
 To: "Philodox Clips List" <[EMAIL PROTECTED]>
 From: "R. A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] MIT Real ID Conference a Success: Participate in New Virtual
  Civic Conversation
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]


 --- begin forwarded text


  Date: Sat, 10 Dec 2005 13:01:20 -0800 (PST)
  From: "Daniel J. Greenwood" <[EMAIL PROTECTED]>
  Reply-To: [EMAIL PROTECTED]
  Subject: MIT Real ID Conference a Success: Participate in New Virtual
 Civic Conversation
  To: [EMAIL PROTECTED]

  This note is to inform you that the MIT Public Forum
  on the Real ID Act of 2005 was held on Monday,
  December 5th and we will be streaming video of the
  entire day from the MIT Media Lab web site within the
  next few days.  To those of you who participated,
  thank you for making this event a true success.

  We plan a series of activities for the future,
  including publication of proceedings, further activity
  on the MIT Real ID Public Forum Blog, additional
  events and of course continued work with the
  Department of Homeland Security and other federal and
  state governmental agencies to provide a neutral forum
  within which to meet, hear from the public and
  interest groups and to consider opportunities for
  cross boundary cooperation.

  We intend to use publication of the final report of
  the proceedings of the day to highlight the many
  valuable perspectives and ideas that came forward
  throughout the event.  Again, we encourage each of you
  to share any thoughts you may have regarding this
  important new federal statute.  After the Department
  of Homeland Security published their draft regulations
  under the law, we anticipate another round of activity
  to support discussion and meaningful response.

  Finally, the MIT E-Commerce Architecture Program,
  hosted at the MIT Media Lab Smart Cities group, is now
  working with partners to make available a new more
  efficient mode of public dialog on important affairs
  of the day.  Currently called “Virtual Civic
  Conversations”, this simple approach uses existing
  blog technology (including RSS feeds and track-back
  features), to set up shared meta-search terms for
  specific issues, allowing participants to post a topic
  on their blog and for it to appear as a new post on a
  large-scale multi-party communications blog.  In this
  way, the many interest groups, governmental agencies,
  individuals and others who are all speaking to the
  same topic (next steps on the Real ID Act, in this
  case), can use a blog (such as the MIT Real ID Public
  Forum Blog) to compile all posts on all blogs related
  to that topic.  In addition, it is possible for
  participants to respond to the posts across threads,
  blogs and topics, thereby creating a bounded but very
  open knowledge zone on that issue.  We are setting up
  a Virtual Civic Conversation for the Real ID Act this
  weekend and early next week.  Stay tuned for more
  information on exactly how to participate and to
  encourage others with relevant blogs to participate.

  MIT is pleased to use new technology and our capacity
  to convene to serve the civic interest.  Thank you for
  your interest.

  Regards,
   - Dan Greenwood

  
  Daniel J. Greenwood, Esq.
  Lecturer, Massachusetts Institute of Technology
  The Media Lab, Program of Media Arts and Science
  Principal, CIVICS.com  The InfoSociety Consultancy
  http://ecitizen.mit.edu & http://civics.com
  1770 Mass. Ave, #205, Cambridge, MA 02140  USA
  M: 857-498-0962
  E: [EMAIL PROTECTED]
  

 --- end forwarded text


 --
 -
 R. A. Hettinga 
 The Internet Bearer Underwriting Corporation 
 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'
 ___
 Clips mailing list
 [EMAIL PROTECTED]
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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]

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[Ed Gerck]

Anne & Lynn Wheeler wrote:

OCSP provides for a online
transaction which asks whether the stale, staic information is still
usuable, attempting to preserve the facade that digital certificates
serve some useful purpose when there is online, direct access
capability. The alternative is to eliminate the digital certificates all
together and rather than doing an OCSP transaction, do a direct, online
transaction.


The benefits of not always requiring direct online transactions has been
pointed out before in this thread, in terms of anonymity, availability and
reliability. What happens when you get a message and the direct, online
connection isn't there? You can' decrypt it even though it you need to?

Digital certs (X.509 and PGP) are useful when the key owner is not online.
There is a world when this not only happens but is also useful. BTW, this
is recognized in IBE as well.

A couple additional comments:

> the baseline analysis, threat/vulnerability models, etc ... start with
> the simplest and then build the incremental pieces  frequently
> looking at justification for the additional complexity.
>
> when doing the original design and architecture you frequently start
> with the overall objective and do a comprehensive design (to try and
> avoid having things fall thru the cracks).

Agreed, and that's where a baseline analysis really fails to reveal a
design's pros and cons -- because it follows a different path. Seems
logical but denies the design's own logic (which did NOT use a baseline
approach to begin with, on purpose).

Therefore, when I look into X.509 / PKI issues, or secure email issues,
a baseline analysis is not so very useful.

> the trusted third party certification authority is selling digital
> certificates to key owners for the benefit of relying parties.

The RPs are not part of the contract. Without CAs, there's no "key
owner" in PKI. It's for the benefit (and reduction of liability)
of the key owners.

Cheers,
Ed Gerck

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

[Clips] Pentagon Intelligence Agency Gathers Domestic Intelligence

[R. A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Sat, 10 Dec 2005 20:51:58 -0500
 To: Philodox Clips List <[EMAIL PROTECTED]>
 From: "R. A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] Pentagon Intelligence Agency Gathers Domestic Intelligence
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]

 

 The Drudge Report


 Support The DrudgeReport; Visit Our Advertisers



  Pentagon Intelligence Agency Gathers Domestic Intelligence
  Sat Dec 10 2005 18:20:11 ET

  Day after day, reports of suspicious activity filed from military bases
 and other defense installations throughout the United States flow into the
 Counterintelligence Field Activity, or CIFA, a three-year-old Pentagon
 agency whose size and budget remain classified, the WASHINGTON POST is
 planning to report on Sunday, newsroom sources tell DRUDGE.

  The Talon reports, as they are called, are based on information from
 civilians and military personnel who stumble across people or information
 they think might be part of a terrorist plot or threat against defense
 facilities at home or abroad.

  It is unclear how many Talon reports are filed each year. But just one of
 the military services involved in the program, the Air Force, generated
 1,200 of them during 14 months, the paper reveals.

  The documents can consist of ``raw information reported by concerned
 citizens and military members regarding suspicious incidents,'' said a 2003
 memo signed by then-Deputy Defense Secretary Paul Wolfowitz. The reports
 ``may or may not be related to an actual threat, and its very nature may be
 fragmented and incomplete,'' the memo said.

  The Talon system is part of the Defense Department's growing effort to
 gather intelligence within the United States, which officials argue is
 imperative as they work to detect and prevent potentially catastrophic
 terrorist assaults. The Talon reports _ how many are generated is
 classified, a Pentagon spokesman said _ are collected and analyzed by CIFA,
 an agency at the forefront of the Pentagon's counterterrorism program.

  The Pentagon's emphasis on domestic intelligence has raised concerns among
 some civil liberties advocates and intelligence officials.

  Developing...


 --
 -
 R. A. Hettinga 
 The Internet Bearer Underwriting Corporation 
 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'
 ___
 Clips mailing list
 [EMAIL PROTECTED]
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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]

Re: [Clips] Engineer Outwits Fingerprint Recognition Devices with Play-Doh

[Travis H.]

A recent magazine article suggested a spoofing technique involving
wrapping one's finger with a few layers of cellophane; the latent
print on the reader apparently is visible enough to be reused in this
manner, at least with some currently-available scanners.
--
http://www.lightconsulting.com/~travis/  -><- Knight of the Lambda Calculus
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[Ralf Senderek]

On Fri, 9 Dec 2005, Ed Gerck wrote:

> [...]  at least the grand
> picture should exist beforehand. This is what this thread's subject
> paper is about, the grand picture for secure email and why aren't
> we there yet (Phil's PGP is almost 15 years old) -- what's missing.
> 

and Bill Stewart wrote:

> Popularity of a product is critical to its security;
> you don't gain anonymity if the Feds can recognize that
> you're one of the dozen users of a given application.
> Your mom can use Skype, but nobody she knows uses Crypto Kong,
> and I only know a few people who use PGP to email their mom.
> But some of the Instant Messaging systems use crypto;
> too bad that they're continually trying to be incompatible
> with each other to gain market share.

I think what's missing is the understanding that there cannot be
secure email without the persons involved acting responsible and 
knowing their role in the process.
Your mother will probably expect the computer to do the job for her
(mine will never expect anything from computers) rejecting any
responsibility for her email's security. In my opinion establishing
secure email this way is impossible despite the fact that encryption is
(relatively) easy if our algorithms work as expected and you have the
correct high-quality public key.
And even if Instant Messaging systems would use the same crypto people
will use them like cell phones without any consciousness of their own
responsibility for key validation. Getting good crypto into mass products
can help but does not eliminate the necessity for checking essential properties
of the system they use.
How we can make this job as reliable as possible is the question at the heart
of the problem.


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: X.509 / PKI, PGP, and IBE Secure Email Technologies

[James A. Donald]

--
James A. Donald wrote:
> > However, the main point of attack is phishing, when
> > an outsider attempts to interpose himself, the man
> > in the middle, into an existing relationship between
> > two people that know and trust each other.

Anne & Lynn Wheeler <[EMAIL PROTECTED]>
> in the traditional, ongoing relationship scenario,
> relying parties directly record authentication
> information of the parties they are dealing with. if a
> relying party were to directly record the public key
> of the people they are communicating with ... it is
> the trusting of that public key and the validating of
> associated public key operations that provide for the
> countermeasure for man-in-the-middle attacks and
> phishing attacks.

This was the scenario envisaged when PKI was created,
but I don't see it happening, and in fact attempting to
do so using existing user interfaces is painful.  They
don't seem designed to do this.

My product, Crypto Kong, http://echeque.com/Kong was
designed to directly support this scenario in a more
convenient fashion - it keeps a database of past
communications and their associated keys, but there did
not seem to be a lot of interest.   I could have made it
more useful, given it more capabilities, but I felt I
was missing the point 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 4ostZwIWJbNX6/eRYYX4QMLG5GGNUaPJao5ZKKGB
 4Bt20kCp2fkd6wgjBDjYMz5ZqUEnTYL4O3aTalDOB



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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[Anne & Lynn Wheeler]

James A. Donald wrote:
> This was the scenario envisaged when PKI was created,
> but I don't see it happening, and in fact attempting to
> do so using existing user interfaces is painful.  They
> don't seem designed to do this.
> 
> My product, Crypto Kong, http://echeque.com/Kong was
> designed to directly support this scenario in a more
> convenient fashion - it keeps a database of past
> communications and their associated keys, but there did
> not seem to be a lot of interest.   I could have made it
> more useful, given it more capabilities, but I felt I
> was missing the point 

i've seen some discussions that were either/or regarding pki & pgp;
aka pki advocates attempting to position pki as a OR to pgp. the issue
is that both pki and pgp require a local trusted public key repository
as the basis for establishing trust.

pki then layers on it, these certification authority business processes,
specialized digitally signed messages called digital certificates, etc
to address first time communication between strangers where the relying
parties have no other resources for determining information about the
sender in an offline environment. they then advocate that all
(personally) digitally signed operations are required to have attached
x.509 identity digital certificates that has been digitally signed by a
certification authority.

we saw some of that when we did work on the cal. state & fed. electronic
signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

one possible interpretation might be that it would have increased the
revenue stream for the certification authority industry.

drastically improving the useability of the interface to the trusted
public key repositories could be viewed as having two downsides 1)
certification authorities that haven't payed to have their public keys
preloaded can more easily join the club, 2) the pgp-like scenario
becames much easier, potentially drastically reducing existing reliance
on the digital-certificate-only (and certification authority only
business process) digital-signed-operation model.

part of the problem with the trusted third party certification authority
 model is that its primary benefit in the case of first time
communication betweeen two strangers ... where the relying party has no
other recourse to information about the other party. this is actually an
extremely small percentage of communications. we saw some of this
working on the original e-commerce activity
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

where we layed out hypothetical certification issues for merchants ...
including things like having FBI background checks for all merchant
employees. the problem is that e-commerce transactions have been quite
bi-model whith the largest percentage of transaction occuring as repeat
business with well-known merchants. in these cases, consumers have
established trust via a large number of other mechanisms ... so there is
little added value that a certification authority can provide ...
especially if they aren't willing to stand-behind and guarantee all
merchant transactions (ssl then is primarily countermeasure to
mitm-attack and evesdropping on transaction as opposed to a
certification/trust issue).

the rest of the remaining transaction are spread around to a large
number of different merchants having a few transactions each. the issue
here is that the incremental revenue flow for a few transactions a month
couldn't possibly cover the cost of a certification process that
involved things like fbi background checks on all merchant employees.

the large majority of transactions are either repeat business and/or
with extremely well-known merchants ... this doesn't satisfy the PKI
target profile of first time communication between complete strangers.
simple countermeasure to mitm-attack and countermeasure is achieved by
having stored the merchant's public key (from the consumer's standpoint).

from the merchant standpoint they already have transaction guarantees on
credit card processing from their contract with financial institution.
the threat/vulnerability model here is client-originated fraudulent
transactions that aren't strongly authenticated. here, x9.59 standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

allows for digitally signed transaction where the public key is
registered with the consumer's financial institution and the digital
signature is verified by the consumer's financial institution as part of
verifying the transaction.

the other part of x9.59 standard is that it specifies that account
numbers used in x9.59 transactions can't be used in non-authenticated
transactions. this eliminates both data breaches and evesdropping as a
threat/vulnerability for fraudulent financial transactions ... aka the
requirement given the x9a10 working group for x9.59 standard was to
preserve the integrity of the financial infrastructure fo

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[James A. Donald]

--
From: Bill Stewart <[EMAIL PROTECTED]>
> The real security issue for your mother is [...] her  
> bank and eBay don't cryptographically sign their mail.

And, since her bank and ebay are under massive attack  
from phishers, and your mother, if she is using any of  
the common email clients is using a cryptographically  
enabled mail agent, why don't they sign their email?  
This is exactly the attack that PKI was designed to  
address.

My possibly biased answer to this question, based on my 
past job as key keeper for two companies, would be that 
not only can your mother not sign her stuff with PKI,  
but the chairman of the board finds it even harder.

Does anyone else have war stories on this issue?

Just as big companies find it hard to write software  
that does not open their servers to a cross scripting  
attack, and hard to interact with their users in ways  
that do not train their users to respond to phishing  
attacks, and hard to write server side software that  
does not rely on the behavior of client side forms, they 
also find it hard to sign their email.

In the unlikely event that my mother is threatened by  
man in the middle attacks, she will allow me to set up  
secret key on her computer, and will follow my  
instructions on how to use it, but the chairman of the  
board will not, nor will the marketing department.

That is my experience - does anyone else have any  
experience that differs from this, or confirms this?

And before we sneer at the chairman of the board - hands 
up all programmers who failed to client and server side 
disable all past cookies and issue new https and http  
cookies on receiving a valid login, and all programmers 
who failed to enumerate and sterilize all fields  
appearing in any response.

It is not my position that inability to sign means that 
the chairman of the board is stupid.  It is that  
cryptographic signatures are too @#$%^&* hard and need 
to be made user friendly.

First write software that is easy enough for your 
mother.  Then we can work on making it easy enough for 
the marketing department.  

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 gvDLBPaNQFZ3Y0yhzmO2KnYEKGolt9E+eey2rPxE
 4bGpW6AUGiMGbJFzaXJ8QcBY0HMhbypcque+5LrMd



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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[James A. Donald]

--
From:   Ed Gerck <[EMAIL PROTECTED]>
> As new capabilities conflict with the old, the end 
> result of this approach seems to ne a lot of patched 
> in complexity and vulnerabilities.
>
> It seems better to start with a performance 
> specification for the full system. The code can follow 
> the specs as close as possible for each version, the 
> specs can change too, but at least the grand picture  
> should exist beforehand.

Usability is the key part of perfomance.

Amazon is sending out unsigned emails.  Seems to me this 
is in part because they find it hard to sign anything, 
in part because if they did sign something I doubt it 
would do the end user much good, since the end user is 
already suffering from name overload, and is unlikely to 
appreciate the difference between a signature belonging 
to amazon.com, amazon.co.uk, and amazon.jim.com

We really need to start from the user, and look for ways 
in which the user's mental model of security can be used 
to defeat realistic threats.  

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 b5RoNWK+PD+pn6rk1lBkzIqv8T4ntwUO6CxDoPtA
 48yzird9uDuNNK+xU0XcZisSug3K2XHzHu0MXgwqB



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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[James A. Donald]

--
From:  Anne & Lynn Wheeler <[EMAIL PROTECTED]>
> drastically improving the useability of the interface 
> to the trusted public key repositories could be viewed 
> as having two downsides 1) certification authorities 
> that haven't payed to have their public keys preloaded 
> can more easily join the club, 2) the pgp-like 
> scenario becames much easier, potentially drastically 
> reducing existing reliance on the 
> digital-certificate-only (and certification authority 
> only business process) digital-signed-operation model.

I would state the same thing differently:  That the 
revenue model is based on sprinkling holy water over 
communications, rather than actually providing security.

Hence the proposal to address phishing by providing 
higher priced grades of holy water.

Public keys are relevant to the problem of decentralized 
reputation management.  For relationship management, 
shared secrets are better.   At present, the only widely 
applied reputation management software is that possessed 
by Ebay - which uses centralized reputation management 
software, so that it can charge people a fee for making 
use of their own reputations, and thus has no inherent 
need or desire for public keys.

After all these years, we still do not have a good fit 
between the capabilities of the technology, the 
usability of the interface, and the problems people need 
solved. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 X1okruQ3BE+qbWjk1b7CgXMbsiKNhvf5oMKDgR71
 4cxizGKqHfxeifgKTUEvpkLYq7wSgzAckTy2yLzQ8



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

another feature RNGs could provide

[Travis H.]

One thing I haven't seen from a PRNG or HWRNG library or device is an
unpredictable sequence which does not repeat; in other words, a
[cryptographically strong?] permutation.  This could be useful in all
sorts of places in the kernel and elsewhere to prevent replay (for
example, in DNS ID #s, in challenge-response protocols, for IVs where
you must never repeat an IV, etc.)  From what I can tell the common
practice is to pick a value at random, and hope that you don't get a
collision, but this has the problem of the birthday paradox.

The questions I have for you are:

1) What form should the API for this take?  I was thinking that there
could be a
create new sequence" operation, and the system could return an opaque
value to the client to store for its next value, and the "get next"
operator could take it as an input, freeing the PRNG from having to
remember state for every stream.

2) While CTR mode with a random key is sufficient for creating a
permutation of N-bit blocks for a fixed N, is there a general-purpose
way to create a N-bit permutation, where N is a variable?  How about
picking a cryptographically strong permutation on N elements, where N
is not necessarily a power of 2?

3) Is there any point in offering a permutation generator that is not
cryptographically strong?
--
http://www.lightconsulting.com/~travis/  -><- P=NP if (P=0 or N=1)
"My love for mathematics is unto 1/x as x approaches 0."
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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

crypto for the average programmer

[Travis H.]

In Peter Gutmann's godzilla cryptography tutorial, he has some really
good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. 
I learned a few no-nos, such as not sending the same message to 3
seperate users in RSA (if using 3 as an encryption exponent).

My question is, what is the layperson supposed to do, if they must use
crypto and can't use an off-the-shelf product?  Is there any site
tracking such gotchas as they show up in the literature?  Are there
APIs written specifically so that a crypto-naive programmer can safely
use them?

This reminds me a bit of Schneier's advice in Practical Cryptography
to use a crypto hash on every user-supplied input to a crypto
algorithm; doing so makes it very difficult for them to control the
input in a way that breaks the system.  But plain SHA-1 is not enough
for him; he has a few constructions that prevent length-extension
attacks, and I presume it should include some random padding as well.

Additionally, I was thinking of providing some compression and crypto
libraries that return their output in two parts; one the predictable
portion, the other unpredictable.  One thing I've noticed is that many
libraries and programs don't distinguish between the two, and so you
risk giving the attacker known plaintext when post-processing them
(and you don't know exactly how much unless you dive into file format
specifics).  Would it be useful enough to merit the effort?
--
http://www.lightconsulting.com/~travis/  -><- P=NP if (P=0 or N=1)
"My love for mathematics is unto 1/x as x approaches 0."
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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

Re: crypto for the average programmer

[Steve Furlong]

> My question is, what is the layperson supposed to do, if they must use
> crypto and can't use an off-the-shelf product?

When would that be the case?

The only defensible situations I can think of in which a
non-crypto-specialist programmer would need to write crypto routines
would be an uncommon OS or hardware, or a new or rare programming
language which doesn't have libraries available from SourceForge etc.
Or maybe implementing an algorithm that's new enough it doesn't have a
decent free implementation, but I'm not sure such an algorithm should
be used in production code.

Indefensible situations include the programmer wanting to write his
own crypto because it's cool or because he just knows he can do better
than all the specialists (in which case he's too arrogant or ignorant
to benefit from a common gotchas list) or the manager telling the
programmer to implement it himself for some bad reason (in which case
the programmer should explain why that's a bad idea).


--
"Oooh, so Mother Nature needs a favor?! Well maybe she should have
thought of that when she was besetting us with droughts and floods and
poison monkeys! Nature started the fight for survival, and now she
wants to quit because she's losing. Well I say, hard cheese." --
Montgomery Burns

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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[James A. Donald]

--
From:   Ed Gerck <[EMAIL PROTECTED]>
> Digital certs (X.509 and PGP) are useful when the key
> owner is not online. There is a world when this not
> only happens but is also useful. BTW, this is
> recognized in IBE as well.

But the key owner is always online, for in practice,
certs are always used for https.

Arguably we should be using not-necessarily-online certs
to sign email, but the email that arguably needs
signing, for example emails from amazon.com, are never
signed.

The only reason this email is signed is to make a point
about technology, not because the signature serves any
useful purpose.

 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 ca4N69sv32Q/plWYe5BnvcydTDFaMVJkZ0rPbVp6
 4CRaaWK8UP3bCPHDbDzuPW7zEKImu5L9x7RUMIrbG



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

RE: crypto for the average programmer

[Whyte, William]

> In Peter Gutmann's godzilla cryptography tutorial, he has some really
> good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. 
> I learned a few no-nos, such as not sending the same message to 3
> seperate users in RSA (if using 3 as an encryption exponent).

> My question is, what is the layperson supposed to do, if they must use
> crypto and can't use an off-the-shelf product? 

Check the standards.

The RSA PKCS#1 standard, which are free, describe 
how to do RSA securely and summarize known security results. 
http://www.rsasecurity.com/rsalabs/node.asp?id=2124. Don't use
PKCS#3-style Diffie Hellman; it's been superseded by the 
versions in ASC X9.42 and IEEE Std 1363-2000.

The Standards for Efficient Cryptography Group (www.secg.org)
publishes SEC1, which describes how to do Elliptic curve algorithms
securely. The standard is free to download, but note that some 
techniques in it have licensing requirements.

NIST, in its series of FIPS standards and Special Publications, has defined 
federal standards for digital signatures and modes of operation for symmetric 
ciphers, and is moving towards standardizing key exchange mechanisms based
on public key algorithms. Those standards are also free, though they
sometimes reference non-free standards.

Other standards groups, such as the IEEE P1363 Working Group (which I chair
-- http://grouper.ieee.org/groups/1363/) and the ASC X9F1 working group 
for cryptographic techniques for the financial services industry, publish 
(for purchase) standards for secure use of other public-key algorithms. 
1363 is currently working on 
- Lattice-based cryptography, such as NTRU (who I work for)
- Password-based public key techniques such as SPEKE, SRP, etc
- A revision of the 1363-2000 standard.
A lot of the documents relevant to these projects are available for
free off the site. X9 is working on a wider range of projects, but
your company has to be an X9 member for you to access them.

> Is there any site
> tracking such gotchas as they show up in the literature?

Rather than tracking gotchas minute-by-minute it's probably best
to use existing standards.

Cheers,

William

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

Re: another feature RNGs could provide

[Jack Lloyd]

On Mon, Dec 12, 2005 at 12:20:26AM -0600, Travis H. wrote:
> 2) While CTR mode with a random key is sufficient for creating a
> permutation of N-bit blocks for a fixed N, is there a general-purpose
> way to create a N-bit permutation, where N is a variable?  How about
> picking a cryptographically strong permutation on N elements, where N
> is not necessarily a power of 2?

Use can use the Bear or Lion constructions to form 2^{arbitrary} bit block
ciphers quite easily.

-Jack

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

crypto wiki -- good idea, bad idea?

[Travis H.]

Seems like a lot of new folks (myself included) ask questions that
have the following answer:

Read the literature, no there's no one site, that would be too much effort, &c.

Would a wiki specifically for crypto distribute the burden enough to be useful?
Or should we just stick to wikipedia?  Is it doing a satisfactory job?

Your opinions welcome.
--
http://www.lightconsulting.com/~travis/  -><- P=NP if (P=0 or N=1)
"My love for mathematics is unto 1/x as x approaches 0."
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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

RE: crypto for the average programmer

[Whyte, William]

> NIST, in its series of FIPS standards and Special Publications, has defined 
> federal standards for digital signatures and modes of operation for symmetric 
> ciphers, and is moving towards standardizing key exchange mechanisms based
> on public key algorithms. Those standards are also free, though they
> sometimes reference non-free standards.

Sorry, meant to include links for these:

Overall home page: http://csrc.nist.gov/focus_areas.html#csa

FIPS: http://csrc.nist.gov/publications/fips/index.html

Special Publications: http://csrc.nist.gov/publications/nistpubs/

Wiliam

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

Re: crypto for the average programmer

[Alexander Klimov]

On Mon, 12 Dec 2005, Travis H. wrote:
> In Peter Gutmann's godzilla cryptography tutorial, he has some really
> good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal.
> I learned a few no-nos, such as not sending the same message to 3
> seperate users in RSA (if using 3 as an encryption exponent).

Probably you have misunderstood it: if you do it correctly (e.g.,
use some standard method like RSAES-OAEP or even RSAES-PKCS1-v1_5)
you can send the same message to 3 (or whatever) separate users
without any bad consequences. The problem appears if you use some
non-standard method, e.g., plain RSA (c = m^e \pmod n).

> My question is, what is the layperson supposed to do, if they must
> use crypto and can't use an off-the-shelf product?

This is quite simple: get some respected standard (see, e.g.,
NIST  or
PKCS ) and
implement it exactly. Interoperability is a bonus :-)

-- 
Regards,
ASK

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

Re: NSA posts notice about faster, lighter crypto

[Alexander Klimov]

On Sat, 10 Dec 2005, Anne & Lynn Wheeler wrote:

> NSA posts notice about faster, lighter crypto
> http://www.fcw.com/article91669-12-09-05-Web

This makes me wonder how news are created -- the NSA announcement made
on 16 February 2005 becomes a news in December...

BTW, we already discussed here Suite B a couple of months ago (see,
e.g., "NSA Suite B Cryptography" thread started by Perry posted on
Thu, 13 Oct 2005 21:41:50 -0400 (EDT))

-- 
Regards,
ASK

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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[Travis H.]

Not to side track the discussion, but frequently I've heard PKI
compared to PGP's model.  Isn't PGP's trust model the same as everyone
being their own CA?

I find PGP to be problematic.  Many keys I see are only self-signed,
and this includes important keys like CERT.  Many others sit unsigned
on the same website you access to download the source code protected
by it.  And 90% of the time when they have more than one signature you
don't have a key that signed the other party's key, so you get to do a
breadth-first search manual-like (pathserver being dead and all). 
Even with kgpg pulling the keys from a keyserver for you, it's still
non-trivial.

I successfully inspired a local keysigning, but it seems like most of
the people didn't see any immediate benefit, and so declined to
participate.  "What does this mean for me" was a common question.  I
tried to explain the purpose, but I suspect it is too recondite or too
far removed from their experience.  Perhaps I'd have better luck by
stating what kind of attacks it would prevent (email spoofing being
relatively rare, save for some obvious spam tactics).  I'm open to any
suggestions along these lines.
--
http://www.lightconsulting.com/~travis/  -><- P=NP if (P=0 or N=1)
"My love for mathematics is unto 1/x as x approaches 0."
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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

Re: crypto wiki -- good idea, bad idea?

[Paul Hoffman]

At 9:57 AM -0600 12/12/05, Travis H. wrote:
Would a wiki specifically for crypto distribute the burden enough to 
be useful?

Or should we just stick to wikipedia?  Is it doing a satisfactory job?


I cannot answer the first question: I am leery of wikis that have 
open posting rights, and I am leery of trusting anyone to maintain 
the posting rights and document quality of a wiki without being paid 
(either in money or whuffie) to do so.


The second and third questions can be answered with "no". Someone 
wrote a fairly poor article on VPNs. That article has been flagged as 
needing a lot of work. I proposed a few weeks ago (in the 
meta-discussion) to do it, but was concerned that doing so would step 
on toes and seem invasive. No one has responded to that, not even the 
people who flagged the article as needing work.


In other words, Wikipedia is trying to correct problems, but doesn't 
have the personpower to do so in a predictable fashion.


--Paul Hoffman, Director
--VPN Consortium

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

Re: crypto wiki -- good idea, bad idea?

[Alexander Klimov]

On Mon, 12 Dec 2005, Travis H. wrote:

> Seems like a lot of new folks (myself included) ask questions that
> have the following answer: Read the literature, no there's no one
> site, that would be too much effort, &c. Would a wiki specifically
> for crypto distribute the burden enough to be useful?

The problem is not the effort on the writer's side (it was actually
done many times in the past), the problem is the effort on the
reader's side and there is no hope to solve it unless direct to brain
information downloading is invented :-)

> Or should we just stick to wikipedia?  Is it doing a satisfactory job?

You can decide it for youself:


-- 
Regards,
ASK

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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

[James A. Donald]

--
From:  Ralf Senderek <[EMAIL PROTECTED]>
> I think what's missing is the understanding that there 
> cannot be secure email without the persons involved 
> acting responsible and knowing their role in the 
> process. Your mother will probably expect the computer 
> to do the job for her (mine will never expect anything 
> from computers) rejecting any responsibility for her 
> email's security. In my opinion establishing secure 
> email this way is impossible despite the fact that 
> encryption is (relatively) easy if our algorithms work 
> as expected

This sounds like "it is not my fault.  It is those 
stupid user's fault"

No, it is not those stupid user's fault.  It is our
fault.  For example phishing ought not to be possible -
would not be possible if we used zero knowledge
technologies to protect passwords.

Whenever a user communicates anything to anyone, they 
use a password, or some form of shared secret - their 
credit card number - the password whereby they login to 
their mail server. Therefore, whenever a user 
communicates anything to anyone, it should be secure, 
but it is not. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 Jogksi+CFTLv6yHXLYAd6VeQz73gNHYNM1t/B6aB
 4uVe9+oTO/DP7awisj6RYpMbzekGf0+UrwxWfnpxM



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

Re: crypto for the average programmer

[James A. Donald]

Date sent:  Mon, 12 Dec 2005 00:41:13 -0600
From:   "Travis H." <[EMAIL PROTECTED]>
To: cryptography@metzdowd.com
Subject:crypto for the average programmer

> In Peter Gutmann's godzilla cryptography tutorial, he has some really
> good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal.
> I learned a few no-nos, such as not sending the same message to 3
> seperate users in RSA (if using 3 as an encryption exponent).
> 
> My question is, what is the layperson supposed to do, if they must use
> crypto and can't use an off-the-shelf product?  Is there any site
> tracking such gotchas as they show up in the literature?  Are there
> APIs written specifically so that a crypto-naive programmer can safely
> use them?

It seems to me that if the only thing you use public key encryption 
for is to encrypt a single use randomly chosen symmetric key, and 
integrity bits for that key, and if you then use that symmetric key 
once and only once, to encrypt a message that already contains 
integrity checking and a unique random number, you don't need to 
worry about those issues.

Of course those issues reappear when using public keys for signature 
algorithms - so don't invent your own signature protocol.  Signatures 
are hard.


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

RE: crypto for the average programmer

[James A. Donald]

--
From: "Whyte, William" <[EMAIL PROTECTED]>
> Check the standards.
>
> The RSA PKCS#1 standard, which are free, describe how 
> to do RSA securely and summarize known security 
> results. 
> http://www.rsasecurity.com/rsalabs/node.asp?id=2124. 
> Don't use PKCS#3-style Diffie Hellman; it's been 
> superseded by the versions in ASC X9.42 and IEEE Std 
> 1363-2000.
>
> The Standards for Efficient Cryptography Group 
> (www.secg.org) publishes SEC1, which describes how to 
> do Elliptic curve algorithms securely. The standard is 
> free to download, but note that some techniques in it 
> have licensing requirements.
>
> NIST, in its series of FIPS standards and Special 
> Publications, has defined federal standards for 
> digital signatures and modes of operation for 
> symmetric ciphers, and is moving towards standardizing 
> key exchange mechanisms based on public key 
> algorithms. Those standards are also free, though they 
> sometimes reference non-free standards.

Of course most of this has already been incorporated in 
standard crypto libraries, such as CryptoPP, and does 
not need to be rewritten.

Be warned, however, that if you faithfully follow a 
standard without comprehending why the standard is the 
way that it is, you will probably screw it up, because 
you will not really understand what faithfullness is.

In practice, it is frequently necessary to roll your own 
damned standards, and in practice, people who roll their 
own damned standard frequently get them wrong.  For 
example SSH had to be SSH, it could not be SSL, and the 
first version of SSH was, predictably, wrong.  Similarly 
the first version of Wifi used WEP, which contained 
errors that should have been spotted, but were not. They
had to roll their own, because they needed to solve a
particular problem which was not the same as the 
problems that other standards solve.

You should, however, never roll your own damned standard
without good reason. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 TXXgVeLZjViyf6+f7NQt7WCs7MzxO/j25GYLXcEg
 4js14nleizkni3mC38n+4rk2r07+4mylYuP2+UnlI



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

Re: crypto wiki -- good idea, bad idea?

[Roy M. Silvernail]

Travis H. wrote:

>Would a wiki specifically for crypto distribute the burden enough to be useful?
>Or should we just stick to wikipedia?  Is it doing a satisfactory job?
>  
>
I'd read it.  More resources == better.  But keep the current Wikipedia
controversy in mind WRT the veracity of the contributed material.  Then
again, if it's a crypto wiki, I suppose we could expect some
credentialing system to be incorporated.  It could even be presented as
a tutorial.

-- 
Roy M. Silvernail is [EMAIL PROTECTED], and you're not
"It's just this little chromium switch, here." - TFT
CRM114->procmail->/dev/null->bliss
http://www.rant-central.com


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

Re: crypto for the average programmer

[leichter_jerrold]

On Mon, 12 Dec 2005, Steve Furlong wrote:
| > My question is, what is the layperson supposed to do, if they must use
| > crypto and can't use an off-the-shelf product?
| 
| When would that be the case?
| 
| The only defensible situations I can think of in which a
| non-crypto-specialist programmer would need to write crypto routines
| would be an uncommon OS or hardware, or a new or rare programming
| language which doesn't have libraries available from SourceForge etc.
| Or maybe implementing an algorithm that's new enough it doesn't have a
| decent free implementation, but I'm not sure such an algorithm should
| be used in production code.
I can tell you a situation that applied in one system I worked on:  You
could 
go with SSL, which gets you into GPL'ed code, not to mention the known
complexities of using the SSL libraries correctly (steep learning curve); or

we could go commercial code that had fairly steep license fees.  The
decision 
was to use off-the-shelf where completely unencumbered (e.g., Gladman's AES 
implementation), build the rest ourselves.

BTW, there are other issues with SSL.  We needed to fit this implementation
in 
to an already-running system with minimal effect - but try to get people to 
use it.  Having to get certificates for SSL was a big hurdle.  Even creating

self-signed certs was a hassle.  The existing code ran directly over TCP,
and 
assumed a byte stream.  SSL is record-oriented.  This shows up, for example,
when your 1-byte ACK (of which we send many) turns into a 32-byte block (or 
even larger).

We weren't interested in "complete" security - we just needed to raise the 
level considerably.  Given the nature of the application, message 
authentication was not *that* big a deal - it could be put off.

SSL is a fine protocol, and on theoretical terms, yes, you probably want 
everything it provides.  But in practice it's too much.

BTW, there are some interesting "social" issues.  Before we implemented our 
own crypto layer, we recommended people go through ssh tunnels.  The product

was set up to allow that.  I made the argument "Do you really want us to 
provide your crypto?  We're not crypto experts.  But this was perceived as 
clunky, complicated ... it didn't make it look as if the *product*.  Those 
factors were ultimately seen as more important than the very highest level
of 
security.  You can *still* use ssh, of course  (In fact, I was in a 
discussion with a military contractor who wanted to use the product.  The 
question came up of exactly how our crypto worked, whether it would be 
approvable for their application, etc.  My comment was:  Isn't NSA providing

you guys with encrypted links anyway?  Answer - sure, you're right; we don't

need to do application-level encryption.  If IPSEC were actually out there,
all sorts of nasty issues would just magically go away.)

-- Jerry


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