Re: Strength in Complexity?

2008-08-04 Thread Perry E. Metzger

Arshad Noor [EMAIL PROTECTED] writes:
 Ben Laurie wrote:
 As such, I'm not seeing much value.

 That may be because you are a cryptographer.  If you were the CSO, an
 Operations Director, or an Application Developer in a company that had
 to manage encryption keys for 5,000 POS Terminals, 10,000 laptops,
 desktops and servers across multiple data-centers and 400 stores, you
 would see it very differently.

I'm not sure I would see it differently from Ben.

There are existing deployed solutions like Kerberos that scale far
beyond that and work just fine, and actually address all the things
this protocol seems to leave as an exercise to the reader. And yes,
they're in use in real companies at gigantic scales. (Indeed, Kerberos
is central to Microsoft's technologies these days.)


Perry

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


Re: Strength in Complexity?

2008-08-04 Thread Cat Okita

On Sun, 3 Aug 2008, Arshad Noor wrote:

A more optimistic way of putting this, Ben, is to state that EKMI allows
domain-experts of underlying components to address the complex issues of
their domain in ways that they deem best, while providing value on top
of those components.  I see no reason to reinvent any of the components
- despite their imperfections - when they serve my purpose very well.
The business goal here is not cryptographic elegance or perfection, but
a solution to a problem without creating new vulnerabilities.


... or in other words, EKMI leaves all of the hard/impossible problems
to be solved by somebody else.  I'd have to agree with Ben that I'm
not seeing the value add of an additional layer of complexity.


That may be because you are a cryptographer.  If you were the CSO, an
Operations Director, or an Application Developer in a company that had
to manage encryption keys for 5,000 POS Terminals, 10,000 laptops,
desktops and servers across multiple data-centers and 400 stores, you
would see it very differently.


That's an interesting presumption that you're making -- are you familiar
with your audience?

cheers!
==
A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now.

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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Perry E. Metzger wrote:


There are existing deployed solutions like Kerberos that scale far
beyond that and work just fine, and actually address all the things
this protocol seems to leave as an exercise to the reader. And yes,
they're in use in real companies at gigantic scales. (Indeed, Kerberos
is central to Microsoft's technologies these days.)


The example I used was only illustrative.  SKSML allows for 2^64 keys
per server, 2^64 servers per domain and 2^64 unique domains on the
internet.  The GlobalKeyID (GKID) of a key within a Symmetric Key
Management System (SKMS) is defined to be a triple consisting of the
concatenation of the unique domain ID, the server ID and the key ID 
(DID-SID-KID).  So GKID's can range from 1-1-1 all the way upto

(2^64-1)-(2^64-1)-(2^64-1); so it is fairly scalable.

That said, Kerberos clearly has the benefit of 20+ years of research
and use in the field.  However, there are two fundamental differences
between SKSML and Kerberos, IMHO:

1) The design goals for Kerberos were very different from SKSML.  The
   former solves the problem of network-authentication in the face of
   insecure hosts/networks, while the latter focuses on long-term key
   management.  That they both use very similiar concepts  components
   to deliver quite different benefits to applications is testament to
   the strength and flexibility of the underlying components rather
   than to a weakness of SKSML.

2) AFAIK, Kerberos clients cannot deliver their stated benefit (network
   authentication) in the absence of the network or the Kerberos server.
   SKSML is designed to allow disconnected EKMI clients to continue
   providing cryptographic services to applications even in the absence
   of the network or the key-management server.  However, it does
   require that the Symmetric Key Client Library (SKCL) have connected
   to the Symmetric Key Services (SKS) server at least once before it
   can use this capability.

Arshad Noor
StrongAuth, Inc.


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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Cat Okita wrote:

... or in other words, EKMI leaves all of the hard/impossible problems
to be solved by somebody else.  I'd have to agree with Ben that I'm
not seeing the value add of an additional layer of complexity.


I view EKMI as using the best tools the cryptographic community has to
offer to solve specific business problems.  As I stated in an earlier
e-mail, one man's meat is another man's poison.  What you see as
additional layer of complexity is viewed as a layer of simplification
by some people - no different from how one might view a self-starter
in an automobile, as a layer of complexity over a crank-starter.

  That's an interesting presumption that you're making -- are you familiar

with your audience?



To the extent that anyone can claim familiarity with something as
fickle and temporal as the needs of an audience, I believe I do (for
the moment).  I recognize that I cannot please everyone in any
audience, and must therefore, do/say what what I believe is right for
my customers.  Only time will tell if I got it right - temporarily.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-08-04 Thread Perry E. Metzger

Arshad Noor [EMAIL PROTECTED] writes:
 That said, Kerberos clearly has the benefit of 20+ years of research
 and use in the field.  However, there are two fundamental differences
 between SKSML and Kerberos, IMHO:

 1) The design goals for Kerberos were very different from SKSML.  The
former solves the problem of network-authentication in the face of
insecure hosts/networks, while the latter focuses on long-term key
management.

Well, kerberos does both, really. It also has the advantage that it
is fully specified and integrates with GSSAPI.

That they both use very similiar concepts  components
to deliver quite different benefits to applications is testament to
the strength and flexibility of the underlying components rather
than to a weakness of SKSML.

 2) AFAIK, Kerberos clients cannot deliver their stated benefit (network
authentication) in the absence of the network or the Kerberos server.

It is generally hard to deliver network authentication without a
network. That said, kerberos tickets can persist even in the face of
disconnects, so once you've connected tickets can survive as long as
you wish.

SKSML is designed to allow disconnected EKMI clients to continue
providing cryptographic services to applications even in the absence
of the network or the key-management server.  However, it does
require that the Symmetric Key Client Library (SKCL) have connected
to the Symmetric Key Services (SKS) server at least once before it
can use this capability.

That's no different from Kerberos, and kerberos works quite well
already.


Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Perry E. Metzger wrote:

That said, kerberos tickets can persist even in the face of
disconnects, so once you've connected tickets can survive as long as
you wish.


But, can the tickets be used for anything useful when the
network does not exist?

I agree that when the network comes back, the ticket can pick
up where it left off and continue providng its stated service
until the ticket expires; but unless there are applications I'm
unfamiliar with, Kerberos tickets are not very useful in the
absence of a network.  Yes, they can be used to authenticate to
local services on the disconnected client, but what benefit does
that provide?

SKMS clients can continue to provide the capability they were
designed for, even when the network is unavailable - it was a
critical design goal.  Yes, applications don't need a central
key-management service to use cryptographic keys on a client;
but the whole business purpose for SKMS is to have centralized
policy-driven key-management, with the added benefit of secure,
disconnected operations.

If this comes back to Ben's original statement about it being
just a key-escrow service, then so be it.  But lets not dismiss
the value standardization and abstraction of this capability
provides - after all people didn't really need DBMS's 30 years
ago because they could do all the data-management operations
inside each application quite well, thank you!

But, the true value of DBMS was to free up application developers,
operations and business managers to deliver new levels of information
services because they no longer had to deal with the arcane mechanics
of data-management in unique ways inside each application, on each
platform.  What DBMS did for the abstraction and standardization of
data-management, I anticipate SKMS doing for key-management.  Those
precise three groups of people - and now, including security and
compliance officers - are slowly starting to discover that for themselves.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-08-04 Thread dan

With the caveat that I am reading mail in 
reverse order (i.e., panic-mode), I do have
to say one thing and it isn't even to mount a
stirring defense of Kerberos, which does not
need defending anyhow...

The design space for practical network security
has always been:

   I'm OK
   You're OK
   The Internet is a problem

A gathering storm of compromised machines, now
variously estimated in the 30-70% range depending
on with whom you are talking, means that the 
situation is now:

   I'm OK, I think
   I have to assume that you are 0wned
   The Internet might make this worse

Put differently, network security has now come
close to Spaf's famous line about netsec in the
absence of host security being assured delivery
of gold bars from a guy living in a cardboard box
to a guy sleeping on a park bench.

BTW, it is probably time to turn off your software's
autoupdate feature.

http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt

Likely off-topic,

--dan

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


Re: Strength in Complexity?

2008-08-04 Thread Perry E. Metzger

Arshad Noor [EMAIL PROTECTED] writes:
 Perry E. Metzger wrote:
 That said, kerberos tickets can persist even in the face of
 disconnects, so once you've connected tickets can survive as long as
 you wish.

 But, can the tickets be used for anything useful when the
 network does not exist?

If you have a locally service that uses them, sure. In any case, a
ticket gives you access to a crypto key, and you can use that for all
sorts of things.

 SKMS clients can continue to provide the capability they were
 designed for, even when the network is unavailable - it was a
 critical design goal.

Well, again, you can do the same thing with Kerberos, and Kerberos has
the added advantage that there is a complete spec that fully handles
all the details and is actually implemented and available off the
shelf -- even built in to Windows. SKMS is vaporware that leaves all
the hard parts of the specification out.

 If this comes back to Ben's original statement about it being
 just a key-escrow service, then so be it.  But lets not dismiss
 the value standardization and abstraction of this capability
 provides

I'm inclined to dismiss it, if only because you can do all of it with
existing, implemented and fully specified tools with no added
complexity. I actually have much larger reservations, but I think that
alone eliminates the reason to consider it.

 - after all people didn't really need DBMS's 30 years
 ago because they could do all the data-management operations
 inside each application quite well, thank you!

I think that comparing the advance SQL made with SKMS seems a bit
unreasonable.

Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Strength in Complexity?

2008-08-04 Thread Tim Hudson

Perry E. Metzger wrote:

Arshad Noor [EMAIL PROTECTED] writes:

- after all people didn't really need DBMS's 30 years
ago because they could do all the data-management operations
inside each application quite well, thank you!


I think that comparing the advance SQL made with SKMS seems a bit
unreasonable.


I think that Arshad's point here is an argument that externalising key
management handling from normal application logic is a valid one but that it is
also equally applicable to existing Kerberos environments.

I don't think a point beyond externalisation is good was trying to be made 
here.

Tim

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


compromised hosts (was Re: Strength in Complexity?)

2008-08-04 Thread Perry E. Metzger

[EMAIL PROTECTED] writes:
 The design space for practical network security
 has always been:

I'm OK
You're OK
The Internet is a problem

 A gathering storm of compromised machines, now
 variously estimated in the 30-70% range depending
 on with whom you are talking, means that the 
 situation is now:

I'm OK, I think
I have to assume that you are 0wned
The Internet might make this worse

 Put differently, network security has now come
 close to Spaf's famous line about netsec in the
 absence of host security being assured delivery
 of gold bars from a guy living in a cardboard box
 to a guy sleeping on a park bench.

This is indeed a big new problem -- indeed, I'd say that how you deal
with partially trusted people logged on to untrusted equipment is now
the name of the game.

 BTW, it is probably time to turn off your software's
 autoupdate feature.

 http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt

 Likely off-topic,

Not entirely. :)

-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Strength in Complexity?

2008-08-04 Thread Perry E. Metzger

Tim Hudson [EMAIL PROTECTED] writes:
 I think that Arshad's point here is an argument that externalising
 key management handling from normal application logic is a valid one
 but that it is also equally applicable to existing Kerberos
 environments.

 I don't think a point beyond externalisation is good was trying to
 be made here.

Well, that's not unreasonable.

Of course, if you're looking for ways to add a layer so that
application logic can be detached from authentication logic, GSSAPI is
one answer. People may have varying opinions on GSSAPI, but it does
have the merit of existing and being widely available.

Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Strength in Complexity?

2008-08-04 Thread Arshad Noor

Perry E. Metzger wrote:

SKMS is vaporware that leaves all
the hard parts of the specification out.


An open-source implementation has been available for 2 years.
A new version will be available next year that will implement
the current OASIS draft and whatever useful comments the
Public Review of the specification brings.



I think that comparing the advance SQL made with SKMS seems a bit
unreasonable.



I was comparing the concept of data-management to key-management,
which is a more appropriate analogy; there is no end-user language
within an SKMS.

WRT comparing SKMS to Kerberos, for 20+ years I've always seen
Kerberos as a network-authentication protocol and perhaps it is my
failing that I couldn't see the possibility of using a flat-head
screwdriver in a Philips-head screw.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-08-04 Thread Peter Saint-Andre

[EMAIL PROTECTED] wrote:
With the caveat that I am reading mail in 
reverse order (i.e., panic-mode), I do have

to say one thing and it isn't even to mount a
stirring defense of Kerberos, which does not
need defending anyhow...

The design space for practical network security
has always been:

   I'm OK
   You're OK
   The Internet is a problem

A gathering storm of compromised machines, now
variously estimated in the 30-70% range depending
on with whom you are talking, means that the 
situation is now:


   I'm OK, I think
   I have to assume that you are 0wned
   The Internet might make this worse

Put differently, network security has now come
close to Spaf's famous line about netsec in the
absence of host security being assured delivery
of gold bars from a guy living in a cardboard box
to a guy sleeping on a park bench.


BTW the original quote seems to be:

Secure web servers are the equivalent of heavy armored cars. The 
problem is, they are being used to transfer rolls of coins and checks 
written in crayon by people on park benches to merchants doing business 
in cardboard boxes from beneath highway bridges. Further, the roads are 
subject to random detours, anyone with a screwdriver can control the 
traffic lights, and there are no police.


-- http://homes.cerias.purdue.edu/~spaf/quotes.html

/psa



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Strength in Complexity?

2008-08-03 Thread Ben Laurie
So, an executive summary of your responses appears to be EKMI leaves 
all the hard/impossible problems to be solved by components that are out 
of scope.


As such, I'm not seeing much value.

Anyway...

Arshad Noor wrote:

Ben Laurie wrote:
OK, so you still have a PKI problem, in that you have to issue and 
manage client certificates. How is this done?



One man's meat  :-).  (I don't necessarily view this as a problem
Ben.  I've built up a career and a small business in the last 9 years
doing just that.)

Nevertheless, to answer the question, the PKI deployment is not part
of the SKSML prtocol (other than the WSS header that carries the XML
Signature and/or XML Encryption of the SOAP Body), but it is part of
an EKMI.  (EKMI = PKI + SKMS).  A company deploying an EKMI must have,
or must build a PKI and deploy the client/server certificates separately
from the SKMS.

While this might be viewed as a problem for some/many companies in the
short-term, I fully anticipate that vendor implementations of SKMS will
integrate with PKI software to manage this process seamlessly in the
future.


PKI out of scope...

I do not believe this is the case. DRM fails because the attacker has 
physical possession of the system he is attacking.




Which is why we are recommending that SKMS clients use hardware based
modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the
Private Key used by SKMS client to decrypt the symmetric keys.  While
even these can be attacked, the problem is now in a different domain
than the SKSML protocol.


...impossibility of solving DRM problem out of scope...


EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.


Are there any even vaguely modern systems that target the network for 
security, or is this a straw man?


What I meant to say is that EKMI's goal is to protect the data and not
the network.


...goals the same as pretty much all cryptographic protocols...

If it is up to them, then why bother with this verification process? 
This sounds like yet more security theatre to me.




I'm not sure which verification process you're referring to.

No, this is not security theater.  EKMI does not guarantee anything, nor
does it promise unbreakable anything.  Everything in EKMI is a choice.
You get to choose the strength of your keys, your PKI, your policies,
your procedures and your implementation.  All we're offering is a tool
that does something specific to the extent that the specifications and
the technology allows.  Nothing more, nothing less.  If you - as a
cryptographer - say that AES-156 will do X under these conditions, then
EKMI will support X under those conditions.  EKMI only adds the ability
to manage a large number of keys centrally, and to ease many of the
administrative burdens we see that large-scale key-management can cause.
Everything it does is constrained by the limitations of the underlying
technology components, polices and practices.  But you still have to
make the choice.


...security out of scope and scope out of scope.

Is there anything other than key escrow that's actually in scope?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

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: Strength in Complexity?

2008-08-03 Thread Arshad Noor

Ben Laurie wrote:
So, an executive summary of your responses appears to be EKMI leaves 
all the hard/impossible problems to be solved by components that are out 
of scope.


A more optimistic way of putting this, Ben, is to state that EKMI allows
domain-experts of underlying components to address the complex issues of
their domain in ways that they deem best, while providing value on top
of those components.  I see no reason to reinvent any of the components
- despite their imperfections - when they serve my purpose very well.
The business goal here is not cryptographic elegance or perfection, but
a solution to a problem without creating new vulnerabilities.


As such, I'm not seeing much value.


That may be because you are a cryptographer.  If you were the CSO, an
Operations Director, or an Application Developer in a company that had
to manage encryption keys for 5,000 POS Terminals, 10,000 laptops,
desktops and servers across multiple data-centers and 400 stores, you
would see it very differently.


Is there anything other than key escrow that's actually in scope?


Yes.

- The KeyUsePolicy element in SKSML tells conforming applications
  how to use the symmetric key, where to use it, when to use it, for
  what purpose, for how many transactions, etc.
- The KeyCachePolicy element tells SKSML clients whether they may
  cache keys, and if they may, how many of them and for how long so
  that conforming applications can continue to use keys even when
  disconnected from the central key-management server.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-09 Thread Arshad Noor

Ben Laurie wrote:
OK, so you still have a PKI problem, in that you have to issue and 
manage client certificates. How is this done?



One man's meat  :-).  (I don't necessarily view this as a problem
Ben.  I've built up a career and a small business in the last 9 years
doing just that.)

Nevertheless, to answer the question, the PKI deployment is not part
of the SKSML prtocol (other than the WSS header that carries the XML
Signature and/or XML Encryption of the SOAP Body), but it is part of
an EKMI.  (EKMI = PKI + SKMS).  A company deploying an EKMI must have,
or must build a PKI and deploy the client/server certificates separately
from the SKMS.

While this might be viewed as a problem for some/many companies in the
short-term, I fully anticipate that vendor implementations of SKMS will
integrate with PKI software to manage this process seamlessly in the
future.

I do not believe this is the case. DRM fails because the attacker has 
physical possession of the system he is attacking.




Which is why we are recommending that SKMS clients use hardware based
modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the
Private Key used by SKMS client to decrypt the symmetric keys.  While
even these can be attacked, the problem is now in a different domain
than the SKSML protocol.



EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.


Are there any even vaguely modern systems that target the network for 
security, or is this a straw man?




What I meant to say is that EKMI's goal is to protect the data and not
the network.



If it is up to them, then why bother with this verification process? 
This sounds like yet more security theatre to me.




I'm not sure which verification process you're referring to.

No, this is not security theater.  EKMI does not guarantee anything, nor
does it promise unbreakable anything.  Everything in EKMI is a choice.
You get to choose the strength of your keys, your PKI, your policies,
your procedures and your implementation.  All we're offering is a tool
that does something specific to the extent that the specifications and
the technology allows.  Nothing more, nothing less.  If you - as a
cryptographer - say that AES-156 will do X under these conditions, then
EKMI will support X under those conditions.  EKMI only adds the ability
to manage a large number of keys centrally, and to ease many of the
administrative burdens we see that large-scale key-management can cause.
Everything it does is constrained by the limitations of the underlying
technology components, polices and practices.  But you still have to
make the choice.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-08 Thread Ben Laurie

Arshad Noor wrote:

Ben Laurie wrote:

Arshad Noor wrote:


I may be a little naive, but can a protocol itself enforce proper
key-management?  I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.


I find the question difficult to understand. Before I could even begin 
to answer, you'd have to define what proper key management actually is.


I consider KM to be the discipline of defining policy and establishing
procedures  infrastructure for the generation, use, escrow, recovery
and destruction of cryptographic keys, in conformance with the defined
policies.


Then I would agree that a protocol alone could not achieve all of this, 
though obviously it is possible to design a protocol that makes it 
impossible.


That said, EKMI (from my brief reading) has a view of key management 
that is only proper in quite constrained circumstances. In 
particular, keys are available to participants other than those who 
are communicating, which is general considered to be a very bad idea. 


I'm not sure I'm following your comment here, Ben.  Did some word get
left out?  In EKMI, keys are available only to those who are known to
the central Symmetric Key Services (SKS) server,  and who are authorized
to receive keys.  The knowledge comes from entries in the SKS server
about the clients and their digital certificates.  The authorization
comes from ACLs and from policies that apply to the client.


OK, so you still have a PKI problem, in that you have to issue and 
manage client certificates. How is this done?


 So, yes,

EKMIs are designed for constrained environments.




The design paradigm we chose for EKMI was to have:

1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;



Well. You said centralized server. Many cryptographic systems don't 
have one of those.




I realizecd that two years ago when I started defining the architecture
for EKMI and the software to implement it.  It was the only logical way
of addressing the business problem of managing encryption keys for five
different platforms/applications that needed to share ciphertext on a
daily basis across hundreds of locations and thousands of POS registers.


I'd be very surprised if it were the _only_ logical way to do it. But 
that aside, my point stands: these characteristics are not shared by all 
cryptographic systems. In fact, I'd say that all of them are not shared 
by most cryptographic systems.


Also, the idea of a client library enforcing policy is DRM all over 
again. Which, as we all know, will never work.


You make an interesting point here.  While, conceptually, EKMI and DRM
share similar designs, I believe the reasons for DRM's failure has more
to do with philosophy than with technology.  But that's a different
debate.


I do not believe this is the case. DRM fails because the attacker has 
physical possession of the system he is attacking.


The fact that the attackers is highly motivated because of the 
objectionable nature of DRM does not seem to differ much from your 
system, though in your case the motivator will presumably be profit.



P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using verified libraries
on the client devices, so their polices are not subverted.



Ha ha. Like that's going to work. Even if we assume that libraries are 
verified (fat chance, IMO), how are you going to stop, for example, 
cut'n'paste? Employees reading things out over the phone? Bugs? Etc.




EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.


Are there any even vaguely modern systems that target the network for 
security, or is this a straw man?


  As such, it will merely be a tool in the evolution towards

more secure systems - how people use the tool is up to them.


If it is up to them, then why bother with this verification process? 
This sounds like yet more security theatre to me.


Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

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: Strength in Complexity?

2008-07-07 Thread Peter Gutmann
Florian Weimer [EMAIL PROTECTED] writes:

Let me rephrase my remark: The trust anchor is conceptually separate
from a root CA certificate.

Conceptually yes, in the same way that the Soviet constitition was 
conceptually quite liberal and protective of individual rights.

In practice, no.  Look at your browser, email app, ... to see how it's reaally 
done.

Nothing in that section gives you permission to ignore extensions on the CA 
certificate (skipping the first entry in the certification path).  In 
addition, the trust anchor cannot be used directly to verify certificates 
issued by the CA because the subject DN does not match.  Ergo, the extensions 
on the CA certificate are still in force.

I think people might be getting a bit tired of this discussion of PKI quirks 
so how about the following: you go to the X.509 standards folks and convince 
them that your interpretation of the spec as given above is the correct one.  
Once that's done, we can continue.

Peter.

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


Re: Strength in Complexity?

2008-07-07 Thread Ben Laurie

Arshad Noor wrote:

Florian Weimer wrote:

* Arshad Noor:


http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937 



On a more serious note, I think the criticism probably refers to the
fact that SKSML does not cryptopgrahically enforce proper key
management.  If a participant turns bad (for instance, by storing key
material longer than permitted by the protocol), there's nothing in the
protocol that stops them.


Thank you for your comment, Florian.

I may be a little naive, but can a protocol itself enforce proper
key-management?  I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.
Any examples you can cite where this has been done, would be very
helpful.


I find the question difficult to understand. Before I could even begin 
to answer, you'd have to define what proper key management actually is.


That said, EKMI (from my brief reading) has a view of key management 
that is only proper in quite constrained circumstances. In particular, 
keys are available to participants other than those who are 
communicating, which is general considered to be a very bad idea. This 
is fine if you are a corporation wanting to achieve escrow, of course. 
Though that can be done without requiring a central server to remember 
all the keys, of course.



The design paradigm we chose for EKMI was to have:

1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;

In some form or another, don't all cryptographic systems follow a
similar paradigm?


Well. You said centralized server. Many cryptographic systems don't 
have one of those.


Also, the idea of a client library enforcing policy is DRM all over 
again. Which, as we all know, will never work.


So, in short: no, they don't.


Arshad Noor
StrongAuth, Inc.

P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using verified libraries
on the client devices, so their polices are not subverted.


Ha ha. Like that's going to work. Even if we assume that libraries are 
verified (fat chance, IMO), how are you going to stop, for example, 
cut'n'paste? Employees reading things out over the phone? Bugs? Etc.


Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

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: Strength in Complexity?

2008-07-07 Thread Arshad Noor

Ben Laurie wrote:

Arshad Noor wrote:


I may be a little naive, but can a protocol itself enforce proper
key-management?  I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.


I find the question difficult to understand. Before I could even begin 
to answer, you'd have to define what proper key management actually is.




I consider KM to be the discipline of defining policy and establishing
procedures  infrastructure for the generation, use, escrow, recovery
and destruction of cryptographic keys, in conformance with the defined
policies.

That said, EKMI (from my brief reading) has a view of key management 
that is only proper in quite constrained circumstances. In particular, 
keys are available to participants other than those who are 
communicating, which is general considered to be a very bad idea. 


I'm not sure I'm following your comment here, Ben.  Did some word get
left out?  In EKMI, keys are available only to those who are known to
the central Symmetric Key Services (SKS) server, and who are authorized
to receive keys.  The knowledge comes from entries in the SKS server
about the clients and their digital certificates.  The authorization
comes from ACLs and from policies that apply to the client.  So, yes,
EKMIs are designed for constrained environments.




The design paradigm we chose for EKMI was to have:

1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;



Well. You said centralized server. Many cryptographic systems don't 
have one of those.




I realizecd that two years ago when I started defining the architecture
for EKMI and the software to implement it.  It was the only logical way
of addressing the business problem of managing encryption keys for five
different platforms/applications that needed to share ciphertext on a
daily basis across hundreds of locations and thousands of POS registers.

Also, the idea of a client library enforcing policy is DRM all over 
again. Which, as we all know, will never work.


You make an interesting point here.  While, conceptually, EKMI and DRM
share similar designs, I believe the reasons for DRM's failure has more
to do with philosophy than with technology.  But that's a different
debate.


P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using verified libraries
on the client devices, so their polices are not subverted.



Ha ha. Like that's going to work. Even if we assume that libraries are 
verified (fat chance, IMO), how are you going to stop, for example, 
cut'n'paste? Employees reading things out over the phone? Bugs? Etc.




EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.  As such, it will merely be a tool in the evolution towards

more secure systems - how people use the tool is up to them.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-06 Thread Florian Weimer
* Arshad Noor:

 I may be a little naive, but can a protocol itself enforce proper
 key-management?  I can certainly see it facilitating the required
 discipline, but I can't see how a protocol alone can enforce it.
 Any examples you can cite where this has been done, would be very
 helpful.

As far as I understand it, you don't actually change protocols, which
means that there's likely no way around this problem.

 The design paradigm we chose for EKMI was to have:

 1) the centralized server be the focal point for defining policy;
 2) the protocol carry the payload with its corresponding policy;
 3) and the client library enforce the policy on client devices;

 In some form or another, don't all cryptographic systems follow a
 similar paradigm?

No, there are things like digital cash and mental poker which do not
work with a trusted third party.  I think it's even possible to compute
RSA signatures from a split private key in a way that is secure against
byzantine failure (IOW, a certain number of key holders needs to
cooperate to forge a signature or recover the private key).  There's
also quite a bit of research on operations on encrypted databases.

Of course, you cannot actually run an ordinary web shop on top of such
protocols because interfaces to the public and to the processors are
essentially fixed.  Cryptographically securing the middle end seems
rather pointless to me because the public-facing front end is the
component that causes most of the trouble.  (And I'm not fully convinced
that more encryption is the answer to that.)

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


Re: Strength in Complexity?

2008-07-05 Thread Florian Weimer
* Peter Gutmann:

 [1] Show of hands, how many people here not directly involved with X.509 work
 knew that the spec required that all extensions in CA root certificates
 (trust anchors in recent X.509 jargon) be ignored by an implementation?
 So if you put in name constraints, key usage constraints, a policy
 identifier, etc, then a conforming implementation is supposed to look at
 them, throw them away, and proceed as if they weren't there?

Are you sure that the constraints are not supposed to be applied when
the root certificate is actually processed, after its signature has been
verified by the trust anchor?

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


Re: Strength in Complexity?

2008-07-05 Thread Florian Weimer
* Arshad Noor:

 The author of an article that appeared in InformationWeek this week
 (June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):

 http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937

 states the following:

 There are, of course, obstacles that must still be overcome by EKMI
 proponents. For example, the proposed components are somewhat simple
 by design, which concerns some encryption purists who prefer more
 complex protocols, on the logic that they're more difficult to break
 into.

First of all, a simple SKSML request for a symmetric key is a whopping
77 lines of SOAPWSS/whatever XML; the server response is 62 lines even
without the container.  If this is not enough to make every complexity
fanboy happy, I don't know what can do the trick.

On a more serious note, I think the criticism probably refers to the
fact that SKSML does not cryptopgrahically enforce proper key
management.  If a participant turns bad (for instance, by storing key
material longer than permitted by the protocol), there's nothing in the
protocol that stops them.

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


Re: Strength in Complexity?

2008-07-05 Thread Peter Gutmann
Florian Weimer [EMAIL PROTECTED] writes:
* Peter Gutmann:
 [1] Show of hands, how many people here not directly involved with X.509 work
 knew that the spec required that all extensions in CA root certificates
 (trust anchors in recent X.509 jargon) be ignored by an implementation?
 So if you put in name constraints, key usage constraints, a policy
 identifier, etc, then a conforming implementation is supposed to look at
 them, throw them away, and proceed as if they weren't there?

Are you sure that the constraints are not supposed to be applied when
the root certificate is actually processed, after its signature has been
verified by the trust anchor?

Yup.  The app is supposed to read the cert, parse and process the extensions,
and then throw them away.  The text from the spec is:

  3.3.60 trust anchor: A trust anchor is a set of the following information in
  addition to the public key: algorithm identifier, public key parameters (if
  applicable), distinguished name of the holder of the associated private key
  (i.e., the subject CA) and optionally a validity period. The trust anchor
  may be provided in the form of a self-signed certificate. A trust anchor is
  trusted by a certificate using system and used for validating certificates
  in certification paths.

Rendered into English, that says take the pubic key, owner name, and 
validity period, and ignore everything else in the cert.

To pre-empt the inevitable yes, but it doesn't explicitly say you can't 
process the extensions if you want to: It also doesn't say you can't reformat 
the user's hard drive when you see a cert, but the intent is that you don't do 
anything not explicitly listed in the text above.  One of the known problems 
with this is that any cert that's marked as trusted now becomes a root CA cert 
because of the requirement to ignore the fact that it isn't a root CA cert.

Luckily no sane implementation pays any attention to this nonsense :-).

Peter.

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


Re: Strength in Complexity?

2008-07-05 Thread Florian Weimer
* Peter Gutmann:

 Florian Weimer [EMAIL PROTECTED] writes:
* Peter Gutmann:
 [1] Show of hands, how many people here not directly involved with X.509 
 work
 knew that the spec required that all extensions in CA root certificates
 (trust anchors in recent X.509 jargon) be ignored by an 
 implementation?
 So if you put in name constraints, key usage constraints, a policy
 identifier, etc, then a conforming implementation is supposed to look at
 them, throw them away, and proceed as if they weren't there?

Are you sure that the constraints are not supposed to be applied when
the root certificate is actually processed, after its signature has been
verified by the trust anchor?

 Yup.  The app is supposed to read the cert, parse and process the extensions,
 and then throw them away.  The text from the spec is:

   3.3.60 trust anchor: A trust anchor is a set of the following information in
   addition to the public key: algorithm identifier, public key parameters (if
   applicable), distinguished name of the holder of the associated private key
   (i.e., the subject CA) and optionally a validity period. The trust anchor
   may be provided in the form of a self-signed certificate. A trust anchor is
   trusted by a certificate using system and used for validating certificates
   in certification paths.

 Rendered into English, that says take the pubic key, owner name, and 
 validity period, and ignore everything else in the cert.

Let me rephrase my remark: The trust anchor is conceptually separate
from a root CA certificate.  It is only used to validate it the CA
certificate.  Nothing in that section gives you permission to ignore
extensions on the CA certificate (skipping the first entry in the
certification path).  In addition, the trust anchor cannot be used
directly to verify certificates issued by the CA because the subject DN
does not match.  Ergo, the extensions on the CA certificate are still in
force.

 Luckily no sane implementation pays any attention to this nonsense :-).

I think your interpretation actually leads to a non-compliant
implementation.  Obviously, wording of that section could be less
confusing.

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


Re: Strength in Complexity?

2008-07-05 Thread Arshad Noor

Florian Weimer wrote:

* Arshad Noor:


http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937


On a more serious note, I think the criticism probably refers to the
fact that SKSML does not cryptopgrahically enforce proper key
management.  If a participant turns bad (for instance, by storing key
material longer than permitted by the protocol), there's nothing in the
protocol that stops them.


Thank you for your comment, Florian.

I may be a little naive, but can a protocol itself enforce proper
key-management?  I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.
Any examples you can cite where this has been done, would be very
helpful.

The design paradigm we chose for EKMI was to have:

1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;

In some form or another, don't all cryptographic systems follow a
similar paradigm?

Arshad Noor
StrongAuth, Inc.

P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using verified libraries
on the client devices, so their polices are not subverted.

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


Re: Strength in Complexity?

2008-07-03 Thread Pat Farrell
Peter Gutmann wrote:
 Pat Farrell [EMAIL PROTECTED] writes:
 At CyberCash, where we had real RSA/DES in the system, we found that users
 want convenience, not security
 
 I think that's phrasing it a bit badly, it'd be better put as without
 usability, you won't have users (see the Tor paper Challenges in deploying
 low-latency anonymity for more thoughts on this). 


I don't think we are disagreeing much, but the essence of the CyberCash
law is that user's only focus is on convenience. If you give them a
choice, any and all bumps in the road to ease of use cause rejection.

I'm not trying to argue that 12+ years ago we had great usability. The
world's expectations have evolved a lot since then. But we put a lot of
engineering into usability. And it was not enough.

I believe that its not users will accept some glitches to get security
Rather, users only care about usability/convenience. It has to be
trivial to use first. Cite Twitter, blogs, etc.

The key message to take away is that when we pros design systems, at
least for mass markets, the users will tolerate nothing except convenience.

Pat

-- 
Pat Farrell
http://www.pfarrell.com/

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


Re: Strength in Complexity?

2008-07-02 Thread Peter Gutmann
Perry E. Metzger [EMAIL PROTECTED] writes:

The problem, Peter, is that people who don't know you may mistake your
sarcasm for agreement with misconception in the article Arshad quoted.

What, me, sarcastic?  Never!

The point is not that fools (often including us) haven't built monstrous
ziggurats that failed. The point is that no one rational should *SEEK* to
make a protocol into monstrous ziggurat on the basis that this will improve
security

Sure, any rational designer, working by themselves, will (hopefully) create a
simple, easy-to-analyse protocol.  The problem seems to occur once you get
committees involved (although I've seen some one-person-designed protocols
that can match the output of any standards committee :-).  So there's a
difference between what should happen in an ideal world and what happens in
practice.  People will quite easily build monstrous ziggurats one mud-brick at
a time, as any number of security protocols aptly demonstrate.  They're not
built because someone thinks they'll be more secure that way, but because the
delegate from IBM suggested that we need this, and the delegate from MS
insisted on having that, and the delegate from Verisign required the other.

(Actually even that doesn't really explain something like IKE... :-).

Peter.

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


Re: Strength in Complexity?

2008-07-02 Thread Paul Hoffman

At 8:28 PM -0400 7/1/08, Perry E. Metzger wrote:

[EMAIL PROTECTED] (Peter Gutmann) writes:

 Perry E. Metzger [EMAIL PROTECTED] writes:


No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.


 IPsec.  Anything to do with PKI.  XMLdsig.  Gimme a few minutes and I can
 provide a list as long as your arm.  Protocol designers *love* complexity.
 The more complex and awkward they can make a protocol, the better it has to
 be.


The problem, Peter, is that people who don't know you may mistake your
sarcasm for agreement with misconception in the article Arshad quoted.



The quote from the article was:

There are, of course, obstacles that must still be overcome by EKMI 
proponents. For example, the proposed components are somewhat simple 
by design, which concerns some encryption purists who prefer more 
complex protocols, on the logic that they're more difficult to break 
into.


It jumps from components to protocols. In general, encryption 
purists like simpler algorithms. OTOH, when encryption purists get 
involved in protocol design, the protocols usually become complex to 
the point of opacity.


So, I agree with Peter that that article is probably correct about protocols.

--Paul Hoffman, Director
--VPN Consortium

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


Re: Strength in Complexity?

2008-07-02 Thread Perry E. Metzger

[EMAIL PROTECTED] (Peter Gutmann) writes:
 (Actually even that doesn't really explain something like IKE... :-).

Having been peripherally involved in the causation change for IKE, let
me confess that it was caused by human stupidity destroying the
alternatives. The author of the much cleaner spec asserted copyright
and control over it, and fearing lawsuits, people turned to the
the remaining alternative. A number of us were all to blame for the
situation.

I will point out that the I Dislike IKE pins were not rare at
meetings. Most people understood the situation as it happened.

Perry

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


Re: Strength in Complexity?

2008-07-02 Thread Jack Lloyd
On Wed, Jul 02, 2008 at 07:25:36AM -0400, Perry E. Metzger wrote:
 
 [EMAIL PROTECTED] (Peter Gutmann) writes:
  (Actually even that doesn't really explain something like IKE... :-).
 
 Having been peripherally involved in the causation change for IKE, let
 me confess that it was caused by human stupidity destroying the
 alternatives. The author of the much cleaner spec asserted copyright
 and control over it, and fearing lawsuits, people turned to the
 the remaining alternative. A number of us were all to blame for the
 situation.

Out of curiosity, was this other spec Photuris?

-Jack

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


Re: Strength in Complexity?

2008-07-02 Thread Leichter, Jerry
On Wed, 2 Jul 2008, Peter Gutmann wrote:

| Date: Wed, 02 Jul 2008 12:08:18 +1200
| From: Peter Gutmann [EMAIL PROTECTED]
| To: [EMAIL PROTECTED], [EMAIL PROTECTED]
| Cc: cryptography@metzdowd.com, [EMAIL PROTECTED]
| Subject: Re: Strength in Complexity?
| 
| Perry E. Metzger [EMAIL PROTECTED] writes:
| 
| No. In fact, it is about as far from the truth as I've ever seen.
| No real expert would choose to deliberately make a protocol more 
| complicated.
| 
| IPsec.  Anything to do with PKI.  XMLdsig.  Gimme a few minutes and
| I can provide a list as long as your arm.  Protocol designers *love*
| complexity.  The more complex and awkward they can make a protocol,
| the better it has to be.
The cynical among us might rephrase that as:  The more complex and
awkward they can make a protocol, the better it will be at generating
future consulting work.  :-(

(I don't think that applies to your list, where the root causes have
more to do with design-by-committee and the consequent need to make
everyone happy.)
-- Jerry


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


Re: Strength in Complexity?

2008-07-02 Thread Perry E. Metzger

Jack Lloyd [EMAIL PROTECTED] writes:
 Having been peripherally involved in the causation change for IKE, let
 me confess that it was caused by human stupidity destroying the
 alternatives. The author of the much cleaner spec asserted copyright
 and control over it, and fearing lawsuits, people turned to the
 the remaining alternative. A number of us were all to blame for the
 situation.

 Out of curiosity, was this other spec Photuris?

Sadly. That situation was long and complicated and I'd prefer not to
go into it -- and I'd prefer actually if others didn't either, as it
is much more about humans and non-security politics than it is about
security or cryptography.

Perry

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


Re: Strength in Complexity?

2008-07-02 Thread Pat Farrell
Perry E. Metzger wrote:
 Jack Lloyd [EMAIL PROTECTED] writes:
 Out of curiosity, was this other spec Photuris?
 
 Sadly. That situation was long and complicated and I'd prefer not to
 go into it -- and I'd prefer actually if others didn't either, as it
 is much more about humans and non-security politics than it is about
 security or cryptography.

Isn't this true in general about nearly all security or cryptography?

At CyberCash, where we had real RSA/DES in the system, we found that
users want convenience, not security

We built a paypal equivalent on top of our real security. Paypal made it
look like they had security, but were convenient.

Which company was sold for over a Billion? and which went bankrupt?

Most attacks are more social engineering than breaking crypto.

-- 
Pat Farrell
http://www.pfarrell.com/

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


Re: Strength in Complexity?

2008-07-02 Thread Hal Finney
 There are, of course, obstacles that must still be overcome by EKMI 
 proponents. For example, the proposed components are somewhat simple 
 by design, which concerns some encryption purists who prefer more 
 complex protocols, on the logic that they're more difficult to break 
 into.

Let me first say that from the discussion here I now get the impression
that this is how criticism of the EKMI spec is being characterized by its
supporters. Their critics are encryption purists. I'm not sure what
that means but it sounds kind of like people who believe in security
over simplicity.

An example where this concern might arise would be an overly simplistic
protocol that used AES in ECB mode - simple by design, while the
encryption purist advocated GCM, more difficult to break into but
more complex.  Now, I'm sure EKMI is not doing things this way but it
is an example where simple would not look good to encryption purists.

Hal Finney

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


Re: Strength in Complexity?

2008-07-02 Thread Arshad Noor

Hal Finney wrote:


An example where this concern might arise would be an overly simplistic
protocol that used AES in ECB mode - simple by design, while the
encryption purist advocated GCM, more difficult to break into but
more complex.  Now, I'm sure EKMI is not doing things this way but it
is an example where simple would not look good to encryption purists.



You are right, Hal.  EKMI does not support AES in ECB mode.

While this may not be acceptable to everyone, in SKSML version 1.0
we have chosen to currently support only the algorithms specified in
XML Encryption (http://www.w3.org/TR/xmlenc-core/#sec-Algorithms):

Block Encryption

   1. REQUIRED TRIPLEDES
  http://www.w3.org/2001/04/xmlenc#tripledes-cbc
   2. REQUIRED AES-128
  http://www.w3.org/2001/04/xmlenc#aes128-cbc
   3. REQUIRED AES-256
  http://www.w3.org/2001/04/xmlenc#aes256-cbc
   4. OPTIONAL AES-192
  http://www.w3.org/2001/04/xmlenc#aes192-cbc

Key Transport

   1. REQUIRED RSA-v1.5
  http://www.w3.org/2001/04/xmlenc#rsa-1_5
   2. REQUIRED RSA-OAEP
  http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

Message Authentication

   1. RECOMMENDED XML Digital Signature
  http://www.w3.org/2000/09/xmldsig#

Message Digest

   1. REQUIRED SHA1
  http://www.w3.org/2000/09/xmldsig#sha1
   2. RECOMMENDED SHA256
  http://www.w3.org/2001/04/xmlenc#sha256
   3. OPTIONAL SHA512
  http://www.w3.org/2001/04/xmlenc#sha512

Encoding

   1. REQUIRED base64
  http://www.w3.org/2000/09/xmldsig#base64

Even though SHA-384 does not appear on the XMLEnc digest list, we do
support it too (the underlying crypto libraries support it, so it was
no big deal to add it).  We will also recommend that SHA1 not be used,
along the timelines suggested by NIST, despite its appearance on this
list.

I understand that the W3C has started-up the XML Security WG again,
and as these standards are updated, we will follow their work and
support them in EKMI as appropriate.  Should there be requests from
the OASIS community that there be support for algorithms that are not
in XMLEnc, the Technical Committee will discuss and vote on it.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-02 Thread Peter Gutmann
Perry E. Metzger [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Peter Gutmann) writes:
 (Actually even that doesn't really explain something like IKE... :-).

Having been peripherally involved in the causation change for IKE, let me
confess that it was caused by human stupidity destroying the alternatives.

The reason why I was using IKE as an example is that it's a lot better-known 
than PKI.  That is, most people on the list know in general terms that PKI is 
a mess, but probably only a few who have had to read and implement some of the 
RFCs (http://www.ietf.org/html.charters/pkix-charter.html) know just how 
incredibly *bad* it really is - it's a perpetual motion machine [0] of 
incomprehensible, contradictory, unimplementable, and often entirely 
nonsensical requirements [1] for which, once you get beyond the simplest 
mechanisms, the behaviour of any one implementation is more or less arbitrary 
as authors have to take guesses at what the authors of the spec (and the 15 
other interfering specs in the same field) might have been thinking when they 
wrote it.  And unlike the IKE bakeoffs there's no interop testing, so there's 
no way to tell whether any two implementations will ever treat the same 
(nontrivial) cert in the same manner.  Unless you've had to implement PKI 
stuff it's difficult to convey the true horror of trying to make sense of 
those specs, which is why I've been using IKE as a better-known example.  If 
you're an IKE fan then mentally replace all occurrences with PKI :-).

Peter.

[0] Don't like some way of doing things?  Wait six months, three more RFCs
will be along to provide different (generally incompatible)
interpretations.
[1] Show of hands, how many people here not directly involved with X.509 work
knew that the spec required that all extensions in CA root certificates
(trust anchors in recent X.509 jargon) be ignored by an implementation?
So if you put in name constraints, key usage constraints, a policy
identifier, etc, then a conforming implementation is supposed to look at
them, throw them away, and proceed as if they weren't there?  More 
amusingly, if you mark a non-CA cert as trusted then the requirement to
ignore the extensions means that it can act as a trusted CA root 
certificate (with the same rights as, say, Verisign's root certs)
since the not-a-CA flags has to be ignored.

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


Re: Strength in Complexity?

2008-07-02 Thread James A. Donald

Peter Gutmann wrote:

For most crypto protocols, usability is job #8,107,
right after did we get the punctuation right in the footnotes for the third
appendix?.


Usability disasters such as DNSSEC are more common than strictly 
cryptographic disasters such as wifi.  DNSSEC is near impossible to use 
correctly end to end.


Usually a cryptographic system is very difficult to use correctly, or to 
use incorrectly - as for example various VPN products.


Sometimes a cryptographic system is easy to use incorrectly, difficult 
to use correctly, for example https and pretty much everything built on 
top of tls-ssl (old flame, never resolved, as to whether this is an 
inherent design flaw in the very concept of a cryptographic layer and 
any product that uses layering to factorize out the cryptographic code)


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


Re: Strength in Complexity?

2008-07-02 Thread Peter Gutmann
Pat Farrell [EMAIL PROTECTED] writes:

At CyberCash, where we had real RSA/DES in the system, we found that users
want convenience, not security

I think that's phrasing it a bit badly, it'd be better put as without
usability, you won't have users (see the Tor paper Challenges in deploying
low-latency anonymity for more thoughts on this).  This is why Skype is the
dominant internet phone protocol and every attempt at building encrypted VoIP
phones in the past ten years or so (anyone else here remember brew-a-stu?) has
languished among a small set of crypto geeks.  As Ian Grigg put it on his blog
a few years ago, It took longer to do the setting up of some security options
[in other software] than it takes to download, install, and initiate an
encrypted VoIP call over Skype with someone who has never used Skype before.

Peter.

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


Strength in Complexity?

2008-07-01 Thread Arshad Noor

The author of an article that appeared in InformationWeek this week
(June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):

http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937

states the following:

There are, of course, obstacles that must still be overcome by EKMI 
proponents. For example, the proposed components are somewhat simple by 
design, which concerns some encryption purists who prefer more complex 
protocols, on the logic that they're more difficult to break into.


In light of the recent discussions about experts in cryptography,
I thought I'd ask this forum to comment on the above author's
statement: is this true?

Do cryptography experts deliberately choose complexity over simplicity
when the latter might provide the same strength of protection?  Since I
do not consider myself a cryptography expert, and have instinctively
preferred simpler - but strong - technical solutions, have my instincts
been wrong all along?  TIA.

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-01 Thread Perry E. Metzger

Arshad Noor [EMAIL PROTECTED] writes:
 There are, of course, obstacles that must still be overcome by EKMI
 proponents. For example, the proposed components are somewhat simple
 by design, which concerns some encryption purists who prefer more
 complex protocols, on the logic that they're more difficult to break
 into.

 In light of the recent discussions about experts in cryptography,
 I thought I'd ask this forum to comment on the above author's
 statement: is this true?

 Do cryptography experts deliberately choose complexity over simplicity
 when the latter might provide the same strength of protection?

No. In fact, it is about as far from the truth as I've ever
seen. No real expert would choose to deliberately make a protocol more
complicated.

Complexity makes a protocol hard to analyze, and thus makes it hard to
know if the protocol is secure. The author of the quoted article, one
Dan Brown, clearly does not know how cryptographic protocol experts
analyze a protocol. (I've CCed him on this message to give him a
chance to reply, and I'll forward his replies if they're interesting.)

Indeed, I've often seen people forced to alter a protocol specifically
to make it analyzable -- see, for example, the JFK protocol that was
proposed in the IETF as an IKE replacement, which was formally
verified only after it had been changed specifically to improve the
ability to analyze it.

Complexity also makes secure implementation of a protocol much
harder. Indeed, it often makes it impossible to really know that an
implementation is secure even if it appears to meet the
specification. For example, see the numerous encoder flaws that have
been found over the years in protocols like SNMP specifically because
producing a safe ASN.1 compiler is so hard. For another example, see
the enormous interoperability challenges that people have had with
X.509 certificates, many of which have had security implications,
because the complexity has made proper operation in all instances
extremely difficult to implement.

Complexity also does not make something harder to break
into. Indeed, it is usually the complexity of a system that provides
the unintended edge conditions necessary to find a hole. If anything,
simple systems are (usually) harder to find flaws in.

In general, complexity is the enemy of security, and any real security
professional could tell you that. Simple and tractable is always
better than complicated, all things being equal -- certainly NOT
the other way around.

 Since I do not consider myself a cryptography expert, and have
 instinctively preferred simpler - but strong - technical solutions,
 have my instincts been wrong all along?

Your instincts are not wrong. The details of what is simple yet secure
are, of course, not trivial. You can make things *too* simple. A
Caesar cipher isn't secure, even though it is much simpler than
AES. That said, complexity is never something people deliberately
seek.


Perry

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


Re: Strength in Complexity?

2008-07-01 Thread Steven M. Bellovin
On Tue, 01 Jul 2008 12:12:26 -0700
Arshad Noor [EMAIL PROTECTED] wrote:

 The author of an article that appeared in InformationWeek this week
 (June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):
 
 http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937
 
 states the following:
 
 There are, of course, obstacles that must still be overcome by EKMI 
 proponents. For example, the proposed components are somewhat simple
 by design, which concerns some encryption purists who prefer more
 complex protocols, on the logic that they're more difficult to break
 into.
 
 In light of the recent discussions about experts in cryptography,
 I thought I'd ask this forum to comment on the above author's
 statement: is this true?
 
 Do cryptography experts deliberately choose complexity over simplicity
 when the latter might provide the same strength of protection?  Since
 I do not consider myself a cryptography expert, and have instinctively
 preferred simpler - but strong - technical solutions, have my
 instincts been wrong all along?  TIA.
 
No, no one competent would deliberately opt for complexity.  However,
there's a quote I've seen attributed to Einstein to remember:
Everything should be as simple as possible, but no simpler.
Sometimes, extra complexity is due to the need to deflect certain
attacks, such as replays and cut-and-paste.  It's quite possible that
the original, simpler design isn't resistant to some threats, either
because the designers weren't aware of them or because they felt that
they weren't credible in their environment.  Without more details than
are in the article (and I don't have the time or energy to read through
those documents), it's hard to say.  I did see one possible red flag in
the article: the key server verifies the client request, then
encrypts, digitally signs, and escrows the key in a database.
Escrowed keys are potentially *very* dangerous, but without knowing
just what's being stored and how it's being protected, I can't say more.


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

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


Re: Strength in Complexity?

2008-07-01 Thread Peter Gutmann
Arshad Noor [EMAIL PROTECTED] writes:

In light of the recent discussions about experts in cryptography, I thought
I'd ask this forum to comment on the above author's statement: is this true?

Do cryptography experts deliberately choose complexity over simplicity when
the latter might provide the same strength of protection?

It's true to some extent.  For most crypto protocols, usability is job #8,107,
right after did we get the punctuation right in the footnotes for the third
appendix?.

Peter.

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


Re: Strength in Complexity?

2008-07-01 Thread Peter Gutmann
Perry E. Metzger [EMAIL PROTECTED] writes:

No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.

IPsec.  Anything to do with PKI.  XMLdsig.  Gimme a few minutes and I can
provide a list as long as your arm.  Protocol designers *love* complexity.
The more complex and awkward they can make a protocol, the better it has to
be.

Peter.

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


Re: Strength in Complexity?

2008-07-01 Thread Arshad Noor

Steven M. Bellovin wrote:


I did see one possible red flag in
the article: the key server verifies the client request, then
encrypts, digitally signs, and escrows the key in a database.
Escrowed keys are potentially *very* dangerous, but without knowing
just what's being stored and how it's being protected, I can't say 
more.


I appreciate the affirmation from Perry and Steven (so far) that
I'm not off-base wrt designing security with simplicity in mind.
I will confirm that security has taken precedence over simplicity
where it was necessary to make a trade-off and where security was
the primary goal.

To respond to your concern, Steven, the escrowed symmetric keys
are encrypted using a Public Key from an asymmetric key-pair (the
recommended key-size is 2048-4096 bits RSA).

The Private Key of the RSA key-pair capable of decrypting the
escrowed keys is recommended to be generated and stored on a FIPS
140-2 Level 3 (or greater) certified HSM.

For activating the HSM to use the Private Key by the SKMS service,
it is recommended to use M of N FIPS-certified smartcards for strong
authentication, so that no single individual is capable of accessing
the Private Key (and consequently, any of the escrowed symmetric
keys) on their own.

(For those interested, an ACM paper on an earlier DRAFT version of
the protocol/architecture of the SKSML protocol is available at:
http://middleware.internet2.edu/idtrust/2008/papers/07-noor-ekmi.pdf
I hope to inform this forum of the public availability of a more
recent DRAFT of the protocol within the next two weeks, for review
and comments.  We, on the OASIS committee will be grateful for any
feedback we get from this forum).

My understanding of cryptography, after spending 9 years deploying
PKIs - large and small - is that it is necessary to use a combination
of strong technology and procedures for effective security.  Relying
on just one component alone can lead to a breakdown in security (as
my experience has shown me).

Arshad Noor
StrongAuth, Inc.

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


Re: Strength in Complexity?

2008-07-01 Thread Perry E. Metzger

[EMAIL PROTECTED] (Peter Gutmann) writes:
 Perry E. Metzger [EMAIL PROTECTED] writes:

No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.

 IPsec.  Anything to do with PKI.  XMLdsig.  Gimme a few minutes and I can
 provide a list as long as your arm.  Protocol designers *love* complexity.
 The more complex and awkward they can make a protocol, the better it has to
 be.

The problem, Peter, is that people who don't know you may mistake your
sarcasm for agreement with misconception in the article Arshad quoted.

Oh, and by the way, you missed half a dozen failed secure mail
protocols, SET (the Wikipedia article for SET really needs to be
changed from present to past tense), and 20 other easy examples. It is
sort of like shooting fish in a barrel, isn't it?

The point is not that fools (often including us) haven't built
monstrous ziggurats that failed. The point is that no one rational
should *SEEK* to make a protocol into monstrous ziggurat on the basis
that this will improve security, and don't pretend you don't agree,
because most of us know you better than that.

Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

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