Re: Crypto Craft Knowledge

2009-02-25 Thread Ben Laurie
Cat Okita wrote:
> On Sat, 21 Feb 2009, Peter Gutmann wrote:
>> This points out an awkward problem though, that if you're a commercial
>> vendor
>> and you have a customer who wants to do something stupid, you can't
>> afford not
>> to allow this.  While my usual response to requests to do things
>> insecurely is
>> "If you want to shoot yourself in the foot then use CryptoAPI", I can
>> only do
>> this because I care more about security than money.  For any
>> commercial vendor
>> who has to put the money first, this isn't an option.
> 
> That's not entirely true -- even commercial vendors have things like
> ongoing support to consider, and some customers just cost more money
> than they're worth.

Furthermore, its entirely simplistic to suggest that "money first" ==
"do any fool thing a customer demands". Some businesses do actually care
about their reputation, even if only because they believe that will make
them more money in the long run.

Plus, even the most accommodating company will draw the line somewhere -
not every foolish thing is profitable, even if a customer wants it.

-- 
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 majord...@metzdowd.com


Re: Crypto Craft Knowledge

2009-02-24 Thread Cat Okita

On Sat, 21 Feb 2009, Peter Gutmann wrote:

This points out an awkward problem though, that if you're a commercial vendor
and you have a customer who wants to do something stupid, you can't afford not
to allow this.  While my usual response to requests to do things insecurely is
"If you want to shoot yourself in the foot then use CryptoAPI", I can only do
this because I care more about security than money.  For any commercial vendor
who has to put the money first, this isn't an option.


That's not entirely true -- even commercial vendors have things like
ongoing support to consider, and some customers just cost more money
than they're worth.

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 majord...@metzdowd.com


Re: Crypto Craft Knowledge

2009-02-24 Thread Cat Okita

On Tue, 17 Feb 2009, James Hughes wrote:
I find this conversation off the point. Consider other trades like 
woodworking. There is no FAQ that can be created that would be applicable to 
building a picture frame, dining room table or a covered bridge. A FAQ for 
creating a picture frame would be possible, but this is not the FAQ that is 
being discussed.


You're thinking at the wrong level.

There are definitely FAQs that are applicable to building a picture
frame, a dining room table, or a covered bridge.

Woodworking FAQs can (and do) exist to teach basic skills, like sawing and 
measuring wood, different ways to join bits of wood together, and what 
types of join are most appropriate for what type of task.  Further, there

are discussions about things like load and stress, and what designs and
materials are best suited to what applications.

The same applies for implementing crypto -- teach the building blocks,
issues and judgement points required for good understanding and
implementation.

Ultimately it doesn't matter if they're building a picture frame, a
dining room table, or a covered bridge, as you've put it -- the skills,
materials and judgement of what to use where are what matters.

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 majord...@metzdowd.com


Re: Crypto Craft Knowledge

2009-02-23 Thread Peter Gutmann
Ben Laurie  writes:

>I totally agree, and this is the thinking behind the Keyczar project (
>http://www.keyczar.org/):

If we're allowed to do self-promotion I'll have to mention cryptlib, which had
as one of its principal design goals what was later stated by Ian Grigg as
"there should only be one mode and that is secure".  With cryptlib you have to
work very, very hard to do things insecurely (generally by resorting to
calling very low-level functions that the docs contain all sorts of dire
warnings about), and some things just can't be done at all, plaintext key
export being one really major sticking point that I get no end of complaints
about (if you really want the gory details you can get them at either
http://researchspace.auckland.ac.nz/handle/2292/2310 or at
http://www.springer.com/computer/security+and+cryptology/book/978-0-387-95387-8 
for a newer, cleaned-up version).

This points out an awkward problem though, that if you're a commercial vendor
and you have a customer who wants to do something stupid, you can't afford not
to allow this.  While my usual response to requests to do things insecurely is
"If you want to shoot yourself in the foot then use CryptoAPI", I can only do
this because I care more about security than money.  For any commercial vendor
who has to put the money first, this isn't an option.

Peter.

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


Re: Crypto Craft Knowledge

2009-02-20 Thread James Hughes


On Feb 14, 2009, at 12:54 PM, David Molnar wrote:


Ben Laurie wrote:

[snip discussion of bad crypto implementation practices]

Because he is steeped in the craft
knowledge around crypto. But most developers aren't. Most developers
don't even have the right mindset for secure coding, let alone  
correct
cryptographic coding. So, why on Earth do we expect them to follow  
our

unwritten rules, many of which are far from obvious even if you
understand the crypto?


Yes, there's a need for a "crypto practices FAQ" to which one can  
refer.

In addition to individual education, it'd be helpful to have something
when pointing out common mistakes.

[snip specific discussion]

I find this conversation off the point. Consider other trades like  
woodworking. There is no FAQ that can be created that would be  
applicable to building a picture frame, dining room table or a covered  
bridge. A FAQ for creating a picture frame would be possible, but this  
is not the FAQ that is being discussed.


Crypto protocol failures are not trivial. The recent CBC attack on SSH  
shows that this is the case.

http://secunia.com/Advisories/32760/
What FAQ would prescribe how not to make this mistake?

There are PhD programs related to this subject. I would argue (and  
actually dovetailing with another thread) that, if one creates a FAQ,  
that it point to well vetted implementations of information delivery  
protocols like SSL and SSH, and that any FAQ regarding the use of  
crypto libraries be that this is dangerous and should only be  
attempted with proper oversight and/or training.


Crypto protocols are not trivial, and suggesting a FAQ would be able  
to take the uninitiated to secure coding is more dangerous than good.



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


Re: Crypto Craft Knowledge

2009-02-20 Thread Ben Laurie
Stephan Neuhaus wrote:
> Many mistakes in crypto coding come from the fact that API developers
> have so far very successfully shifted the burden of secure usage to the
> application developer, the API user.  But I believe this hasn't worked
> and needs to be changed.

I totally agree, and this is the thinking behind the Keyczar project
(http://www.keyczar.org/):

"Cryptography is easy to get wrong. Developers can choose improper
cipher modes, use obsolete algorithms, compose primitives in an unsafe
manner, or fail to anticipate the need for key rotation. Keyczar
abstracts some of these details by choosing safe defaults, automatically
tagging outputs with key version information, and providing a simple
programming interface.

Keyczar is designed to be open, extensible, and cross-platform
compatible. It is not intended to replace existing cryptographic
libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is built
on these libraries."

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 majord...@metzdowd.com


Re: Crypto Craft Knowledge

2009-02-20 Thread David Molnar
Stephan Neuhaus wrote:

>> Yes, there's a need for a "crypto practices FAQ" to which one can refer.
> 
> I disagree because you cannot force developers to read (and understand)
> these FAQs.  Instead, there is a need for APIs that are difficult to use
> in an insecure way.  For example, Peter Gutmann's cryptlib makes it
> intentionally hard to get at private key material because of precisely
> this issue.  Also, I believe, cryptlib does not allow RSA in anything
> but ECB mode, because doing so means the developer is seriously on the
> wrong track here.

This is a good point, and it reminds me of this presentation from Rusty
Russell on "levels" of Linux kernel interfaces. See
http://ozlabs.org/~rusty/ols-2003-keynote/img39.html
and following.

The main issue I see is how do you force the developer to adopt your
library and corresponding API? A secondary issue is what do you do if
there isn't a suitable library and API yet available? In cases where you
can't (yet) provide a simple "use cryptlib" response, a crypto practices
FAQ would be helpful for pointing out common problems and explaining
them well.

I've started a wiki in case anyone wants to hack on such a FAQ:
http://www.cryptohygiene.org/

-David Molnar





signature.asc
Description: OpenPGP digital signature


Re: Crypto Craft Knowledge

2009-02-16 Thread David Molnar
Ben Laurie wrote:

[snip discussion of bad crypto implementation practices]
> Because he is steeped in the craft
> knowledge around crypto. But most developers aren't. Most developers
> don't even have the right mindset for secure coding, let alone correct
> cryptographic coding. So, why on Earth do we expect them to follow our
> unwritten rules, many of which are far from obvious even if you
> understand the crypto?

Yes, there's a need for a "crypto practices FAQ" to which one can refer.
In addition to individual education, it'd be helpful to have something
when pointing out common mistakes. For example, I was involved recently
in a discussion about MAC'ing prices returned by a shopping cart web
application:
http://news.ycombinator.com/item?id=477398

There's at least two gotchas here to consider:

1) The choice of MAC (i.e. why use HMAC instead of H(s||m) or H(m||s) ?)
2) replay attacks if the MAC'd item is not bound to the transaction or
the rest of the web page

I can point out these issues, but I don't usually have time to write
fully detailed examples. Having such examples goes a long way towards
increasing one's credibility in this kind of discussion. Ideally they
would be from deployed applications, but that's tough.

-David Molnar




signature.asc
Description: OpenPGP digital signature


Re: Crypto Craft Knowledge

2009-02-14 Thread Anne & Lynn Wheeler


On 02/14/2009 07:18 AM, Ben Laurie wrote:

Actually, in my extensive experience of reviewing security-critical
code, this particular error is extremely common. Why does Michael assume
that they probably wouldn't? Because he is steeped in the craft
knowledge around crypto. But most developers aren't. Most developers
don't even have the right mindset for secure coding, let alone correct
cryptographic coding. So, why on Earth do we expect them to follow our
unwritten rules, many of which are far from obvious even if you
understand the crypto?

[1]
http://www.lightbluetouchpaper.org/2009/02/02/hidden-assumptions-in-cryptographic-protocols/



Note that one of the things that FSTC did in e-check (and I did in
x9.59) was specify the fields from existing transport infrastructures
that were used for signing.

Part of this was that standard digital signature processes (along with
digital certificates if necessary) could represent a one hundred times
factor payload bloat ... some past comments about various efforts that
tried to apply knee-jerk application of digital signatures to existing
financial infrastructures ... resulting in two orders of magnitude
payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

One of the side-effects of some of the extreme bloated approaches was
that they actually avoided defining end-to-end protocol ... just defined
a digitally signed operation for flow over the internet ... which was
then stripped off and thrown away at the gateway to the "real" infrastructure.

In any case, as a result, the fields from standard existing financial
transaction was specified for encoding ... that was signed ... and then just
the digital signature was appended to existing formatted message.

At the receiving end, the fields were re-encoded and verified with
the transmitted digital signature.

The issue for FSTC that prompted FSML ... was that at the time, the
encoding standards weren't deterministic (i.e the sender and
the recipient had to use the same encoding rules ... so the signed
encoding and the verified encoding were the same). FSML was then
contributed to W3C and incorporated into the XML digital signature
standard.

in that sense, neither e-check nor X9.59 required a length field
... they just specified all the encoded transaction fields that were
necessary for characterizing a transaction unambiguously.

As an aside ... we didn't particularly come at it from the stand-point
of crypto craft or even security-critical craft ... we came at it
from standpoint of business-critical craft ... where things might
fail in a multitude of ways (some possibly having nothing to do
with security). slightly related recent post mentioning FAA ATC
system:
http://www.garlic.com/~lynn/2009c.html#17 Bletchly Park fires up Big Green-Eyed 
Monster

Another example was we did "audits" of RAID disk arrays
... looking for design &/or implementation shortcomings
thatmight result in loss of data.

In the "security" context ... we did some audits where
we identified (nearly trivial) exploits in end-to-end operation
... and were told that wasn't part of the security protocol.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

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