Cryptography-Digest Digest #743, Volume #9 Mon, 21 Jun 99 07:13:03 EDT
Contents:
Re: A Thought or a Quoater ("rosi")
Re: 1024 bits encryption for web based e-mail (hushmail) (Fred)
Re: HushMail -- Free Secure Email (a little long) (Fred)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: Cipher ([EMAIL PROTECTED])
Re: Where can i get the code from Bruce Schniere's applied crytptography?
([EMAIL PROTECTED])
Re: Where can i get the code from Bruce Schniere's applied crytptography? ("Sven
Knispel")
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (kurt wismer)
Re: Good book for beginning Cryptographers? ("GyungHwa Jun")
Re: Good book for beginning Cryptographers? (Jim Gillogly)
Re: alt.security.scramdisk ("Andy Jeffries")
Re: Security ... or just lies .... (wtshaw)
Re: *** FAKE KEYS AGAIN *** ("Sam Simpson")
----------------------------------------------------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: A Thought or a Quoater
Date: Sun, 20 Jun 1999 23:25:00 -0400
Key Establishment
(Certain things, for succinctness, are implicit. If you are not clear,
it almost surely is because I did not make things clear. Apologies in
advance)
NS (Needham-Schroeder) may be the 'basic' construct of almost all key
establishment protocols (including hybrid ones) using public-keying. Here
freshness of session keys is facilitated through a primitive that offers
the inseparable (mutual) identification of the communicating parties and
the establishment of a _SHARED_ key (which is of course overwhelmingly of
a symmetric keying scheme). Besides the neatness of the primitive, the key
established is not biases toward either party, as both can be guaranteed
to constibute equally.
The attackers are faced with two problems. Breaking the protection by
the public-key method or breaking the symmetric one, both are independent
of each other and the weakest defines the real security. (The former via
obtaining the decryption key is more beneficial for sure).
Two (public) keys are involved in NS. However, the strength is not
the 'sum' of the two (e.g. two 1024-bit RSA combined give 2048-bit RSA
strength, and the security assumption is assumed here). Instead, it
gives at 'best' 1025-bit strength. Yet ideally we would like the 2048-
bit strength.
More sophisticated schemes employ an (essentially) two-key approach
where one of the public-keying 'component' is signing. However, It
requires the maintenace of two public keys, both static. Ideally, we
would like to just keep one static.
Even though the above described two-public-key method takes 'advantage'
of signing, non-repudiation is never an issue in such a primitive in
general, yet verification is a 'public' operation rather than a private
one. Therefore in essence, only one public-keying is really utilized to
the full extend. In addition, in situations (which are very common) where
the two sides have unbalanced security, the failure of 'one side' can
render the complete communications between the 'failing side' and any
other party totally exposed. An ideal situation is to prevent this, i.e.
passive attacks will still not succeed even when one of the public keys
is completely broken.
It seems a rule rather than an exception that whenever two public keys
are involved, the security depends on one rather than 'both'. In addition,
the dependency on a third trusted party adds 'unecessary convolution'.
While special applications may be improved in efficiency, c.f. Beller-
Yacobi, the intensive computation for public-keying operations remains a
nuisance. The burden on the 'server' side, for example, can hardly be
alleviated (as of now).
Taking our general assumption and the optimistic 'view on life', we
behave as if, for example, the 'cycles' can never be found efficiently.
This is highly necessary. I can not imagine one wearing a straight face
when he believes that is not the case. Under that assumption, the worst
catastrophe is something like: 2^100 times faster now for that special
kind. Something suddenly brought within reach that was previously thought
otherwise. The impact of such an event is of course closely related to
our definition of 'secure', 'broken', etc., a too hard topic I do not
want to go in, knowing that more answers can be received than expected
but no 'solution'. Similarly, if the issue is broadened, we will never
see an end of it. In particular, the 'initial key establishment' is not
touched here.
One layer may not be a too good idea. But this is a mere personal
taste. 'Why two layers? Why not just more bits but keep one layer? etc.'
A judgement call.
Next, the weird thing --- key secure. See you next time.
Thank you very much.
--- (My Signature)
------------------------------
From: Fred <[EMAIL PROTECTED]>
Subject: Re: 1024 bits encryption for web based e-mail (hushmail)
Date: Mon, 21 Jun 1999 03:04:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <7jqvle$eed$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
<snip>
> discussed this already. Hushmail can be broken quite easily. A
server
> could interrupt hushmail and pretend (i.e ghost servers) which could
> send false java apps.
This is the second time I've seen a suggestion that hushmail
is vulnerable to a man-in-the-middle attack.
Has someone found a hole in SSL that would permit this? If
so, then every time you send your credit card to a merchant
you're risking sending it to an impostor.
If not, then the only problem is that hushmail might be
invaded, coerced, bribed, or hire the wrong employee...
>
> Basically the problem is that you have no clue wether the java app
you
> get is the real thing.
This is important, and true unless you go to unlikely lengths
to check. Here's the response I got from hushmail when I
asked about applet validation:
[quote]
Use the "l" command on the Netscape Java Console to dump our
classfiles
to a directory. They will be in a jar file in <netscape
home>/Communicator/Program.
Compile the source using Sun's JDK 1.1.7 for Windows. Put it in a jar
file.
Extract the manifests from the two jar files. They will contain
hashes
of the classes in the archives. Compare the hashes of our classes
with
those of the classes you compiled.
If you don't trust the manifest in our jar file, simply extract the
classes,
and create a new jar file. This will automatically create a fresh
manifest
that is guaranteed to be accurate.
In the future, we hope to offer a plug-in that will automate this
tedious
process.
[\quote]
I've found hushmail pretty responsive to questions, and
[EMAIL PROTECTED] gave me permission to post his address
(exact words: "Please post my willingness to sci.crypt
to take questions/comments to developers. ")
>
> Use PGP or RIPEM for private email. You will save yourself the
trouble.
Amen. Hushmail is for communicating with people who can't
or won't install and use PGP.
>
> BTW, what does '1024 bit encryption' mean? Is that the block size?
> Key, number of bits in the name?
>
> Tom
Diffie-Helman key length.
- --
f r e d e r w <atsign> p o b o x . c o m
Boycott spammers!
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>
iQA/AwUBN22roHJQgJ+siYlMEQLlZwCZAYswnBw/WdIhZfh/nMB0CJtQF9IAoKML
NzSDzKGZwjYczSTmsDWJfmvd
=/tur
=====END PGP SIGNATURE=====
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Fred <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email (a little long)
Date: Mon, 21 Jun 1999 03:28:34 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
<snip>
>
> I have downloaded the purported Java source code and it does seem to
> include some operations I expected. But I have not looked at it in
> detail.
>
> HushMail does seem to be missing things, including the ability to
> validate public keys end-to-end, and some way to check that the
> executable applet corresponds to the examined source. Without these
> features the system cannot reasonably be called secure, so there
would
> seem to be scant reason to really get into the code.
>
> As far as I know, none of their technical people are talking about
> these problems, or what they intend to do about them. It is a beta
> system, but maybe they are just selling the site as is.
I've gotten some answers from [EMAIL PROTECTED] Draw
your own conclusions. All the quotes are from email
sent 6/13 and 6/14.
Java applet validation:
"
Use the "l" command on the Netscape Java Console to dump our
classfiles
to a directory. They will be in a jar file in <netscape
home>/Communicator/Program.
Compile the source using Sun's JDK 1.1.7 for Windows. Put it in a jar
file.
Extract the manifests from the two jar files. They will contain
hashes
of the classes in the archives. Compare the hashes of our classes
with
those of the classes you compiled.
If you don't trust the manifest in our jar file, simply extract the
classes,
and create a new jar file. This will automatically create a fresh
manifest
that is guaranteed to be accurate.
In the future, we hope to offer a plug-in that will automate this
tedious
process.
"
Making it easier to view someone else's key fingerprint:
"Sure, we'll do something about that in a future version."
Displaying the recipient fingerprint on encryption:
"That's a good idea."
Trapping weak user-chosen passphrases(> is me speaking):
"
>S1. OK, it's a lower priority than implementing a change-passphrase
>feature, but it would be a big
>security improvement to have a check when someone chooses a
passphrase
>to tell them how good
>it is. Let's face it, in real life the biggest security risk you
face
>is sloppy customers. If you prevent
>someone from using "Cookie" or "Secret" as a passphrase, you prevent
>getting blamed for a
>problem that the user caused.
In our FAQs and elsewhere we stress the importance of choosing a very
secure passphrase as it is the key to the security of our system. It
is up to our users to take that information and use it. But, you
offer a good suggestion.
"
What happens if the server is compromised:
"
>Q1. How long are encrypted messages stored in your backups and log
>files? In other words,
>if your facilities got subpoenaed or seized by someone who knew how
to
>run a passphrase
>cracker, how much mail would be at risk?
These are actually three questions, and we'll try to answer them the
best we can. Encrypted Messages are stored on the server
indefinitely, the only limit is on storage, which is currently 1MB.
Our servers are in Canada, so it would be up to the Canadian
government to subpoena our records, not the U.S. government, and we
will just have to cross that bridge when and if we come to it. The
passphrase is not stored on our servers. When you log in a secure,
one-way hash of the passphrase is sent to us for verification
purposes, but the passphrase itself is never in transit, nor is it
stored on our servers.
>
>Q2. How long do you keep logs showing what IP address a login came
>from?
Currently, logs are wiped daily.
"
Hope that's useful!
- --
f r e d e r w <atsign> p o b o x . c o m
Boycott spammers!
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>
iQA/AwUBN22w1nJQgJ+siYlMEQLrSwCfQcPzgrimkzrS0F9m6+sQAgv9krwAn0ME
m0Nx1XFPxCs8BHZ5c7BL255L
=Igrx
=====END PGP SIGNATURE=====
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Sun, 20 Jun 1999 13:23:12 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Last month I came across an implementation for RC4
> on the web. After which I started monitoring this NG
> and believe I understand how RC4 works. What I
> don't know, is how secure it is. Can someone
> comment on how relatively secure RC4 would be
> against common cyptoanalysis?
Apparently RC4 is still secure. It is used most commonly in SSL in
north america. I would imagine the only weakness in RC4 is the
possibility of short cycles but I dunno.
I have never seen any cryptanalysis of RC4 so if you find something
please pass it along.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher
Date: Sun, 20 Jun 1999 13:20:54 GMT
In article <[EMAIL PROTECTED]>,
Anonymous <[EMAIL PROTECTED]> wrote:
> This is the first cipher that i ever made, the the question for you
is can
> you decode the encrypted message, i will even give you the passkey
> i know this is trival at best, but i need to know how you cracked it
so i
> can learn... please
Well if you want to learn post the algorithm and we can have a crack at
it (excuse the pun).
I briefly looked at the ciphertext and it doesn't appear to be a
monoalphabetic substituion. It isn't is it?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Where can i get the code from Bruce Schniere's applied crytptography?
Date: Sun, 20 Jun 1999 13:25:00 GMT
In article <[EMAIL PROTECTED]>,
"J.J." <[EMAIL PROTECTED]> wrote:
> as title,
> thanks
Get the book or buy his diskette set. They are not available free on
the net.
Most ciphers however include the source on their home pages.
IDEA - www.ascom.com
BLOWFISH - www.counterpane.com
RC5 - www.rsa.com (look up rivests MIT page)
etc...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Sven Knispel" <[EMAIL PROTECTED]>
Subject: Re: Where can i get the code from Bruce Schniere's applied crytptography?
Date: Sun, 20 Jun 1999 14:23:51 GMT
ftp://ftp.replay.com/pub/crypto/applied-crypto
check the index file !
-Sven
--
=============
E-mail: remove "nospam" from reply address
J.J. wrote in message <[EMAIL PROTECTED]>...
>as title,
>thanks
>
>
>
------------------------------
From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 21 Jun 1999 06:13:06 GMT
John B. Andrews wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
>
> > [EMAIL PROTECTED] (James Pate Williams, Jr.) wrote, in part:
> >
> > >The response is intended for a wider audience that the original
> > >poster. I hope you are being facetious at my expense.
> >
> > It's just that that sort of response _to_ the original poster - on a
> > systematic basis, yet - will tend to be regarded as discouraging, or
> > even taunting.
>
> Seems to me it could just as easily be taken as a helpful hint that the
> original poster should get a friend in the U.S. to request the wanted
> information and forward it to him...
in other words a friend in the u.s. who is willing to break the law...
export restrictions on munitions apply, which is why mr. williams made
the qualification in the first place... you can only get it from the
source mentioned if you're in the u.s., to then export it out of the
country you break the exact same law that the originally mentioned
source is trying to avoid breaking by disallowing access to non-u.s.
residents...
------------------------------
From: "GyungHwa Jun" <[EMAIL PROTECTED]>
Subject: Re: Good book for beginning Cryptographers?
Date: Mon, 21 Jun 1999 06:16:42 GMT
"Handbook of Applied Cryptography" written by Alfred Menezes, Paul C.van
Oorschot, Scott A. Vanstone.
Who me? <"binthr"@@hotmail.com> wrote in message
news:X8ib3.158688$[EMAIL PROTECTED]...
> Can anyone/everyone recommend a good book for a beginner, (please not a
> slow book, one that is fairly advanced but covers all areas)
>
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Good book for beginning Cryptographers?
Date: Mon, 21 Jun 1999 00:51:51 -0700
Who me? wrote:
> Can anyone/everyone recommend a good book for a beginner, (please not a
> slow book, one that is fairly advanced but covers all areas)
Decrypted Secrets, by Friedrich Bauer.
--
Jim Gillogly
Highday, 1 Lithe S.R. 1999, 07:51
12.19.6.5.6, 10 Cimi 14 Zotz, Seventh Lord of Night
------------------------------
Reply-To: "Andy Jeffries" <[EMAIL PROTECTED]>
From: "Andy Jeffries" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk
Subject: Re: alt.security.scramdisk
Date: Mon, 21 Jun 1999 09:25:17 +0100
> >Just to let you all know, there is now "alt.security.scramdisk" created.
>
> And amazingly, the group is already getting spammed!
And in my typical efficient manner a complaint has been sent. :-)
--
Andy Jeffries
alt.security.scramdisk Proposer
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Security ... or just lies ....
Date: Sun, 20 Jun 1999 10:48:58 -0600
In article <[EMAIL PROTECTED]>, "Markku J. Saarelainen"
<[EMAIL PROTECTED]> wrote:
> It appears that some VERY popular encryption applications are just used
> as covert instruments to control encryption market place and the
> security of messaging. Just remember who developed and started using the
> internet first. In fact, some authors of these popular programs appear
> to have some significant working connections to some information
> security architecture departments. Just a thought ... !
You mean, serious now, that there are some who might want to manage
crypto, topdown? Naw...what gave you the first clue?
--
"I want to make laws. We don't make donuts here." --John Conyers
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: *** FAKE KEYS AGAIN ***
Date: Mon, 21 Jun 1999 09:17:49 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Soylent Grin <Charon@Rocket*NOSPAM*mail.com> wrote in message
news:[EMAIL PROTECTED]...
>
> Michel Bouissou <[EMAIL PROTECTED]> wrote in message
> news:7kg5n3$f4e$[EMAIL PROTECTED]...
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > The malevolent forger that plays creating fake PGP keys
bearing my
> > name striked again, as I just found on keyservers a FAKE PGP
key
> > bearing my name, that tries to imitate as much as possible my
true
> > key:
<SNIP>
> How do we know this isn't a clever ruse by the forger using the
cleverly
> forged key and not the real one?
> What if you are the fake and pointing us to the fake key?
>
>
> Kirk
Simple... Download the key with which this message was signed and
check out the signatures on the key...
How man forged keys do you know of that have been signed by
PRZ??????????? ;-)
- --
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
=====BEGIN PGP SIGNATURE=====
Version: 6.0.2ckt http://members.tripod.com/IRFaiad/
iQA/AwUBN231Je0ty8FDP9tPEQLkuwCgx9hWBCels+WY5kW2vlrPjmGfuigAn3H1
qcKd5eKxUjSQ9c+y8RGIF1Lj
=2Rwb
=====END PGP SIGNATURE=====
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
