Cryptography-Digest Digest #586, Volume #9 Sun, 23 May 99 21:13:03 EDT
Contents:
Re: HushMail -- Free Secure Email (John Kennedy)
Re: TwoDeck ([EMAIL PROTECTED])
Re: HushMail -- Free Secure Email (John Kennedy)
Re: blowfish hints anyone? ([EMAIL PROTECTED])
Re: Reasons for controlling encryption (Dutra de Lacerda)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: DSA (Digital Signature Standard) and the Schnorr Patents ("Roger Schlafly")
Re: Reasons for controlling encryption (William Hugh Murray)
Re: blowfish hints anyone? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Kennedy)
Subject: Re: HushMail -- Free Secure Email
Reply-To: [EMAIL PROTECTED]
Date: Sun, 23 May 1999 21:07:24 GMT
On Sun, 23 May 1999 20:35:21 GMT, William Hugh Murray
<[EMAIL PROTECTED]> wrote:
>This is a multi-part message in MIME format.
>--------------DF5617F28F17FFDB8AC113AD
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>John Kennedy wrote:
>>
>> On Sun, 23 May 1999 16:57:56 GMT, William Hugh Murray
>> <[EMAIL PROTECTED]> wrote:
>>
>> >If I were the NSA, I think that I would buy hushmail now while the
>> >price is still low and while I can still hope to do so secretly.
>> >
>> >In any case, it seems to me that hushmail is a third party in which I
>> >would have to have at least as much trust as I have in MIT. It seems to
>> >me that they have a smaller claim to such trust as an institution and
>> >that vetting and demonstrating their implementation will be more
>> >difficult. What am I missing?
>>
>> I think it is possible to implement a hushmail type system where the
>> only trust required is in one's ability to evaluate the source code
>> and strong crypto.
>>
>> Are you saying you need to trust MIT because they hold public PGP
>> keys?
>
>
>> But you don't really have to trust them, nor should you for
>> something very important. Yes they can fiddle with the keys if they
>> choose, but you can verify the fingerprint of your targets key. No
>> trust in MIT neccessary.
>>
>
>No but MIT is trusted to some degree as the source of the code. That is
>to say, most people who download PGP do not do all of the necessary
>tests to ensure that they got reliable code. It is sort of like
>science; most of us do not repeat all of the experiments that we rely
>upon.
Understood. My point was simply that you don't *need* to trust them,
you can in principle verify, or rely on the verification of another
trusted party or parties.
>
>As Lincoln said, you can fool some of the people all of the time. If
>one is in the contract carrier business, one is not motivated to do
>that. However, if one is in the police state business, the FUD
>business, or the surveillance business, that is enough.
>
>As it stands now, NSA can read any message that it wants but it cannot
>read every message that it wants. If they want to keep a secret which
>messages it has read, that reduces further what it can read. That is,
>it must break codes, not merely fingers.
>
>> If the source code of a hushmail type system is sound then I don't see
>> that it matters if the NSA owns the system. If it's not sound, lack of
>> ownership won't be an obstacle for the NSA.
>
>Necessary but not sufficient. At a minimum, every user must validate
>the applet everytime they use/download it. In practice, it is likely
>that most users will never do it, much less always to it. This is
>different from PGP where one downloads and validates, once, and then
>uses, in a separate step not obvious to the carrier.
Very good points which a hushmail-type system needs to try to address.
>
>Similarly, most users will rely very heavily on the same third party for
>public keys. Few will ever check a key out-of-channel, much less ensure
>that they, and the software, are using the intended key for each
>message.
>It seems to me that the problem is a human one rather than a technical
>one. "There are human solutions for technical problems but there are no
>technical solutions for human problems."
True enough. You can't use any tool effectively without observing it's
operiational requirements. If you have not verified the key of your
intended recipient, you don't know your message is secure.
--
John Kennedy
--
The causal world imposes a nonarbitrary distinction between detecting in one's visual
array
the faint outline of a partly camouflaged stalking predator and not detecting it
because of
alternative interpretative procedures. Nonpropagating designs are removed from the
population, whether they believe in naive realism or that everything is an arbitrary
social
construction.
(Tooby and Cosmides, in _The Adapted Mind_, Barkow,
Cosmides and Tooby, editors )
=======
Best Anarchy Links:
David Friedman -> http://www.best.com/~ddfr/
Niels Buhl -> http://www.math.ku.dk/~buhl/
Billy Beck -> http://www.mindspring.com/~wjb3/promise.html
========
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TwoDeck
Date: Sun, 23 May 1999 21:21:25 GMT
> Having done so, I note that it is interesting, but it has some flaws
which
> were already mentioned by others. It generates a stream cipher
sequence
> which consists of successive permutations of the N values (i.e.,
> successive groups of bytes containing one copy each of values 0
through
> 255), and the shuffling algorithm isn't particularly good.
Yeah well I wanted a fast shuffling algorithm, If i were to use the RC4
shuffling, I might as well use RC4 :)
> However, tweaks are always possible, and this is an interesting idea.
I
> might suggest something like FourDeck to solve the problem of the
delay
> between repeats of the same byte. The shuffle might use three bytes
of key
> - one for the shuffle point, one for an offset between halves, one to
pick
> a decimation. However, even that is inefficient: if one is moving
each of
> the 256 objects in a deck, one would like to introduce a little
randomness
> with each one moved.
The problem with using multiple layers is that for any outputer there
will always be 2^8n possible permutations of that byte, and finding it
would be rather simpler. You can always test for permutations which
are valid for multiple blocks... etc...
Ideally if the first deck were completely permutated then it would be
secure, but to a point. You would have to shuffle the entire twodeck
function faster then 256 RC4 shuffles to be faster...
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (John Kennedy)
Subject: Re: HushMail -- Free Secure Email
Reply-To: [EMAIL PROTECTED]
Date: Sun, 23 May 1999 21:25:04 GMT
On Sun, 23 May 1999 20:49:42 GMT, William Hugh Murray
<[EMAIL PROTECTED]> wrote:
>This is a multi-part message in MIME format.
>--------------0A7CAEB7CB93EB5175649A6F
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>John Kennedy wrote:
>>
>> On 23 May 99 14:35:01 GMT, [EMAIL PROTECTED] () wrote:
>>
>> >John Kennedy ([EMAIL PROTECTED]) wrote:
>> >: On Sat, 22 May 1999 11:18:07 +0100, David Crick <[EMAIL PROTECTED]>
>> >: wrote:
>> >
>> >: >Total security would also require users to be running 128-bit crypto
>> >: >browsers, something which isn't clearly stated on the web site.
>> >
>> >: >public/private keys are stored on their server, encrypted with Blowfish.
>> >
>> >: Assuming the source code checks out, I don't see how this can be a
>> >: scam nor why a 128-bit crypto browser would be required.
>> >
>> >A 128-bit browser certainly isn't required for operation. I suppose one
>> >could be required for adequate security if it was used for setup.
>> >
>> >: Having both keys will not allow anyone to decrypt your message if they
>> >: don't have the passphrase, will it?
>> >
>> >No, the passphrase is used to protect encrypted copies of the keys. Having
>> >your private key is enough to allow decryption of all your incoming mail.
>>
>> Wow thanks, clearly I've been laboring under a fundamental
>> misconception.
>>
>> I'm new at this, but I want to understand it properly.
>>
>> As I review the PGP manual I see it says the private key is protected
>> by the passphrase. Does that mean essentially that the private key has
>> been conventionally encrypted with the passphrase?
>>
>> So now it seems to me that one of the requirements for a hushmail
>> system to be secure is that the system only holds an encrypted copy of
>> your private key,...
>
>Ideally, for security, not even that. However, to enable one to
>retrieve mail from anywhere, an encrypted copy of the key would have to
>be stored on the server and then retrieved for use.
>
>> which cannot be used to decrypt your mail without
>> your passphrase. You should be able to verify that the client side
>> program follows this proceedure without compromising your passphrase,
>> and then your mail is secure from the people running the system.
>>
>> Am I getting warmer?
>
>Close, but no cigar. PGP compresses the pass-phrase into 128 bits and
>uses that for the block-cipher key to protect the private key. [Note
>that if there is not 128 bits of entropy in the pass-phrase, that would
>reduce the cost of attack.]
Assuming there are 128 bits of entropy in the passphrase, how secure
is the encryption of your private key compared to the encryption of
your messages, would you say?
What would it take to crack such an encrypted private key?
>>
>> And to prevent the man-in-the-middle issue, don't both parties need to
>> be able to verify a fingerprint of the other's public key as with PGP?
>
>Yes, out of channel.
>
>> How could that requirement be addressed in a hushmail type system? Is
>> it addressed? If it's at the hushmail site I've missed it my initial
>> browsing.
>
>Don't know and suspect that it isn't.
Well if it isn't addressed then you have no way of knowing if there is
any security to the system at all.
My inital sense is that there is a way of making this work safely, but
that does not mean hushmail has done so.
--
John Kennedy
--
The causal world imposes a nonarbitrary distinction between detecting in one's visual
array
the faint outline of a partly camouflaged stalking predator and not detecting it
because of
alternative interpretative procedures. Nonpropagating designs are removed from the
population, whether they believe in naive realism or that everything is an arbitrary
social
construction.
(Tooby and Cosmides, in _The Adapted Mind_, Barkow,
Cosmides and Tooby, editors )
=======
Best Anarchy Links:
David Friedman -> http://www.best.com/~ddfr/
Niels Buhl -> http://www.math.ku.dk/~buhl/
Billy Beck -> http://www.mindspring.com/~wjb3/promise.html
========
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: blowfish hints anyone?
Date: Sun, 23 May 1999 21:25:15 GMT
> 1) When would it be preferable to use the ECB type instead of CFB?
ECB is only usefull for truly random data (keys, etc...), use CFB or
CBC if possible. CFB is for stream ciphers though.
> 2) Would you just have a standard, "built-in" IV, or do programs get
this
The IV is normally private.
> 3) How do you make use of the 448-bit (max) key length of Blowfish
when
> people generally are only going to enter a single word in as their
password?
Well normally passwords are hashed, but I would suggest to your users
to use longer passwords. You could pass the password as a key to the
blowfish algorithm and output a key in CFB for longer keys, but they
are only as secure as the password. Generally between 10 and 20 words
is a standard password, and mixed case/symbols...
What are you actually designing? Sounds like you are a bit confused.
If you are going to encode live data, use a CFB mode, unless the data
is fast enough to warrant CBC mode.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Dutra de Lacerda)
Subject: Re: Reasons for controlling encryption
Date: Sun, 23 May 1999 22:57:39 GMT
On 21 May 1999 23:22:22 GMT, [EMAIL PROTECTED]
(Mike McCarty) wrote:
>I'm much more afraid of what criminals in government can do than what
>common criminals outside of government can do.
Likewise... The greed for power over the citizens is a very bad sign.
>Let's suppose that everyone having crypto allows some people to commit
>some dastardly deeds in secret, and we can't find them. Well, that
>means that some private criminals are getting away with some bad stuff.
[Considerations]
Is there any crime that demands computers? Like a murder or robery?
Actually every crime never needed computers or even paper.
I cannot see how words on paper, or other may be a crime since they
are not needed. Obviously the reason is NOT the silly one stated.
[Data #1]
On the other hand: See the atempt to forbiden crypto by civilians.
They call it a weapon... Well... then polititians are major criminals
as they speek a lot. (weapon).
What about cars ?!?
- They are used to deliver drugs
- They are changed in Bombs...
- and so on...
But as weapons they are not illegalized nor its usage conditioned.
[Data #2]
ECHELLON system will not work if people can escape political control
by the state. And that's the point. Reasons behind ECHELLON are the
reasons behind the attempt to control peoples privacy... and to
monitor theyr lives. Why?
[Data #3]
Monitoring society is a need to any totalitarian government SPECIALLY
in the case of a New Kind of Power.
And, Allways, attempts have been made by some persons to control
others... it's almoast Atavic.
[Data #4]
We know these people are eager to power and that State Control is a
mean for them to get it... Liberty Constitutions are not a stop but an
excuse: "We live in liberty so those thingds do not happen" . They do!
Neather are the main believes of whole populations because these
persons do not believe anything... they are chameleons and say any
thing if apropriate. They are the most fit, by it's hidden cinical
view of human kind, to get the higher positions.
[Data #5]
All this situations have a comon goal... and are only possible because
people gives them Power... And society gives them them "Bread and
Circus" to a better sleep...
[Conclusion]
It's a bad idea to be limited to the Media... And conditioned by them.
It's up to every citizen to fight for its liberty and dignity.
But how ?!? If people are conditioned ?...
By discovering that the power is virtual and not real.
By reminding that crime is a matter of consciousness, not law!
By being brave!
By growing from theyr present, and feeded, chieldwood.
By awaking up!
Best regards,
Dutra de Lacerda.
(I subscribe my philosophy)
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 23 May 1999 05:00:36 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Sun, 23 May 1999 17:35:04 -0700
Vin McLellan wrote in message <[EMAIL PROTECTED]>...
> Actually, I don't think of the NSA's plots to deny everyone
>but themselves (and those they dub worthy) access to strong un-GAKed
>commercial cryptography as a conspiracy, per se. NSA officials acted
>upon a fairly open if Byzantine strategy. It was hatched by men who
>obviously believe that Western liberal society is best safeguarded if
>the US can continue to glean the benefits of the huge passive
>eavesdropping net that has for decades sustained America's
>geo-political dominance.
Ok, but how does this fit into DSA and Schnorr? There was never a
requirement for GAK of DSA signature keys. Use of DSA keys does
not enable the feds to spy on you. If the they got your signature private
key, all they'd be able to do is forge your digital signature. They have
no interest in doing that. But if you don't trust DSA, then don't use it.
The DSA was going to be used in the Hillary health plan. No doubt
that plan would have violated the sense of privacy that many people
have. But was DSA the cause of it? I don't see how. Signatures are
only used for authentication.
> I think they're wrong, and I think their efforts are futile,
>but no one can deny they have effectively stalled widespread use of
>strong crypto for a fifteen years, and will for a bit longer.
They have stalled the export of strong crypto, but beyond that, the
influence has been minor. Strong crypto is completely unregulated
within the US. In some ways, the NSA has promoted the use of
crypto -- its endorsement of DES, DSA, SHA-1, etc were all
positive, IMO.
> Again, in 1992, at least two firms of patent law specialists
>hired by NIST to review the prospect of defending the DSA against a
>Schnorr challenge declared themselves uncertain of the outcome of any
>court case. Then, those opinions had a significant impact on US
>policy.
I don't believe it. NIST had some concern about the Hellman-Merkle and
the Diffie-Hellman patents, but I don't think there was significant concern
about the Schnorr. Schnorr's main patent claim is for a specific
identification
system in a smart card and reader. The connection with DSA is not very
apparent until claim 6 which mentions a prime subgroup. But claim 6 is
dependent on all the earlier claims, including the smart card, reader, the
specific Schnorr formulas, the hash function, and even the "rejuvenation".
The rejuvenation claim is not likely to be infringed by anyone since it is
difficult to use it securely based on information in the patent.
> Eight years ago, the standardization of the DSA in the DSS --
>in the face of the already widespread acceptance of RSA (which offers
>both authentication and key-management) as a de facto industry standard
>-- was explicitly intended to inhibit vendor (and user) access to
>confidentiality.
This is ridiculous. It is like saying that the Apple Macintosh was intended
to
thwart desktop computing because DOS was already widely accepted.
DSA was, and is, an alternative. Those who were happily using RSA
continued to do so. Govt users were supposed to use DSS, but I don't
think that was ever enforced. (There are govt agencies using RSA today.)
You can get key management with DSA just as easily as you can with RSA.
It is called Diffie-Hellman. It is true that the govt preferred was of doing
it
(KEA) was classified, but there were other techniques in the literature
and in common use.
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Mon, 24 May 1999 00:41:39 GMT
This is a multi-part message in MIME format.
==============EE297664AC853A6DEA7C7BBC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Markku J. Saarelainen" wrote:
>
> The story of many open market standards may often be more complex than it may seem
> in some news. One should always try to analyze very carefully all product options
> and development processes prior to the use of any product. In some cases, newly
> discovered and slightly modified Indian smoke signals may be better than some others
> :)
>
> Any thoughts...?
You are, of course, right. The problem is that, be definition, one
cannot have enough information to recognize such a case.
==============EE297664AC853A6DEA7C7BBC
Content-Type: text/x-vcard; charset=us-ascii;
name="whmurray.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for William Hugh Murray
Content-Disposition: attachment;
filename="whmurray.vcf"
begin:vcard
n:Murray;William Hugh
tel;fax:800-690-7952
tel;home:203-966-4769
tel;work:203-966-4769
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:William Hugh Murray
end:vcard
==============EE297664AC853A6DEA7C7BBC==
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: blowfish hints anyone?
Date: Mon, 24 May 1999 00:16:00 GMT
"Matthew Bennett" <[EMAIL PROTECTED]> wrote:
> Having decided to scrap my original "homemade" encryption method and
use Blowfish instead,
Clever move.
> 1) When would it be preferable to use the ECB type instead of CFB?
Suppose you want to crack an ECB scheme. You build a reverse
codebook containing a common plaintext block, e.g., "Subject:".
Then, given captured ciphertext, you look for instances of the
encrypted "Subject:" block. When you find one you have identified
the key.
In CBC the encrypted "Subject:" would map to different ciphertext
depending on prior blocks.
Consider also an ECB video stream. If the background doesn't
change, you'll see silhouettes.
> 2) Would you just have a standard, "built-in" IV, or do programs get
this from your password instead?
What would be the point of a public (ie, fixed) IV?
The whole point is to make the eavesdropper's task harder.
> 3) How do you make use of the 448-bit (max) key length of Blowfish
The algorithm specifies how to duplicate a key to fill up
the 448 bits. You simply replicate: Fubar becomes FubarFubarFubar...
You realize that 128 bits is considered secure, so anything
over this is fine.
Humans will have a hard time remembering that much.
Ideally you use a passphrase to encrypt a truly random key;
that truly random key is the actual crypto key. It means
that even if They get your key disk, they still have to
try lots of passphrases (or rubber-hose you). Read the
PGP manual.
In the crypto field, you will learn to translate "Why?" into
"What attack does this repel?". Security = understanding
and compensating for threat models.
If you're just a programmer needing crypto, well, using
a publicly evaluated algorithm is vital. There are other
issues (like using CBC, not swapping state to disk, key generation,
etc.) depending on your threat model.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
** 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
******************************
