Re: PGP Encryption Proves Powerful

2003-06-04 Thread Bill Stewart
At 11:38 AM 05/30/2003 -0700, John Young wrote:
If the FBI cannot crack PGP that does not mean other
agencies with greater prowess cannot. It is unlikely that
the capability to crack PGP would be publicly revealed
for that would close an invaluable source of information.
.
Still, it is impressive that PRZ valiantly argues that PGP is
algorithmically impregnable. That should satisfy its users as
well as its crackers.
And Phil was quoted as saying
 Does PGP have a back door? The answer is no, it does not,
 he said. If the device is running PGP it will not be possible
 to break it with cryptanalysis alone.
But in fact that's incorrect.  PGP doesn't have back doors,
but it has two major weaknesses, which are weak user-chosen passphrases,
combined with a secret key file format that makes it easy to
verify whether a key has been guessed correctly,
and human-rememberable passphrases, combined with
rubber-hose cryptanalysis and a captured agent.
If you're doing good operational security, and the
Red Brigades probably are, your passphrases have good enough entropy
that they're hard to crack, but if they got sloppy,
and someone wants to feed all the information that's known about them
to pgpcrack, it's possible that they'll find something.
It's less likely than VENONA succeeding, because the importance
of good passphrases was known, and unlike one-time pads there's
no operational need to occasionally get sloppy under time pressure.
I'm not aware of a PGP port to the Psion, but at least the
Psion 3/3a/3c generation were 8086-like processors,
and there was a C compiler ported to them,
so perhaps somebody ported one of the earlier PGPs.
(There was an old HP palmtop that ran genuine MS-DOS,
unlike the Psion's more interesting operating system,
and you could probably run PGP on that directly.)
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Peter Gutmann
Lucky Green [EMAIL PROTECTED] writes:

I trust that we can agree that the volume of traffic and number of
transactions protected by SSL are orders of magnitude higher than those
protected by SSH. As is the number of users of SSL. The overwhelming majority
of which wouldn't know ssh from telnet. Nor would they know what to do at a
shell prompt and therefore have no use for either ssh or telnet.

Naah, that third sentence is wrong.  It's:

  The overwhelming majority of [SSL users] wouldn't know SSL from HTTP with a
  padlock GIF in the corner.

Given that SSL use is orders of magnitude higher than that of SSH, with no
change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by
your assertion that ssh, not SSL, is the only really successful net crypto
system.

I think the assertion was that SSH is used in places where it matters, while
SSL is used where no-one really cares (or even knows) about it.  Joe Sixpack
will trust any site with a padlock GIF on the page.  Most techies won't access
a Unix box without SSH.  Quantity != quality.

If you could wave a magic wand and make one of the two protocols vanish, I'd
notice the loss of SSH immediately (I couldn't send this message for
starters), but it would take days or weeks before I noticed the loss of SSL.

Peter.

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


Re: New vs Old (was Snake Oil)

2003-06-04 Thread bear


On Tue, 3 Jun 2003 [EMAIL PROTECTED] wrote:


I confess to being confused - though admittedly part of the blame for this
is my own ignorance.

I remember a time when PGP was a command line application. The only
algorithms it used were IDEA (symmetric), RSA (assymetric) and MD5 (hash). I
came to trust these algorithms.

Now these once-'standard' algorithms are no longer encouraged. The new
versions of PGP seem to prefer CAST instead of IDEA, DH/DSS instead of RSA,
and SHA-1 instead of MD5.

So, could someone please tell me:

(1) What is the justification for using these new algorithms instead of
the old ones? (A cynic might suggest that, since the powers that be
couldn't break the old algorithms, they encouraged the use of new ones that
they could. This probably isn't true, but I'm sure you can understand why
someone might think that).

Well - Hans Dobbertin found hash collisions in MD5 and while I haven't
heard much more, that's a toehold that somebody might be able to use
to break it, and makes it vulnerable in some applications.  SHA-1 is
now considered better.

IDEA is still a good cipher as far as I know, but PGP has been driven
away from it in the US due to intellectual-property issues.  Rather than
continue with incompatible versions for use inside/outside the USA, they're
switching to CAST (although this is causing more, rather than less, version
incompatibilities).

RSA is still good, as far as I know, and has been in the public domain
worldwide since September 2001.  But it had the same kind of IP issues
as IDEA until that point, and several versions of PGP had to be
produced that used a different asymmetric cipher for that reason.  I
don't know enough about DH/DSS specifically to comment further on its
relative security, but RSA has had several scares and people are
concerned that custom hardware (such as a million-qubit quantum
computing device or Bernstein's matrix hardware factoring device)
might cause insecurity in RSA _and_ be possible for someone to keep
secret.  And lots of people quit using RSA because they don't like
the big block of key that it requires.

(2) What actually _IS_ DH/DSS? (I don't mean what do the initials it stand
for, I mean what actually is the algorithm?). I ask because I can understand
RSA, and implement it myself relatively straightforwardly, but I have not
been able to find an explanation, simple or otherwise, of what the DH/DSS
algorithm actually is, or of why it's hard to break.

(3) Ditto CAST and SHA-1.

for a good complete description of SHA-1 and a few others, try

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

(warning: link may be outdated).

I don't have pointers to the other two offhand.

Bear


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


Re: PGP Encryption Proves Powerful

2003-06-04 Thread Bill Stewart
At 08:17 AM 06/03/2003 -0700, bear wrote:
what he said was with cryptanalysis alone.
Rubber-hose methods are not cryptanalysis, and
neither is password guessing.
Eh?  Password guessing certainly is.

I'm not aware of a PGP port to the Psion, but at least the
Psion 3/3a/3c generation were 8086-like processors,
and there was a C compiler ported to them,
so perhaps somebody ported one of the earlier PGPs.
IIRC, there was/is a psion linux port, with gcc.
Looks like it's still in active development,
mainly for the Psion 5 series - they've even got
X Windows running on them, as well as PGP.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Bill Frantz
At 7:42 AM -0700 6/3/03, John Kelsey wrote:
I keep wondering how hard it would be to build a cordless phone system on
top of 802.11b with some kind of decent encryption being used.  I'd really
like to be able to move from a digital spread spectrum cordless phone
(which probably has a 16-bit key for the spreading sequence or some such
depressing thing) to a phone that can't be eavesdropped on without tapping
the wire.

rant

I've spent some time recently looking at Voice over IP (VoIP)
implementations.  My immediate reaction to reading the standards is that
they a complete answer to a telephone company executive's wet dreams.
Conferencing, Automatic call forwarding, Billing etc. etc., they're all
covered.  The result is a protocol that is beyond baroque and well into
rococo.  I think the various standards bodies are still trying to deal with
issues in the protocols that weren't thought of from the start.

Of course, once you have your call set up, you have to encrypt it.  Most of
the VoIP implementations use Real Time Streaming Protocol (RTSP, RFC2326),
which requires two UDP ports through your firewall.  Then you have to
encrypt the RTSP traffic.  I have seen reference to an encryption protocol
specifically for RTSP, but a quick scan of STD1 didn't turn it up, so it is
probably still a draft.  I don't know anything about its security.

The other choice is IPSec.  IPSec seems happiest securing traffic between
machines with permanent IP addresses.  It is a nightmare to use with
Network Address Translation.

What would be really nice would be a VoIP system that used TCP instead of
UDP.  (I know that if TCP goes into error recovery, there is going to be
major jitter in the voice.  I know it will be hard to support conferencing.
I know it will not gracefully bridge to the POTS network.  Etc. I'm willing
to put up with that to avoid the pain that comes with UDP.)  Then I can
just tunnel it through SSH, or hack it to use SSL/TLS.  Oh well.

/rant

Cheers - Bill


-
Bill Frantz   | Due process for all| Periwinkle -- Consulting
(408)356-8506 | used to be the | 16345 Englewood Ave.
[EMAIL PROTECTED] | American way.  | Los Gatos, CA 95032, USA



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


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Anne Lynn Wheeler
On Tue, 2003-06-03 at 07:04, Peter Gutmann wrote:
 That's a red herring.  It happens to use X.509 as its preferred bit-bagging
 format for public keys, but that's about it.  People use self-signed certs,
 certs from unknown CAs [0], etc etc, and you don't need certs at all if you
 don't need them, blatant self-promotionI've just done an RFC draft 
that uses
 shared secret keys for mutual authentication of client and server, with no
 need for certificates of any kind/blatant self-promotion, so the use of
 certs, and in particular a hierarchical PKI, is merely an optional extra.
 It's no more required in SSL than it is in SSHv2.

the pk-init draft for kerberos allows public keys  allowing both
cert  cert-less implementation
blatant aads-promotion
the scenario allows for public key registration in lieu of shared secret
registration. the scenario is that r/o access, divulging, sniffing, etc
doesn't result in compromise.
in the token form 
http://www.garlic.com/~lynn/index.html#aadsstraw
http://www.asuretee.com/
the key-pair is gen'ed in the chip and never leaves the chip.

as part of 3-factor authentication
* something you have
* something you know
* something you are
the chip in the token purely provides something you have
authentication ... and the digital signature done by the token is purely
to prove  that you have that particular token. It doesn't prove who you
are, it just proves that you have a specific (extremely difficult to
counterfeit) token as part of something you have authentication.
if the token is augmented with a pin/password for its correct operation,
then there can be 2-factor authentication. It doesn't involved
shared-secrets since the pin/password is purely between the person and
the hardware token.
The business process validates that the token is of the type requiring
PIN and/or biometric for
correct operation.
The ecdsa digital signature authentication protocol for kerberos,
radius, x9.59 for all retail financial transactions, or ssh can be
identical regardless of the integrity level.
The ecdsa digital signature authentication protocol can be ubiquitous
regardless of the authentication integrity level required.
The business process to meet integrity requirements then can require
sofware key-pair or hardware token key-pair, the level of integrity of
the hardware token, and/or the operational characteristics of the
hardware token (no-pin, pin, biometrics, etc) w/o changing the protocol.
If the protocol is independent of the business process integrity issue
then either the business and/or the end-user may be able to having
personal choice about the level of integrity required. Furthermore, the
person might even have personal choice whether they need a unique token
per security environment, a single token for all security environment,
and/or a small number of tokens selectively applied to different
security environments
the digital signature has nothing at all to do directly with the person,
it is purely related to demonstrating the possession of the token (as
part of something you have authentication) and possibly the integrity
level of the token.
The issue of the authentication protocol  is getting the bits and bytes for
transmission correct but doesn't normally say what it means ... i.e. secret,
shared-secret, one factor authentication, two-factor authentication,
something you have authentication, something you know authentication,
etc. ... although frequently the protocol is envisioned to be a specific
implementation of a specific kind of authentication and trust/integrity level.
recent token discussions
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
older token discussions
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, 
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and 
their users [was Re: Cryptogram:  Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: 
Rubber hose attack
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by 
Credit Card Scam
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the 
wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really 
secure?
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security 
requested

Re: Nullsoft's WASTE communication system

2003-06-04 Thread Steven M. Bellovin
The AP wire reports that the founder of Nullsoft, Justin Frankel, plans 
to resign in the wake of WASTE being pulled.

http://www.nytimes.com/aponline/technology/AP-AOL-Nullsoft.html


--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of Firewalls book)



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


Re: New vs Old (was Snake Oil)

2003-06-04 Thread Bill Stewart
At 08:53 AM 06/03/2003 -0700, bear wrote:
IDEA is still a good cipher as far as I know, but PGP has been driven
away from it in the US due to intellectual-property issues.  Rather than
continue with incompatible versions for use inside/outside the USA, they're
switching to CAST (although this is causing more, rather than less, version
incompatibilities).
Actually, they switched to letting the user choose algorithms,
with CAST as the default but others such as 3DES available.
One of the compatibility issues is that people have written
patches for GPG that implement IDEA, so some users' systems support it
and others don't.  On the other hand, that mainly bothers the
people who've picked only accept IDEA for their symmetric algorithms.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Bill Stewart
At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote:
I (arbitratrily) define the marketplace for SSL as browsing.
...
There, we can show statistics that indicate that SSL
has penetrated to something slightly less than 1% of servers.
For transmitting credit card numbers on web forms,
I'd be surprised if there were 1% of the servers that *don't* use SSL/TLS.
Virtually all deployed browsers support SSL, except a few
special-purpose versions.  The web servers supporting
almost all of the web support SSL if they have keys installed.
While many of them haven't bothered paying money for certified keys
or doing self-signed keys, I'd be surprised if it's really
as low as 1%.  What's your source for that figure?
While only a small fraction of web pages, and a much smaller
fraction of web bits transmitted, use SSL, that's appropriate,
because most web pages are material the publisher wants the public to see,
so eavesdropping isn't particularly part of the threat model,
and even integrity protection is seldom a realistic worry.
(By contrast, eavesdropping protection and integrity protection
are critical to telnet-like applications, so SSH is a big win.)
It's nice to have routine web traffic encrypted,
so that non-routine traffic doesn't stand out,
and so that traffic analysis is much harder,
but there is a significant CPU hit from the public-key phase,
which affects the number of pages per hour that can be served.
Corporate intranet web traffic carried across the public internet
sometimes uses SSL, but usually uses IPSEC because that also supports email.


In addition to web browsing and email submission,
there's an emerging market for SSL-based VPNs appliances.
Neoteris is one of the pioneers, and Aventail and some others are players.
The intention is that you can get clientless (browser-based)
support for intranet web browsing and email,
and lightweight client support for telnet,
while only having to buy an overpriced server box.
(And the box doesn't even need crypto accelerator help,
because the public-key phase only gets used for login,
while most sessions are long enough that this amortizes quickly.)
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Eric Blossom
On Tue, Jun 03, 2003 at 06:17:12PM -0400, John Kelsey wrote:
 At 01:25 PM 6/3/03 -0700, Eric Blossom wrote:
 ...

 I agree end-to-end encryption is worthwhile if it's available, but even 
 when someone's calling my cellphone from a normal landline phone, I'd like 
 it if at least the over-the-air part of the call was encrypted.  That's a 
 much bigger vulnerability than someone tapping the call at the base station 
 or at the phone company.

GSM and CDMA phones come with the crypto enabled.  The crypto's good
enough to keep out your neighbor (unless he's one of us) but if you're
that paranoid, you should opt for the end-to-end solution.  The CDMA
stuff (IS-95) is pretty broken: *linear* crypto function, takes 1
second worst case to gather data sufficient to solve 42 equations in
42 unknowns, but again, what's your threat model?  Big brother and
company are going to get you at the base station...

At our house we've pretty much given up on wired phone lines.  We use
cell phones as our primary means of communication.  Turns out that
with the bundled roaming and long distance, it works out cheaper than
what we used to pay for long distance service.  There is that pesky
location transponder problem though.

 ...which will basically never be secured end-to-end if 
 this requires each of those people to buy a special new phone, or do some 
 tinkering with configuring secure phone software for their PDA.  Hmmm, 
 which key size do I need?  Is 1024 bits long enough?  Why do I have to move 
 the mouse around, again, anyway?

It doesn't have to be hard.  No requirement for PKI.  Just start with
an unauthenticated 2k-bit Diffie-Hellman and be done with it.

Eric

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


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Anne Lynn Wheeler
At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:

I never figured out how to use a certificate to authenticate a
client to a web server, how to make a web form available to one
client and not another.  Where do I start?
What I and everyone else does is use a shared secret, a
password stored on the server, whereby the otherwise anonymous
client gets authenticated, then gets an ephemeral cookie
identifying him..   I cannot seem to find any how-tos or
examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared secret
passwords, whereby we each log into a large number of
webservers.  Was this what the people who created this protocol
intended?
The issue is where does the authentication material come from.
blatant aads promotion
Basically, certificates were solution targeted for offline email from
the early '80s. you dail-up, connect, exchange email, hang-up. then
you read. some random person that you never, ever dealt with before
sends you something. they claim to be somebody  the certificate
is signed by somebody you trust  is offered as proof that they are
who they claimed to be.
the other approach in the online world /or with previous relations,
is have a table of authentication material. the payment (debit/credit) card
world went from non-electronic, offline to electronic and online (and
skipped the step altogether that certificates represent ... the electornic
and offline).
note that even the certificate-based infrastructure are dependent on
this method  basically the certificate-enabled infrastructures have
local table of CA public keys (i.e. those public keys that they've previously
decided to trust) ... then certificates are validated with CA public keys
and the current message/document is validate with public key from
certificate. The primary difference between cert-based infrastructure and
certless-based infrastructure is that the cert-based infrastructure there
CAs have the database of all public keys and create these small R/O
copies of their database records called certificates and spray them all
over for use in offline environments. Then relying parties just have
abbreviated CA-only public key tables and can't access the full tables
maintained at the CAs.
In the certless-based infrastructure the relying parties either maintain
their own full tables of all public keys and/or have direct online access to
the full tables. There is no need for these little R/O, static, stale,
redundant and superfluous copies of somebody else offline database entry 
(called
certificates) since there can be direct, online access to the original copy.

generalized case can be hooking the web server to either radius or
kerberos for handling the authentication process. both radius and
kerberos support shared-secrets recorded in database as authentication.
the radius example at
http://www.asuretee.com/
shows example of radius recording public key in lieu of shared-secret
and performing ecdsa digital signature authentication. pkinit for
kerberos also allows for public key recorded in lieu of shared-secret
and digital signature authentication.
misc. radius public key authentication posts
http://www.garlic.com/subpubkey.html#radius
misc. kerberos public key authentication pots
http://www.garlic.com/subpubkey.html#kerberos
futher discussion specifically regarding static, stale, redundant,
superfluous certificates.
http://www.garlic.com/~lynn/subpubkey.html#rpo
slightly related discussions regarding SSL merchant comfort
certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
/blatant aads promotion
--
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: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Ng Pheng Siong
On Tue, Jun 03, 2003 at 03:04:54PM -0700, James A. Donald wrote:
 I never figured out how to use a certificate to authenticate a
 client to a web server, how to make a web form available to one
 client and not another.  Where do I start?

[ Resend to cryptography@ only coz the earlier attempt failed. ]

Start by looking up the OpenSSL wrappers for your favourite high-level
scripting language. There exists wrappers for Perl, Python, tcl, Ruby,
etc. Some popular languages have several.

Many of these programming language environments come with HTTP server
implementations, and many of the OpenSSL wrappers hook into said HTTP
server code to add HTTPS, and a number demonstrate how to do client-side
certificates.

My M2Crypto adds HTTPS to the popular web application server Zope
(www.zope.org) and has some code to hook client-side certificates into
Zope's own user authentication machinery. (By faking HTTP basic
authentication, just like Apache's SSL do.) Once you have that, you can
choose to serve whatever content you want.


 What I and everyone else does is use a shared secret, a
 password stored on the server, whereby the otherwise anonymous
 client gets authenticated, then gets an ephemeral cookie
 identifying him.. 

It seems HMAC'ing cookies are getting popular for this purpose.
OpenACS, another popular web application server uses this:

   http://openacs.org/doc/openacs-4/security-design.html

My Python crypto kit has an implementation of the scheme described here:

http://www.pdos.lcs.mit.edu/cookies/pubs/webauth.html

I'll be interested to hear this list's view on such schemes. From my
app-plumber's perspective, such a technique for is good enough provided it
is 'secure' enough.

People understand passwords. Private keys, certificates, smart cards, etc.,
are more difficult. (I recall a paper on PGP UI useability testing called
Why Johnny cannot encrypt or something like that.)


 As a result we each have a large number of shared secret
 passwords, whereby we each log into a large number of
 webservers.  Was this what the people who created this protocol
 intended?

Actually, this is the crypto-wielding-open-source-hacker-wannabe's wet
dream: So what you need now to track (or generate strong) passwords is a
GUI password safe! (Like the one offered on (the old?) Counterpane site.)

Again, Perl, Python, Ruby, yada yada, you name it, people are going to
implement them for free. ;-)

Especially since there are usually 3-5 GUI toolkits and 2-4 database toolkits
for these language environments. Enough combinations to suit everyone.


-- 
Ng Pheng Siong [EMAIL PROTECTED] 

http://firewall.rulemaker.net  -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto  SSL

--94BE45B7.1054694140/vista.netmemetic.com--


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


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread James A. Donald
--
On 3 Jun 2003 at 15:04, James A. Donald wrote:
 I never figured out how to use a certificate to authenticate 
 a client to a web server, how to make a web form available to 
 one client and not another.  Where do I start?

 What I and everyone else does is use a shared secret, a 
 password stored on the server, whereby the otherwise 
 anonymous client gets authenticated, then gets an ephemeral 
 cookie identifying him..   I cannot seem to find any how-tos 
 or examples for anything better, whether for IIS or apache.

 As a result we each have a large number of shared secret 
 passwords, whereby we each log into a large number of 
 webservers.  Was this what the people who created this 
 protocol intended?

Or to say the same thing in different words -- why can't HTTPS 
be more like SSH?Why are we seeing a snow storm of scam
mails trying to get us to login to e-g0ld.com? 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 QtiFX0Q654gHh54NAMlLGE1FGDveixyzL0ZnAOVS
 4hprBkT1zeYk/HdBOXiquwvz5vLUwF/21wW1Jf411


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


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Ian Grigg
Tim Dierks wrote:
 
 At 09:11 AM 6/3/2003, Peter Gutmann wrote:
 Lucky Green [EMAIL PROTECTED] writes:
  Given that SSL use is orders of magnitude higher than that of SSH, with no
  change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by
  your assertion that ssh, not SSL, is the only really successful net crypto
  system.
 
 I think the assertion was that SSH is used in places where it matters, while
 SSL is used where no-one really cares (or even knows) about it.  Joe Sixpack
 will trust any site with a padlock GIF on the page.  Most techies won't access
 a Unix box without SSH.  Quantity != quality.
 
 I have my own opinion on what this assertion means. :-) I believe it
 intends to state that ssh is more successful because it is the only
 Internet crypto system which has captured a large share of its use base.
 This is probably true: I think the ratio of ssh to telnet is much higher
 than the ratio of https to http, pgp to unencrypted e-mail, or what have you.


Certainly, in measureable terms, Tim's description
is spot on.  I agree with Peter's comments, but
that's another issue indeed.


 However, I think SSL has been much more successful in general than SSH, if
 only because it's actually used as a transport layer building block rather
 than as a component of an application protocol. SSL is used for more
 Internet protocols than HTTP: it's the standardized way to secure POP,
 IMAP, SMTP, etc. It's also used by many databases and other application
 protocols. In addition, a large number of proprietary protocols and custom
 systems use SSL for security: I know that Certicom's SSL Plus product
 (which I originally wrote) is (or was) used to secure everything from
 submitting your taxes with TurboTax to slot machine jackpot notification
 protocols, to the tune of hundreds of customers. I'm sure that when you add
 in RSA's customers, those of other companies, and people using
 OpenSSL/SSLeay, you'll find that SSL is much more broadly used than ssh.


Design wins!  Yes, indeed, another way of measuring
the success is to measure the design wins.  Using
this measure, SSL is indeed ahead.  This probably
also correlates with the wider support that SSL
garners in the cryptography field.


 I'd guess that SSL is more broadly used, in a dollars-secured or
 data-secure metric, than any other Internet protocol. Most of these uses
 are not particularly visible to the consumer, or happen inside of
 enterprises. Of course, the big winners in the $-secured and data-secured
 categories are certainly systems inside of the financial industry and
 governmental systems.


That would depend an awful lot on what was meant
by dollars-secured and data-secured ?  Sysadmins
move some pretty hefty backups by SSH on a routine
basis.

-- 
iang

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


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Dave Howe
Bill Frantz wrote:
 I know of one system that takes credit cards over HTTPS, and then
 sends the credit card number, encrypted with GPG to a backend system
 for processing.
For that matter, our system here discards the CC after use (the pre-auth
step with the merchant bank agent gives us back a fulfillment handle that
can only be used to fulfill or cancel that individual transaction - but of
course Amazon *want* to keep your CC details so they can do their
fast-checkout patented thingy.


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


Re: Maybe It's Snake Oil All the Way Down

2003-06-04 Thread Peter Gutmann
James A. Donald [EMAIL PROTECTED] writes:

I never figured out how to use a certificate to authenticate a client to a
web server, how to make a web form available to one client and not another.
Where do I start?

There's a two-level answer to this problem.  At an abstract level, doing
client certs isn't hard, there are various HOWTOs around for Apache, Microsoft
have Technet/MSDN papers on it for IIS, etc etc.  At a practical level, it's
almost never used because it's just Too Hard.  That's not the SSL client-cert
part, it's the using-X.509 part.  To save having to type in a long
explanation, I'll lift a representative paragraph from a (not-yet-published,
don't ask :-) paper on PKI usability:

  There is considerable evidence from mailing lists, Usenet newsgroups and web
  forums, and directly from the users themselves, that acquiring a certificate
  is the single biggest hurdle faced by users [1].  For example various user
  comments indicate that it takes a skilled technical user between 30 minutes
  and 4 hours work to obtain a certificate from a public CA that performs
  little to no verification, depending on the CA and the procedure being
  followed.  Obtaining one from non-public CAs that carry out various levels
  of verification before issuing the certificate can take as long as a month.
  A representative non-technical user who tried to obtain an (unverified)
  certificate from a public CA took well over an hour for the process, which
  involved [...] eventually the user gave up.

and that doesn't even get into the mess of managing private keys, handling
revocation, etc etc etc ad nauseum:

  The problems that this creates are demonstrated by what happens when
  technically skilled users are required to work with certificates.  The
  OpenSSL toolkit [2][3] includes a Perl script CA.pl that allows users to
  quickly generate so-called clown suit certificates (ones that 'have all the
  validity of a clown suit' when used for identification purposes [4]), which
  is widely-used in practice.  The cryptlib toolkit [5][6] contains a similar
  feature in the form of Xyzzy certificates (added with some resistance and
  only after the author grew tired of endless requests for it), ones with
  dummy X.500 names, an effectively infinite lifetime, and no restrictions on
  usage.  Most commercial toolkits include similar capabilities, usually
  disguised as 'test certificates' for development purposes only, which end up
  being deployed in live environments because it.s too difficult to do it the
  way X.509 says it should be done.  Certificates used with mailers that
  support the STARTTLS option consist of ones that are 'self-signed, signed-by
  the default Snake Oil CA, signed by an unknown test CA, expired, or have the
  wrong DN' [7].  The producer of one widely-used Windows MUA reports that in
  their experience 90% of the STARTTLS-enabled servers that they encounter use
  self-signed certificates [8].  This reduces the overall security of the
  system to that of unauthenticated Diffie-Hellman key exchange, circa 1976.
  In all of these cases, the entire purpose of certificates has been
  completely short-circuited by users because it.s just too difficult to do
  the job properly.  The problematic nature of X.509 is echoed in publications
  both technical and non-technical, with conference papers and product
  descriptions making a feature of the fact that their design or product works
  without requiring a PKI.  For example, one recent review of email security
  gateways made a requirement for consideration in the review that the product
  'have no reliance on PKI' [9].  As an extreme example of this, the inaugural
  PKI Research Workshop, attended by expert PKI users, required that
  submitters authenticate themselves with plaintext passwords because of the
  lack of a PKI to handle the task [10][11].

As a result we each have a large number of shared secret passwords, whereby
we each log into a large number of webservers.  Was this what the people who
created this protocol intended?

The assumption of the protocol's creators was that someone would figure out
how to make X.509 PKI work by the time SSL took off, and everyone would have
their own certificates and whatnot.

At least they got *most* of the design right :-).

Peter.


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


Microsoft Ties Security to VeriSign, Certifications

2003-06-04 Thread R. A. Hettinga
http://www.internetnews.com/ent-news/print.php/2216571

www.internetnews.com/ent-news/article.php/2216571


Back to Article 

Microsoft Ties Security to VeriSign, Certifications 
By
Thor Olavsrud and Mark Berniker 
June 3, 2003 


Microsoft ( Quote ,Company
Info ) moved to bolster its code-securing effort called Trustworthy
Computing Initiative by announcing two security initiatives Tuesday.


Microsoft and VeriSign said they would jointly develop improved solutions
for authentication security, digital rights management (DRM) and other
online security enhancements. Financial terms of the deal were not
disclosed. 

The new security products from Microsoft-VeriSign are aimed at
achieving improvements in existing software, while providing automated
renewal of digital certificates, secure e-mail and digital signatures. The
alliance also plans to help improve network security with reliable access
to wireless LANs or virtual private networks .

The two partners also said
they plan to help customers embed PKI (public key infrastructure) security
into desktop and networked applications. 

Microsoft also announced the
availability of a new security certification program for system
administrators and systems engineers: MCSA: Security and MCSE: Security.
These programs will give IT professionals training to improve enterprise
security. 

By introducing these new certifications, we're supporting the
Secure in Deployment tenet of the company's Trustworthy Computing
Initiative, said Lutz Ziob, general manager for Microsoft's Training and
Certification group. This tenet speaks to an organization's ability to
apply recognized and established best practices around security, so that
Microsoft products and technologies are rolled out in the most secure way
possible. We've taken those best practices and developed prescriptive
certification tracks to help IT professionals demonstrate their acumen in
designing and implementing a secure computing environment. We've also
included CompTIA's Security+ credential in these tracks to extend the
certifications to include cross-platform skills as well. 

Microsoft is
beginning to make real progress in Trustworthy Computing on behalf of our
customers and partners, particularly in the way we think about, design and
develop our products and services to be more secure, reliable and
privacy-compliant from the start, Scott Charney, chief trustworthy
computing strategist at Microsoft, said during his Tech Ed 2003 keynote in
Dallas Tuesday. 

Although much work remains to be done, we are delivering
tools and resources so customers and partners can successfully manage their
networks for optimum security in deployment. 

Still, critics of
Microsoft's security strategy have had a lot of fodder with the recent
discovery of security holes in its Passport personal information storage
service, which were later patched, and other questionable levels of
security for critical applications for businesses, governments and
individuals. 

But the Trustworthy Computing Initiative is trying to change
that, and Charney, together with Nico Popp, vice president of product
development in the Security Services Division at VeriSign ( Quote ,Company
Info ), said new efforts will see the two partners developing several
security initiatives for enterprise customers, including PKI auto
enrollment of VeriSign certificates, interoperability of certificate
authorities, and secure mobile access. The initiatives will be built on the
Windows Server 2003 PKI platform. 

The pact is expected to improve upon
existing security use of digital signatures for Microsoft's Windows Server
2003. Digital signatures provide some authentication security, but with the
recent security problems associated with Microsoft's Passport product, the
company is moving to improve security software within its products. 

The
deal aims to provide improved online security, especially for remote
access. The two companies will build the security solutions into not only
Microsoft's Windows Server 2003, but also VeriSign's Managed PKI (public
key infrastructure) Services. 

VeriSign specializes in making server
software that is able to handle a large number of digital signatures, and
is expected to launch a service later this year that will be closely tied
to the new features inside Microsoft's Windows Server 2003. 

Improvements
in digital signatures could be helpful in the exchange of contracts and
proposals sent over networks. In addition, corporate partners could send
documents that would include a digital rights management tag along with an
e-mail, which would enhance document security for both parties. 

The two
companies said they would market the new solutions to enterprise users
aiming to provide secure online information and digital identity management
systems. 

Developing reliable and secure PKI authentication systems has
proven to be complicated and difficult, as many companies have been slow to
install the servers and software to support the