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 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 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]