Re: Simple SSL/TLS - Some Questions

[Anne & Lynn Wheeler]

At 08:38 PM 10/7/2003 -0400, Ian Grigg wrote:

You are not being fair, Lynn, you are hijacking
the name of TLS, in order to promote a protocol
to protect credit cards.
What you described was practically nothing to do
with TLS/SSL...
Such a protocol would be quite useful no doubt,
but it has little to do with TLS' design goal of
being a full service channel security product.
what i said was that it was specifying a simplified SSL/TLS based on the 
business requirements for the primary use of SSL/TLS  as opposed to a 
simplified SSL/TLS based on the existing technical specifications and 
existing implementations.

I don't say it was technical TLS  I claimed it met the business 
requirements of the primary use of SSL/TLS.

I didn't preclude that there could simplified SSL/TLS based on existing 
technical specifications as opposed to implementation based on business 
requirements for the primary use.

I thot I was very fair to distinguish between the business requirements use 
of SSL/TLS as opposed to technical specifications for SSL/TLS.

There are lots of really great implementations in this world  many of 
which have absolutely no relationship at all with a good business reason to 
exist.

The real observation was that in the early deployments of SSL  it was 
thot it would be used for something entirely different ... and therefor had 
a bunch of stuff that would meet those business requirements. However, we 
come to find out that it was actually being used for something quite a bit 
different with different business requirements.

So a possible conjecture is that if there had been better foreknowledge as 
to how SSL was going to be actually be used  one might conjecture that 
it would have looked more like something I suggest (since that is a better 
match to the business requirements) ... as opposed to matching some 
business requirements for which it turned out not to be used.

As to usefulness  I wasn't really trying to claim it would be useful 
 just that it would meet the business requirements of its primary use.

I've repeatedly claimed that the credit card number in flight has never 
been the major threat/vulnerability  the major threat (even before the 
internet) has always been the harvesting of the merchant files with 
hundreds, thousands, tens of thousands, even millions of numbers  all 
neatly arranged.

The issue that we were asked to do in the X9A10 working group was to 
preserve the integrity of the financial infrastructure for all electronic 
retail payments.  A major problem is that in the existing infrastructure, 
the account number is effectively a shared-secret and therefor has to be 
hidden. Given that there is a dozen of business processes that require it 
to be in the clear and potentially millions of locations  there is no 
practical way of addressing integrity of such a shared-secret ((you could 
burry the earth to the depth of a couple miles with cryptography  and 
it still wouldn't alleviate the threat).

It turns out that once the account number is no longer a shared-secret  
then it is no longer necessary to hide it in order to preserve the 
integrity of the financial infrastructure. At that point, a primary 
existing use of SSL/TLS goes away completely.

I wasn't really to hijack the protocol  however, if you wanted to 
simplify something based on the business requirements of its use ... then 
one might consider simplifying based on the business requirements of its 
use (even if it became somewhat different). My strong preference (by 
several orders of magnitude) is to not do anything to contribute to delays 
of eliminating account numbers as shared-secrets (that would include not 
contributing to an extreme KISS TLS other than a hypothetical mental 
exercise related to business justification as a reason for doing something)..

I would prefer the primary justification for SSL/TLS to totally 
disappear  There then might remain some other uses that could benefit from 
SSL/TLS  and they might not have a need for simplification at all.

Frequently when simplification is done to something  you throw away 
stuff that isn't needed (at least for the targeted business purpose). The 
issue in extreme KISS TLS  at what point has it become so simple that 
it can no longer be TLS  ... aka what is the minimal simple set of things 
needed for something to still be TLS?

simple result of the x9a10 working group to preserve the integrity of the 
financial infrastructure for all electronic retail payments  and 
eliminate account numbers as shared-secrets
http://www.garlic.com/~lynn/index.html#x959

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Simple SSL/TLS - Some Questions

[Ian Grigg]

Anne & Lynn Wheeler wrote:
> 
> At 12:09 PM 10/7/2003 -0700, Eric Rescorla wrote:
> >This doesn't provide equivalent services to TLS--no anti-replay
> >service for the server.
> 
> KISS ... for the primary business requirement  the application already
> has anti-replay  TLS ant-replay is then redundant and superfluous.

Well, that is correct, all financial cryptography
protocols will have end-to-end replay, and in this
sense, the anti-reply of TLS is not needed / gets
in the way if one is doing financial stuff.

( I've recently discovered this wierdness in Java where
it automatically launches the entire POST again if
it sees a problem, thus resulting in two transaction
requests.  Of course, the protocols pick it up and
there is no danger, but I can't figure out how to
easily stop the client side telling the user that
the transaction had already been done )

> yes, it isn't existing TLS  it is KISS TLS based on primary business
> requirement ... as mentioned in original,  not on existing specification
> for existing implementation
> http://www.garlic.com/~lynn/aadsm15.htm#19


You are not being fair, Lynn, you are hijacking
the name of TLS, in order to promote a protocol
to protect credit cards.

What you described was practically nothing to do
with TLS/SSL...

Such a protocol would be quite useful no doubt,
but it has little to do with TLS' design goal of
being a full service channel security product.

iang

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

Re: Simple SSL/TLS - Some Questions

[Anonymous]

Ian Grigg wrote:
> Jill Ramonsky wrote:
> > (3) MULTIPLY SIGNED CERTIFICATES
..snip..
> I don't believe it is possible to multiply-sign
> x.509 certs.  This is one of the reasons that
> PKIs based on x.509 have a miserable record, as
> the absence of any web of trust support and the
> promoting of a hierarchical trust model goes
> against most business and individual practices.
..snip..
> But, what's the point to the question?  I'm
> not quite sure how this relates to the essential
> question of implementing TLS?

I suspect the reason for wanting multiply signed certs in a simple TLS implementation 
is that the primary targets for such a library are P2P applications.  Most encrypted 
P2P apps use roll-your-own link encryption, probably in an insecure manner.  They'd 
certainly benefit from a secure protocol like TLS, using self-signed certs SSH-style 
for node identification where appropriate.  They would also probably benefit from a 
PGP-style web of trust.  If it's not possible to implement this using x.509 certs, 
perhaps the effort would be better spent deriving a protocol variant that meets those 
needs.

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

Re: Other OpenSSL-based crypto modules FIPS 140 validated?

[Ben Laurie]

Peter Gutmann wrote:

> "Nathan P. Bardsley" <[EMAIL PROTECTED]> writes:
> 
> 
>>Anecdotally, I've heard that there are many, but almost all of them were done
>>by vendors for embedding in their proprietary products.
> 
> 
> Ditto.  The problem is that when vendors have spent $100K+ on the
> certification, they're very reluctant to give anyone else (and specifically
> their competitors) the benefits of their expenditure, so you end up getting
> the same thing re-certified over and over for private use, rather than a
> single generally-usable version being certified.

Which is, of course, what we are trying to fix. And yeah, there are
others using OpenSSL. And if they don't say so, they're in breach of the
licence.

Cheers,

Ben.

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

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


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

Re: Simple SSL/TLS - Some Questions

[Eric Rescorla]

Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:

> At 12:09 PM 10/7/2003 -0700, Eric Rescorla wrote:
> >This doesn't provide equivalent services to TLS--no anti-replay
> >service for the server.
> 
> KISS ... for the primary business requirement  the application
> already has anti-replay  TLS ant-replay is then redundant and
> superfluous.
>
> yes, it isn't existing TLS  it is KISS TLS based on primary
> business requirement ... as mentioned in original,  not on existing
> specification for existing implementation

But calling it "KISS TLS" is very inaccurate, since it
doesn't provide equivalent security guarantees. What you're
proposing doesn't really have any connection to TLS.

> Making it significantly more simple and lightweight might encourage it
> to be used more extensively.

Extensive performance analysis shows that the performance cost
in TLS is cryptography, not message passing. Your suggestion
doesn't improve that much at all.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Simple SSL/TLS - Some Questions

[Anne & Lynn Wheeler]

At 12:09 PM 10/7/2003 -0700, Eric Rescorla wrote:
This doesn't provide equivalent services to TLS--no anti-replay
service for the server.
KISS ... for the primary business requirement  the application already 
has anti-replay  TLS ant-replay is then redundant and superfluous.

yes, it isn't existing TLS  it is KISS TLS based on primary business 
requirement ... as mentioned in original,  not on existing specification 
for existing implementation
http://www.garlic.com/~lynn/aadsm15.htm#19

when doing the original deployment stuff
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
there was the idea in would be used for the whole online experience. The 
subsequent comments was that it got cut back to the current primary use 
 because it imposed a five-fold overhead increase (or reduced a server 
service capacity by 80 percent).

Making it significantly more simple and lightweight might encourage it to 
be used more extensively.

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Simple SSL/TLS - Some Questions

[Eric Rescorla]

Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> the client generates a random session key according to the crypto
> preferences, encrypts a credit card number and misc. ancillary
> transaction info with the session key, encrypts the session key with
> the public key (if you really want to simplify to the business
> requirements, directly encrypt with the public key and eliminate the
> session key step)
This doesn't provide equivalent services to TLS--no anti-replay
service for the server.

>  and use a XTP-like (or some of the emerging
> real-time protocol)  aka existing SSL is carried on top of TCP
>  TCP requires a minimum of 7 packet exchange  and SSL on top
> of that then requires all the negotiation chatter.
With the result that it is now screened out by your current
firewall policies. Good idea.

> This is about as simplified SSL/TLS as you can get based on business
> requirements for the major existing applications using SSL/TLS
This also isn't TLS. It's a protocol that bears some vague resemblence
to TLS.

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Simple SSL/TLS - Some Questions

[Anne & Lynn Wheeler]

At 05:55 PM 10/3/2003 +0100, Jill Ramonsky wrote:
Having been greatly encouraged by people on this list to go ahead with a 
new SSL implementation, it looks like I am going to go for it, but I'd 
kinda like to not make any enemies in the process so I'll try to keep this 
list up to date with progress and decisions and stuff ... and I will ask a 
lot of questions.
really KISS/simple SSL/TLS  given the business requirements for 
existing use (as opposed to existing technical specifications for existing 
implementations) is to register server's public key and crypto preferences 
in DNS  when client calls DNS to get ip-address ... they can also 
request public key & crytpo preferences be returned in the same 
transmission. for transition purposes, the public key, crypto preferences, 
etc  can exist in a authoritative signed message by some generally 
recognized trusted party  a mini-certificate (if you will).

the client generates a random session key according to the crypto 
preferences, encrypts a credit card number and misc. ancillary transaction 
info with the session key, encrypts the session key with the public key (if 
you really want to simplify to the business requirements, directly encrypt 
with the public key and eliminate the session key step)  and use a 
XTP-like (or some of the emerging real-time protocol)  aka existing SSL 
is carried on top of TCP  TCP requires a minimum of 7 packet exchange 
 and SSL on top of that then requires all the negotiation chatter.

Having the public key (& possibly crypto preferences  unless you want 
to directly encrypt with the public key) piggy-back with the DNS request 
 then the actual transaction can be done in three-packet exchange (i.e. 
XTP defines a minimum three-packet exchange for reliable transaction).

This is about as simplified SSL/TLS as you can get based on business 
requirements for the major existing applications using SSL/TLS

some past related comments
http://www.garlic.com/~lynn/subtopic.html#sslcerts
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Simple SSL/TLS - Some Questions

[Ian Grigg]

Jill Ramonsky wrote:

>  > The only question I wasn't quite sure of
>  > was whether, if I take your code, and modify it,
>  > can I distribute a binary only version, and keep
>  > the source changes proprietary?
> 
> You can't distribute a binary only version of ANY crypto product,
> surely? No crypto product can EVER be trustworthy unless you can see the
> source code and verify that it has no back doors, and then compile it.
> Unless you give your users the power to inspect the source code, and
> /know/ that it is the source code (because they can actually compile it
> and run the resulting executable) then you could have put all sorts of
> back doors into it. You could have added password theft, key escrow, who
> knows what?
> 
> Don't get me wrong. I agree with you that crypto has enough barriers
> already, and I would like to produce something that is as freely
> distributable as possible. "For the masses" crypto is, I guess, an
> unwritten design goal. But allowing people to hide the crypto source
> from crypto users would allow the bad guys (you can define your own bad
> guys) to produce Trojan Horse crypto. Closed source crypto is to all
> intents worthless. (In my opinion). Please feel free to argue that I'm
> wrong.


You - or others - are talking about putting your TLS
thingie in an embedded device?  Like a toaster, for
sake of discussion, because we don't want the bad guy
to see us doing white bread in the mornings :-)

Are you envisaging a world where a toaster owners must
be permitted to inspect and rebuild the crypto code in
their toaster so as to be sure that there are no back
doors?

And, are you envisaging a world where you could do more
good by forcing this viewpoint on the manufacturers of
toasters, as opposed to a world where a manufacturer of
toasters decides that, regardless of the possible presence
of backdoors, they think it better than the user cannot
see the crypto in the toaster?

If so, then you need to craft some source code availability
clause into the licence.  That would mean more like Mozilla,
and definately not like BSD/MIT and the rest.  (And maybe
like GPL, as suggested by Jerry.)

Also, note that OpenSSL - your erstwhile competitor -
is under Apache licence and that has no such limit,
AFAIK.

In practice, what you are suggesting doesn't work.  It
is pretty nigh impractical to take a set of open source,
and a finished deliverable crypto product, and show that
one was used to build the other.  This is because the
compilation process is not really deterministic and
duplicable, across a variety of times & machines &
tools.

In essence, a developer uses the open source if he wants
to be sure.  Anyone using a binary only product makes that
choice.


>  > My own philosophy has always been that crypto has
>  > enough barriers on it already, so it should not
>  > add any more personality quirks than necessary,
>  > hence preference for BSD two clause.  Mind you,
>  > such a statement is a personality quirk, so you
>  > be your own judge.
> 
> Eek. Was my paragraph above a personality quirk? I thought it was a
> sound cryptographic principle.


As a highly general comment, when we get to something
along the lines of "you must do it like I say" then you
have to apply the God test. Are we that omniscient?  Can
we really support the case that we know how this is best
used?

For every successful god, there are a thousand who found
themselves forgotten and unmartyred.  RMS is one of the
few exceptions;  he crafted a prisoners' dilemma that
stretched broad and created a community of programmers.
I can't think of any similar successes in the field of
cryptography, although there are claims.

So, the question you have to ask yourself is, does that
arrangement he crafted - GPL or something similar - have
sufficient merit that it should be applied to crypto?

My call is "no" as I really don't want any user of my
crypto to actually have to think at all about my own
beliefs.  I want him to use it as fast and as furiously
as possible.  (There are many who disagree with this,
but that is orthogonal to the licensing issue.)  I
admire the game theory behind the GNU licence, but we
should also note the very large number of companies
that won't touch it because of the costs that it brings.

Now, there are a few GNU crypto products out there.
Also, please don't believe that I have much confidence
in the call!  What you might want to do is to check
how other GNU crypto products have faired, it would
be a useful exercise.


>  > Q:  Does your employer  have any say or comment
>  > on this project?  Might be wise to clear up the
>  > posture, and either get it in writing, or make
>  > the repository public from the git-go.  Many an
>  > open source project has foundered when the boss
>  > discovered that it works...
> 
> It has absolutely nothing whatsoever to do with my employer. All my code
> will be written at home in my spare time, and uploaded to CVS or
> whatever also from home. It is true tha

Re: NCipher Takes Hardware Security To Network Level

[Dave Howe]

Peter Gutmann wrote:
> Uhh, so you're avoiding privilege escalation attacks by having
> everyone run as root, from which you couldn't escalate if you wanted
> to.
Indeed so.
"What do you do to prevent ordinary users from abusing access to the
software"
"we don't allow them on - only admins can use this machine"
"but ordinary users will *have* to use this machine"
"yes, but they will be admins while they do it"
"oh, ok then" 

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

Re: Open Source (was Simple SSL/TLS - Some Questions)

[Jerrold Leichter]

| Maybe the solution should be this: You can distribute the binary without
| any source code whatsoever, and use this toolkit, unrestricted, in
| whatever manner you choose, provided that EITHER you distribute the
| source code for the whole product in a form which allows the user to
| reconstruct a working executable from the source code, OR you include a
| message which says something like "Warning - this product is closed
| source. If you rely on its crypto features, you do so at your own risk".
No commercial software is ever going to use your software based on those
requirements.  Oh, sure, the software vendors all write language into their
contracts that try to dump all the risk on the buyer - and the current
attempts at a class action suit against Microsoft may determine the degree to
which the courts let them get away with it.  But no one is going to let you
impose *your* language on the way they talk to their customers - unless you
make your requirement so mealy-mouthed that it's pointless, or you allow them
to hide the language so deep that no one ever sees it.

At some point, you need to decide whether you are doing this in service to
some kind of idealism about perfect cryptography for the masses, or whether
you want to improve the state of the world by making it easier for honest
vendors to easily provided good crypto.

I'll let my bias show:  If the vendor of your software wishes to attack you,
there's not a hell of a lot you can do about it.  It's just too hard to hide
things, if you set your mind to it.  Even accidental bugs take huge effort to
find - whether you believe that "all bugs are shallow to sufficiently many
eyes" or not, there's no bug-free open-source software out there any more than
there's bug-free closed-source (...which may simply mean that there aren't
sufficiently many eyes - but there likely never will be.)  *Deliberate* bugs
in a system of significant size?  I can't even imagine the effort necessary to
gain assurance that there aren't any, given the current state of the art.
(Sure, in an eventual world with multiple independent proved-secure compilers
and libraries for safe languages, verifiers, proof-carrying code or some such
technique ... maybe.  But the necessary infrastructure is currently way beyond
the state of the art for all but very specialized, limited domains.)

-- Jerry

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

Re: Simple SSL/TLS - Some Questions

[Ralf Senderek]

On Mon, 6 Oct 2003, Ian Grigg wrote: (answering Jill's questions)

> The only question I wasn't quite sure of
> was whether, if I take your code, and modify it,
> can I distribute a binary only version, and keep
> the source changes proprietary?

I'd strongly recommend to think about some code-signing which would
best be included in the source code but could as well be distributed
as separate signature files. Including a note in your licence (whatever
it will turn out to be) this will not only help to spot and reject
unauthorized and dubious attempts to "improve" your code but
will also deter those who might call your code "crap" without having
seen the "real thing".

Good luck.

Ralf

*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
* Ralf Senderek  <[EMAIL PROTECTED]> http://senderek.de  *  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: NCipher Takes Hardware Security To Network Level

[Anton Stiglic]

- Original Message - 
From: "Peter Gutmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 11:07 AM
Subject: Re: NCipher Takes Hardware Security To Network Level


> "Anton Stiglic" <[EMAIL PROTECTED]> writes:
>
> >This is why you get requirements of the type that it should run on
Windows in
> >single-user mode, which I take to mean have only an admin account.  This
> >prevents privilege escalation attacks (regular user to root) that are
easily
> >done.
> >
> >I think this is reasonable, since you really are relying on the OS and
the PC
> >for the security of the module.
>
> Uhh, so you're avoiding privilege escalation attacks by having everyone
run as
> root, from which you couldn't escalate if you wanted to.  This doesn't
strike
> me as a very secure way to do things (and it would still get MSDOS
certified,
> because you've now turned your machine into a DOS box protection-wise).

Did you read the security policy of Netscape Security Module?  Basically,
if you want to get the configuration that is FIPS 140 certified, you need
to install the module on a PC and add tamper resistant seals over
appropriate
interfaces, junctions and fasteners of all doors and covers in the enclosure
of the PC, so that you can't open the cover without the fact being
physically
noticeable.  I suggest adding some duct tape in strategic positions for
additional
security :).

By reasonable I mean in the framework of having a general purpose software
cryptographic library be certified FIPS.  I'm not saying I find this secure.
When I see a software library being certified FIPS 140, I say to myself it
must
implement the cryptographic algorithms in a descent way, has a descent
random number generator, and stuff like that.  I don`t care much about the
physical boundary that they artificially determine.

If I want high security, I will go with hardware.  At the end of the line,
what
you want to protect is your secret keys, and if you don't have a tamper
resistant
hardware (that zeroizes your secrets when someone tries to poke at it)
to do that it is difficult if not impossible.

--Anton


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

Re: Protocol implementation errors

[Peter Gutmann]

Markus Friedl <[EMAIL PROTECTED]> writes:
>On Sat, Oct 04, 2003 at 05:58:49PM +1200, Peter Gutmann wrote:
>> We've already seen half the
>> SSH implementations in existence taken out by the SSH malformed-packet
>> vulnerabilities,
>
>I don't think so.

According to the CERT advisory, roughly half of all known SSH implementations
are vulnerable (some of the vendor statements are a bit ambiguous), and the
number would have been higher if it weren't for the fact that several of the
non-vulnerable implementations share the OpenSSH code base (there are a number
of implementations not in the advisory, but we can take it as being a
representative sample).

The reason I appear to be defending ASN.1 here is that there seems to be an
irrational opposition to it from some quarters (I've had people who wouldn't
recognise ASN.1 if they fell over it tell me with complete conviction that
it's evil and has to be eradicated because... well just because).  I don't
really care about the religious debate one way or the other, I'm just stating
that from having used almost all of the bit-bagging formats (starting with PGP
1.0) for quite a number of years, ASN.1 is the one I feel the most comfortable
with in terms of being able to process it safely.

Incidentally, if anyone wants to look for holes in ASN.1 data in the future,
I'd be really interested in seeing what you can do with malformed X.509 and
S/MIME data.

Peter (who's going to look really embarrassed if the NISCC test suite finds
   problems in his ASN.1 code :-).

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

Re: NCipher Takes Hardware Security To Network Level

[Peter Gutmann]

"Anton Stiglic" <[EMAIL PROTECTED]> writes:

>This is why you get requirements of the type that it should run on Windows in
>single-user mode, which I take to mean have only an admin account.  This
>prevents privilege escalation attacks (regular user to root) that are easily
>done.
>
>I think this is reasonable, since you really are relying on the OS and the PC
>for the security of the module.

Uhh, so you're avoiding privilege escalation attacks by having everyone run as
root, from which you couldn't escalate if you wanted to.  This doesn't strike
me as a very secure way to do things (and it would still get MSDOS certified,
because you've now turned your machine into a DOS box protection-wise).

>More scary to me is stuff like "DSSENH does not provide persistent storage of
>keys.  While it is possible to store keys in the file system, this
>functionality is outside the scope of this validation."

That's the "Define the bits that we can easily get away with to be secure and
ignore the rest" approach that I commented on.  It was actually part of a
posting to another list where I was poking fun at BS 7799:

-- Snip --

Some years ago I witnessed a BS 7799 security certification being done.  For
those of you who aren't familiar with this, it's ISO 9000 for security.  It
went something like this:

  First, we define the region from the rug in the corner to Dave's desk to the
  pot-plant on the right to be... SECURE.  Everything inside this region is by
  definition SECURE.  Everything outside the region is none of our concern.
  Access to the server room from the SECURE area is by locked door.  The keys
  are on a hook on the wall, but since the hook is outside the SECURE area, we
  don't have to worry about that.

  Now we need to produce a lot of paperwork.  I'll help you with this, it
  should only take a few weeks.

  Congratulations, you now have a BS 7799-certified SECURE facility.  Here's
  my bill.

In other words they didn't change anything at all in their insecure (except in
the eyes of BS 7799) work area.  The whole certification process was an
exercise in meeting the certification requirements purely through the
production of paperwork.

-- Snip --

The SECURE facility has since been decomissioned, so I guess it's safe to talk
about it now.  Incidentally, almost everyone knew where the key was because
the room in question had the best air-conditioning in the building (it was
packed full of servers and networking gear), so it became quite popular in the
summer with the sysadmins, who'd find various reasons to do extended amounts
of work in there.

Peter.

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

RE: Simple SSL/TLS - Some Questions

[Jerrold Leichter]

| From: Jill Ramonsky <[EMAIL PROTECTED]>
|  > From: Ian Grigg [mailto:[EMAIL PROTECTED]
|  >
|  > The only question I wasn't quite sure of
|  > was whether, if I take your code, and modify it,
|  > can I distribute a binary only version, and keep
|  > the source changes proprietary?
|
| You can't distribute a binary only version of ANY crypto product,
| surely? No crypto product can EVER be trustworthy unless you can see the
| source code and verify that it has no back doors, and then compile it.
| Unless you give your users the power to inspect the source code, and
| /know/ that it is the source code (because they can actually compile it
| and run the resulting executable) then you could have put all sorts of
| back doors into it. You could have added password theft, key escrow, who
| knows what?
This sounds nice in principle, but if you follow that where it goes, you are
left with GPL - not even LGPL.  There's no way for a library to protect itself
against code it is linked with.  (Where's TOPS-20 when you need it)  Even
if you let me completely rebuild the crypto library you've shipped with your
product, why should I trust it?

| Don't get me wrong. I agree with you that crypto has enough barriers
| already, and I would like to produce something that is as freely
| distributable as possible. "For the masses" crypto is, I guess, an
| unwritten design goal. But allowing people to hide the crypto source
| from crypto users would allow the bad guys (you can define your own bad
| guys) to produce Trojan Horse crypto. Closed source crypto is to all
| intents worthless. (In my opinion). Please feel free to argue that I'm
| wrong.
This is not really a soluable problem.  Going full GPL will render your project
useful for just about any commercial use.  Anything less leaves even someone
with the necessary skills, desire, and time in a position where they can't
say anything meaningful about the system in which the code is embedded.

|  > Q:  Does your employer  have any say or comment
|  > on this project?  Might be wise to clear up the
|  > posture, and either get it in writing, or make
|  > the repository public from the git-go.  Many an
|  > open source project has foundered when the boss
|  > discovered that it works...
|
| It has absolutely nothing whatsoever to do with my employer. All my code
| will be written at home in my spare time, and uploaded to CVS or
| whatever also from home. It is true that I happen to be sending this
| email from work, but even that's in my own time. I don't see how they
| have any say. To be /really/ safe,  I'd be happy to always post to this
| list only from home, but right now I don't think it's a problem.
Check your employment contract carefully.  Many contracts these days basically
say "if you invented/developed/wrote it while you worked for us, it's ours".
(Sometimes there are provisions like "if it's related to what we sell", but
when you look more closely, they will define "what we sell" so broadly - and
then add the ability to change their minds later anyway - that it doesn't
change anything.)

Lawsuits about this sort of stuff get ugly and *very* expensive.  Just because
your current employer is reasonable doesn't mean it won't be acquired by
someone who isn't.  Doing a bit of up-front checking is only prudent.

BTW, someone remarked in another issue that you could put of your choice of
license from among a variety of possibilities until later.  Well ... yes and
no.  Once something goes out the door under less restrictive terms, you can't
add restrictions later.  Let a copy go out with the phrase "released to the
public domain" and it's no longer yours - it's everyone's.  Let it out under
a BSD license, and you can't apply GPL terms later.  (You can apply stricter
terms to new versions, but if you try that, the resulting confusion will kill
any possibilities of broad acceptance:  You'll end up with a competition
between your restrictive versions and evolved versions of less-restrictive
ones that other people do because they aren't willing, or can't accept your
later restrictions.)
-- Jerry

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

Re: Open Source (was Simple SSL/TLS - Some Questions)

[Rich Salz]

>  I took the initial view that closed source and trustable
> crypto are mutually incompatible

Of course this isn't true.  When is the last time you built your
own ATM or credit-card POS terminal?

> Claims such
> as "Download this app and you will be secure" should definitely need to
> be proven, and if the app is built with TLS++ that would mean
> distributing the source code.

That's not enough.  Are you validating the toolchain?  (See Ken Thompson's
Turing Aware lecture on trusting trust).  Are you going to prevent
users from storing private keys in world-readable files?  Think very
carefully before you make *any* claims about what features your software
will provide, and what is necessary to truly ensure those features.
Are you planning on taking real liability here?   That would be a first
in the software world.

> I don't want to restrict the distribution of TLS++, but I
> also don't want crippled versions of it being used to fool the public.

Do you really think that someone who wants to fool the public will
be deterred by a LICENSE.txt file in an open source distribution?

> If anyone could help me to outline a reasonable possibility?

I think that rather than spending time on deciding what to call this
library that is to-be-written, and how to license this library that is
to-be-written, that time should be spent on, well, writing it. :)
/r$
--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

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

Re: Open Source (was Simple SSL/TLS - Some Questions)

[Florian Weimer]

Jill Ramonsky wrote:

> Example. You're a company. You build hardware devices which need to talk 
> to each other securely. (Say, ATMs for example). Obviously it wouldn't 
> make sense for that company to have to supply its ATM-using-customers 
> with the source code of the ATMs.

Who's the customer, the one that buys and deploys the ATMs, or the
actual customer who interacts with it?

I can only recommend to demand source code before purchase/deployment,
especially for embedded devices which are supposed to communicate
securely over an untrusted network.  Custom crypto protocols appear to
be quite common in this area.

Even if you lack the necessary time and experience to detect subtle
flaws in the implementation, it's likely that you'll discover a few
surprises.  Did you know that proprietary Blowfish libraries exist which
are extremely easy to use?  They even provide a default key which is
used unless another key is imported explicitly.  This neatly solves all
key management problems.  (The key, by the way, is the third one you
would check if you had to guess it.)

> This is an important question (for me, at least) since it affects the 
> licensing of the yet-to-be-written TLS++ project.

There are few licenses today which require distribution of source code
to end users if they don't receive binaries.  One prominent exception is
the Afferro (sp?) GPL.

> Maybe the solution should be this: You can distribute the binary without 
> any source code whatsoever, and use this toolkit, unrestricted, in 
> whatever manner you choose, provided that EITHER you distribute the 
> source code for the whole product in a form which allows the user to 
> reconstruct a working executable from the source code, OR you include a 
> message which says something like "Warning - this product is closed 
> source. If you rely on its crypto features, you do so at your own risk".

If you want to see widespread adoption of your Better TLS Library, you
should avoid such licensing experiments.  Use a BSD or MIT-style
license instead.

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

Re: Protocol implementation errors

[Markus Friedl]

On Sat, Oct 04, 2003 at 05:58:49PM +1200, Peter Gutmann wrote:
> Bill Frantz <[EMAIL PROTECTED]> writes:
> 
> >This is the second significant problem I have seen in applications that use
> >ASN.1 data formats.  (The first was in a widely deployed implementation of
> >SNMP.)  Given that good, security conscience programmers have difficultly
> >getting ASN.1 parsing right, we should favor protocols that use easier to
> >parse data formats.
> >
> >I think this leaves us with SSH.  Are there others?
> 
> I would say the exact opposite: ASN.1 data, because of its TLV encoding, is
> self-describing (c.f. RPC with XDR), which means that it can be submitted to a
> static checker that will guarantee that the ASN.1 is well-formed.  In other
> words it's possible to employ a simple firewall for ASN.1 that isn't possible
> for many other formats (PGP, SSL, ssh, etc etc).  This is exactly what
> cryptlib does, I'd be extremely surprised if anything could get past that.
> Conversely, of all the PDU-parsing code I've written, the stuff that I worry
> about most is that which handles the ad-hoc (a byte here, a unit32 there, a
> string there, ...) formats of PGP, SSH, and SSL.  We've already seen half the
> SSH implementations in existence taken out by the SSH malformed-packet
> vulnerabilities,

I don't think so.  The SSH packet format is _much_ simpler than ASN.1
and neither the original ssh-1.x nor OpenSSH had problems due to
the packet parsing, both have been immune to last years malformed
packet tests.   I've seen more problems related to ASN.1 parsing
than to SSH packet parsing...

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

Open Source (was Simple SSL/TLS - Some Questions)

[Jill Ramonsky]

Ian asked about the possibility of distributing binaries built with a 
crypto toolkit. I took the initial view that closed source and trustable 
crypto are mutually incompatible, but on reflection, I can think of 
circumstances where that might not be true.

Example. You're a company. You build hardware devices which need to talk 
to each other securely. (Say, ATMs for example). Obviously it wouldn't 
make sense for that company to have to supply its ATM-using-customers 
with the source code of the ATMs. So where should one draw the line?

This is an important question (for me, at least) since it affects the 
licensing of the yet-to-be-written TLS++ project.

After a lot of thought, I think it all boils down to the simple question 
... "trusted by whom?". I might trust an application for any variety of 
reasons. This does not mean that you have to trust it.

It seems to me, therefore, that if you're putting together a crypto app 
which is going to run in an embedded software environment, in a chip, on 
some product, you need to consider WHO is going to be relying on the 
crypto services of that product. If it's just you (or your company) then 
only you (or your company) need to trust it, so only you (or your 
company) need to see the source code. On the other hand, if the public 
are going to be using it, then how will /they/ be assured that there are 
no Trojans in the chips? Should they just take your word for it? Even if 
you gave them the source code, the public would (in general) have no way 
of verifying that it actually WAS the source code. They couldn't (in 
general) compile the code down to the processor-specific machine code 
used on that device and burn in the new binary. Basically, this means 
you can never trust a hardware device you didn't build yourself.

But ... if nobody apart from you (or your company) is going to be 
relying on the crypto, then surely you should be allowed to use TLS++?

With software though, this would be an unusual circumstance. Claims such 
as "Download this app and you will be secure" should definitely need to 
be proven, and if the app is built with TLS++ that would mean 
distributing the source code. But would that mean distributing the 
source code for the whole product, or just the crypto library parts? I 
would argue that it would have to be the whole product, otherwise how 
can a user know whether what you /claim/ is the source code actually 
/is/ the source code?

I'm lost on this one. I don't have any answers, and I'm hoping someone 
else does. I don't want to restrict the distribution of TLS++, but I 
also don't want crippled versions of it being used to fool the public. 
If anyone could help me to outline a reasonable possibility?

Maybe the solution should be this: You can distribute the binary without 
any source code whatsoever, and use this toolkit, unrestricted, in 
whatever manner you choose, provided that EITHER you distribute the 
source code for the whole product in a form which allows the user to 
reconstruct a working executable from the source code, OR you include a 
message which says something like "Warning - this product is closed 
source. If you rely on its crypto features, you do so at your own risk".

(Of course, it's also "at your own risk" if it's open source. The 
difference is, you have a better idea of the risk).

Jill

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

Re: NCipher Takes Hardware Security To Network Level

[Anton Stiglic]

- Original Message - 
From: "Peter Gutmann" <[EMAIL PROTECTED]>
> [...]
> If you think that's scary, look at Microsoft's CryptoAPI for Windows XP
FIPS
> 140 certification.  As with physical security certifications like BS 7799,
you
> start by defining your security perimeter, defining everything inside it
to be
> SECURE, and ignoring everything outside it.  Microsoft defined their
perimeter
> as "the case of the PC".  Everything inside the PC is defined to be
SECURE.
> Everything outside is ignored.

I believe that is typical of most software crypto modules that are FIPS 140
certified, isn't it?
It classifies the module as multi-chip standalone.

This is why you get requirements of the type that it should run on Windows
in
single-user mode, which I take to mean have only an admin account.  This
prevents
privilege escalation attacks (regular user to root) that are easily done.

I think this is reasonable, since you really are relying on the OS and the
PC for the
security of the module.

More scary to me is stuff like
"DSSENH does not provide persistent storage of keys.  While it is possible
to
store keys in the file system, this functionality is outside the scope of
this validation."

This is where Microsoft's CSPs do the dirty work, and use what is called
the Data Protection API (DPAPI) to somehow safeguard keys somewhere
in your system.

--Anton

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

Re: NCipher Takes Hardware Security To Network Level

[Perry E. Metzger]

I was asked by someone to anonymously forward the following reply to
Joshua Hill to the list. (Second time in a week, and on the same topic!)

If you reply, please don't put my name in the reply -- this isn't my
comment.

--

> > The government will still buy your "encryption devices" (FIPS-140
> > certified)
>
> That will greatly depend on the sophistication of the agency concerned.
> The US Forest Service (for example) may not have the level understanding
> of the FIPS 140-2 standard that the US Navy has.

The last time we delt with the Navy, they barely knew what FIPS
140 was, weren't aware there were multiple levels, and when
informed of this had no idea what level they should be using. All
they were interested in was checking the box that said "Must be
FIPS certified".

--

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

Re: nCipher netHSM

[Nicko van Someren]

Ronald,

	I can confirm that there is no new code or hardware inside the 
"cryptographic boundary" as validated by FIPS compared to the most 
recent release of our PCI cards; all necessary changes to the HSM were 
put in before the last re-validation of the cards.  The UI components 
themselves are outside the cryptographic boundary.  That said, 
communication with the HSM thought the screen and input devices on the 
front panel does NOT pass through the computer inside the case but 
instead goes through a micro-controller and into the serial port on the 
PCI card HSM.  This is analogous to the way things have always been 
with out smart card readers plugged into the HSM which themselves were 
not FIPS certified.

	I hope this makes things a little clearer.

Cheers,
Nicko van Someren
CTO, nCipher
On Monday, Oct 6, 2003, at 19:11 Europe/London, R. A. Hettinga wrote:

--- begin forwarded text

Status:  U
To: "R. A. Hettinga" <[EMAIL PROTECTED]>
Subject: Re: nCipher netHSM
From: Ronald Perez <[EMAIL PROTECTED]>
Date: Mon, 6 Oct 2003 13:32:48 -0400
This looks like new packaging of an old/previously-announced product.

The NIST FIPS 140 site 
(http://csrc.nist.gov/cryptval/140-1/1401val2003.htm) does not list 
this device as having undergone any FIPS validation. And from the 
pictures and specs, it looks like what they did was to put one of 
their FIPS validated PCI cards into a 1U rack-mount format box -- 
along with one or two 10/100 Ethernet connections, an LCD display, 
keyboard input, and some other buttons and knobs (all of which have 
not gone through a FIPS validation no doubt).

-Ron

--- 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: anonymity +- credentials

[Anton Stiglic]

- Original Message - 
From: "Ian Grigg" <[EMAIL PROTECTED]>

> [...]
> In terms of actual "practical" systems, ones
> that implement to Brands' level don't exist,
> as far as I know?  

There were however several projects that implemented 
and tested the credentials system.  There was CAFE, an 
ESPRIT project.

At Zeroknowledge there was working implementation written 
in Java, with a client that ran on a blackberry.

There was also the implementation at ZKS of a library in C 
that implemented Brands's stuff, of which I participated in.
The library implemented issuing and showing of credentials,
with a limit on the number of possible showing (if you passed
the limit, identity was revealed, thus allowing for off-line
verification of payments for example.  If you did not pass the
limit, no information about your identity was revealed).  
The underlying math was modular, you could work in a 
subgroup of Z*p for prime p, or use Elliptic curves, or 
base it on the RSA problem.  We plugged in OpenSSL 
library to test all of these cases.
Basically we implemented the protocols described in 
[1], with some of the extensions mentioned in the conclusion.

The library was presented by Ulf Moller at some coding
conference which I don't recall the name of...

It was to be used in Freedom, for payment of services, 
but you know what happended to that projet.

> Also, the use of Brands work
> would need to consider that he holds a swag of
> patents over it all (as also applies to all of
> the Chaum concepts).

Yes, most of the stuff is patented, as is Chaum's stuff.
Somebody had suggested that to build an ecash system
for example, you could start out by implementing David
Wagner's suggestion as described in Lucre [2], and then
if you sell and want extra features and flexibility get the
patents and implement Brands stuff.  Similar strategy 
would seem to apply for digital credentials in general.

> There is an alternate approach, the E/capabilities
> world.  Capabilities probably easily support the
> development of psuedonyms and credentials, probably
> more easily than any other system.   But, it would
> seem that the E development is still a research
> project, showing lots of promise, not yet breaking
> out into the wider applications space.
> 
> A further alternate is what could be called the
> hard-coded psuedonym approach as characterised
> by SOX.  (That's the protocol that my company
> wrote, so normal biases expected.)  This approach
> builds psuedonyms from the ground up, which results
> in a capabilities model like E, but every separate
> use of the capability must be then re-coded in hard
> lines by hardened coders.

Do you have any references on this?

Thanks.

--Anton

[1] http://crypto.cs.mcgill.ca/~stiglic/Papers/brands.pdf
[2] http://anoncvs.aldigital.co.uk/lucre/theory2.pdf

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

Re: [e-lang] Re: Protocol implementation errors

[Peter Gutmann]

Ben Laurie <[EMAIL PROTECTED]> writes:
>Peter Gutmann wrote:
>>ASN.1 has a *reputation* of being notoriously hard to parse, gained chiefly
>>from some early bad experiences with OSI work (which would give anything a
>>reputation of being hard to work with :-).  I've implemented, and I know of
>>others who have implemented, extremely compact and portable ASN.1 libraries.
>
>Do you really mean ASN.1 or do you mean DER/BER?

Sorry, I meant BER/DER data, not the ASN.1 source text.

Peter.

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

Re: [e-lang] Re: Protocol implementation errors

[Ben Laurie]

Peter Gutmann wrote:
> Jerrold Leichter <[EMAIL PROTECTED]> writes:
>>I agree that ASN.1 is statically checkable, and that this is an important
>>property. However, ASN.1 is notoriously hard to parse, which leads to errors.
> 
> 
> ASN.1 has a *reputation* of being notoriously hard to parse, gained chiefly
> from some early bad experiences with OSI work (which would give anything a
> reputation of being hard to work with :-).  I've implemented, and I know of
> others who have implemented, extremely compact and portable ASN.1 libraries.

Do you really mean ASN.1 or do you mean DER/BER?

Cheers,

Ben.

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

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


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

RE: Simple SSL/TLS - Some Questions

[Jill Ramonsky]

Comments inlined below

> -Original Message-
> From: Ian Grigg [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 06, 2003 10:35 PM
> To: Jill Ramonsky
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Simple SSL/TLS - Some Questions
>
> The only question I wasn't quite sure of
> was whether, if I take your code, and modify it,
> can I distribute a binary only version, and keep
> the source changes proprietary?
You can't distribute a binary only version of ANY crypto product, 
surely? No crypto product can EVER be trustworthy unless you can see the 
source code and verify that it has no back doors, and then compile it. 
Unless you give your users the power to inspect the source code, and 
/know/ that it is the source code (because they can actually compile it 
and run the resulting executable) then you could have put all sorts of 
back doors into it. You could have added password theft, key escrow, who 
knows what?

Don't get me wrong. I agree with you that crypto has enough barriers 
already, and I would like to produce something that is as freely 
distributable as possible. "For the masses" crypto is, I guess, an 
unwritten design goal. But allowing people to hide the crypto source 
from crypto users would allow the bad guys (you can define your own bad 
guys) to produce Trojan Horse crypto. Closed source crypto is to all 
intents worthless. (In my opinion). Please feel free to argue that I'm 
wrong.

> My own philosophy has always been that crypto has
> enough barriers on it already, so it should not
> add any more personality quirks than necessary,
> hence preference for BSD two clause.  Mind you,
> such a statement is a personality quirk, so you
> be your own judge.
Eek. Was my paragraph above a personality quirk? I thought it was a 
sound cryptographic principle.

> Names are really hard.  I'd defer that one until
> it pops out.
I agree. But ruling them out is easy. We've already ruled out EasyTLS, 
GnuTLS and Pretty Good TLS. That's narrowing things down. Top of the 
list currently is TLS++, but that kindof implies it won't work with C. 
(This will actually be true for the prototype, but not, I hope, true 
indefinitely). I think I'll stick with that for now until a better one 
comes up.



> Q:  Does your employer  have any say or comment
> on this project?  Might be wise to clear up the
> posture, and either get it in writing, or make
> the repository public from the git-go.  Many an
> open source project has foundered when the boss
> discovered that it works...
It has absolutely nothing whatsoever to do with my employer. All my code 
will be written at home in my spare time, and uploaded to CVS or 
whatever also from home. It is true that I happen to be sending this 
email from work, but even that's in my own time. I don't see how they 
have any say. To be /really/ safe,  I'd be happy to always post to this 
list only from home, but right now I don't think it's a problem.

How do I go about changing the email address with which I'm a member of 
this list?

Jill

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

Re: Other OpenSSL-based crypto modules FIPS 140 validated?

[Peter Gutmann]

"Nathan P. Bardsley" <[EMAIL PROTECTED]> writes:

>Anecdotally, I've heard that there are many, but almost all of them were done
>by vendors for embedding in their proprietary products.

Ditto.  The problem is that when vendors have spent $100K+ on the
certification, they're very reluctant to give anyone else (and specifically
their competitors) the benefits of their expenditure, so you end up getting
the same thing re-certified over and over for private use, rather than a
single generally-usable version being certified.

Peter.

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

Re: NCipher Takes Hardware Security To Network Level

[Peter Gutmann]

>In fact, if you're clever, you can manage to not trouble yourself to get the
>key-management, etc. certified, getting only the simple, symmetric-cipher
>stuff run through the process.  The government will still buy your
>"encryption devices" (FIPS-140 certified) and will conveniently ignore the
>lack of certification on your "management device", even though it acts as an
>administrative user towards the "encryption device".  It's somewhat scary that
>this sort of skulduggery is possible, but it's also not really anything new
>or exciting.

If you think that's scary, look at Microsoft's CryptoAPI for Windows XP FIPS
140 certification.  As with physical security certifications like BS 7799, you
start by defining your security perimeter, defining everything inside it to be
SECURE, and ignoring everything outside it.  Microsoft defined their perimeter
as "the case of the PC".  Everything inside the PC is defined to be SECURE.
Everything outside is ignored.

FIPS 140 requires role-based access control (RBAC).  Microsoft enforces this.
There's a single role, "everyone that uses the machine".

After that, it gets a bit dodgy, and the credibility of the certification
process might be called into question by some of the more sceptical readers.
OTOH it does show that Microsoft has a good grasp of the value of the
certification system.

Note that you could probably get a system running MSDOS FIPS 140 certified
following this methodology, provided that you enable the BIOS password to meet
the access control requirements.

Peter ("I define myself to be A BIT CYNICAL about all this").

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

CCIA Microsoft report--the core issues

[R. A. Hettinga]

Wherin Carroll trashes Schneier a bit...

Cheers,
RAH
---




CCIA Microsoft report--the core issues
By John Carroll
Special to ZDNet
October 6, 2003, 5:13 AM PT
URL: http://zdnet.com.com/2100-1107-5086379.html

COMMENTARY--The Computer & Communications Industry Association (CCIA) has
been a long-time Microsoft opponent.  The lobbying group filed numerous
friend of the court briefs during the antitrust trial in America, and is an
active participant in the antitrust investigation being conducted by the
European Commission.  It is composed of a number of Microsoft?s fiercest
competitors, among them AOL, Sun Microsystems, Oracle, Intuit and Nokia .

Since the end of the American trial, however, the CCIA has pretty much
fallen off the radar screen. Recently, however, they?ve managed to generate
a bit of noise with " CyberInsecurity: The Cost of Monopoly ," which is
presented as " a wake up call that government and industry need to hear "
regarding security issues in Microsoft's near-ubiquitous operating system.
The report has garnered an unusual amount of attention, possibly because
Bruce Schneier, author of Applied Cryptography and generally recognized
expert in the realm of cryptography, was included as one of the report?s
authors.

My respect for Mr. Schneier?s work, however, doesn?t extend to ignoring
flaws in reports to which he contributes.  This is part one in a three part
series which rebuts the arguments made in the CyberInsecurity report.
Today?s installment deals with the core issues, namely, the risks
associated with software "monoculture" and complex systems.  Part two is a
collection of general criticisms relating to the report?s content, and
details its uncanny ability to put a negative spin on practically
everything Microsoft does.  Part three is my treatment of the proposed
remedies, and closes with some parting thoughts.

Do note that you can read the entire report yourself by going to
http://www.ccianet.org/papers/cyberinsecurity.pdf .

The risks of a software monoculture
"Protection from cascade failure is instead the province of risk
diversification--that is, using more than one kind of computer or device,
more than one brand of operating system, which in turns assures that
attacks will be limited in their effectiveness. This fundamental principle
assures that, like farmers who grow more than one crop, those of us who
depend on computers will not see them all fail when the next blight hits."
(Page 11)

In other words, by having a diverse operating system environment, you
prevent a virus that targets one platform from bringing down the entire
infrastructure.  The targeted platform might be laid low, but other
platforms will live on to propagate the species...or just continue
computing.

It?s true that a monoculture has certain costs from the standpoint of
shared risks which lead to a larger pool within which a computer virus
might thrive.  On the other hand, there are also real costs to the lack of
a standardized computing architecture, which is the flip-side of the
monoculture detailed in the report.

The benefits of standardization
As I discussed in my Tunney comments , software lacks the inherent
standards found in other industries.  Software APIs can take practically
any shape imaginable, which means that the initial state of a young
software market is extreme fragmentation.

This is a tremendous inhibitor to development, as a particular software
product can only reach a small, platform-specific market.  This attracts
less developer attention, leading to higher software costs and fewer users.
As a result, the market?s natural tendency has been to standardize on one
provider. That one provider might start with only a slight lead over its
competitors, but that slight lead will cause more developers to target the
favored platform, leading to greater economics of scale and lower costs,
which attracts more customers and gives rise to the virtuous cycle which
gave companies like Microsoft, and IBM before it, a dominant share of the
marketplace.

With Windows, consumers have the most hardware and software choice, lower
costs due to economics of scale, and are guaranteed compatibility with
practically any product on the market.  Companies have a large pool from
which to draw technical staff, all of whom benefit from the deeper
knowledge which comes with the ability to specialize in one platform (Adam
Smith would appreciate this).  Employers also benefit from the fact that
potential employees, if they have computer skills, will have those skills
on Windows.

It?s not just the Windows? market, however, that realizes cost savings in
this fashion.  Increasingly, the UNIX market is organizing around an open
source operating system named Linux.  It is my opinion that this
consolidation will continue, making Linux THE standard for the UNIX
development domain.  Few would say this consolidation is a negative thing,
nor suggest that governm

Freenet fork appears likely (was Re: Gmane -- Re: Why is Freenet so sick at the moment?)

[Steve Schear]

On Sat, Oct 04, 2003 at 11:31:36PM -0700, Ian Clarke spake thusly:
> I have never ever characterized Freenet as being anything other than in
> development.  If you don't like the fact that Freenet is taking so-long
> to perfect, then either help, or use Earth Station 5 - I hear its great.
You never said anything to this effect when people started putting things
in the network that could get them sent to prison so it was rather
implicit.
And now after finding that fred is unable to open /dev/random on my system
due to what appears to be a bug (opening for write instead of read) I am
now worried about the security of the encryption due to lack of entropy.
I'm glad I don't use freenet for anything illegal/unpopular but I'm quite
worried for those who do.
On IIRC a new channel #fredisdead has been receiving quite a bit of 
interest (along with discussions on #anonymous and #freenet).  It appears 
that a small group of developers, fed up with the recent spate of Freent 
problems has decided to take a step back, to release 692 and have started a 
revolt.

http://mids.student.utwente.nl/~mids/freenet/fid.html

steve 

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