Cryptography-Digest Digest #584, Volume #9 Sun, 23 May 99 16:13:02 EDT
Contents:
TwoDeck
Re: Crypto Book Wins Award (Medical Electronics Lab)
blowfish hints anyone? ("Matthew Bennett")
Re: HushMail -- Free Secure Email (William Hugh Murray)
Re: Can I have some opinions please?
Re: Musing on and Factoring of a (special) 782-bit Modulus (Ted Kaliszewski)
Re: HushMail -- Free Secure Email (Geoff Thorpe)
Re: HushMail -- Free Secure Email (William Hugh Murray)
Speakable, readable encryption, language dependent (DGoncz)
Re: breaking xor encryption? (Jerry Coffin)
Additive RNGs ([EMAIL PROTECTED])
Re: HushMail -- Free Secure Email (John Kennedy)
Re: HushMail -- Free Secure Email (John Kennedy)
Re: Reasons for controlling encryption ("Markku J. Saarelainen")
Re: looking for independant encryption strength analysis (William Hugh Murray)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: TwoDeck
Date: 23 May 99 16:17:39 GMT
I have delayed looking at TwoDeck, since reading PostScript files is
somewhat awkward for me.
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.
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.
I envisage turning TwoDeck into something like RC4 in a MacLaren-Marsaglia
configuration to obtain security...
John Savard
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Crypto Book Wins Award
Date: Fri, 21 May 1999 11:40:07 -0500
William Stallings wrote:
>
> My book,
>
> Cryptography and Network Security: Principles and Practice, Second Edition
> Prentice-Hall, 1999, ISBN 0-13-869017-0
>
> has just received the 1998 award for the best Computer Science and
> Engineering textbook of the year, awarded by the Text and Academic Authors
> Association.
Congratulations!
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: blowfish hints anyone?
Date: Sun, 23 May 1999 18:15:45 +0100
Hi,
Having decided to scrap my original "homemade" encryption method and use
Blowfish instead, there's a few things I'm not quite sure about. I've got
my blowfish implementation giving the correct output to the standard test
vectors in both ECB and CFB mode.
Some of these questions might be obvious/stupid/both, but I've had no real
luck searching the www or usenet to answer these particular ones:
1) When would it be preferable to use the ECB type instead of CFB?
2) Would you just have a standard, "built-in" IV, or do programs get this
from your password instead? If the answer is the former, would you just make
up any two numbers to use?
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?
Do you just fill the rest up with zeros, or only take it as a (for example)
10-bit key? (..this can't be right..)
Thanks for any help.
Matt
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Sun, 23 May 1999 17:17:06 GMT
This is a multi-part message in MIME format.
==============3902785A8BCEECC5D83962CC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[EMAIL PROTECTED] wrote:
>
> Roger Schlafly ([EMAIL PROTECTED]) wrote:
> : Terry Ritter wrote in message <[EMAIL PROTECTED]>...
> : >But even if not, if the code was developed outside the US, how is
> : >*importing* it a problem?
>
> : I don't know. If circumventing the US export laws were that simple,
> : Microsoft and others would user a foreign unit to develop outside the
> : US.
>
> Well, Sun does do something like that.
>
> Essentially, the export laws prohibit a U.S. resident or citizen from
>
> - exporting cryptographic software,
> - writing such software while abroad,
> - directly assisting people abroad who are writing such software,
> - having foreign employees write such software abroad.
>
> But they *can* purchase encryption software from a foreign firm, whether
> it is off-the-shelf, or _custom-designed to their specifications_. That is
> the only "loophole" in the export laws as they now stand, and it takes
> good legal advice to walk through it.
>
> John Savard
I do not understand the relevance of law here. It seems to me that the
law only comes into this when fear, uncertainty, and doubt fail. The
issue here seems to be trust. That is usually fragile in any case but
when both the hammer and the anvil are held by the US government, it
would seem to me to be easy enough to destroy. While this government
demonstrates little skill in building or preserving trust, it is great
at FUD.
It seems to me that NSA should have learned from the DES, RSA, PGP and
Cylink that the longer you wait the higher the cost and the lower the
chances or scale of success. (Would you buy crypto from a firm headed
by a former director of NSA?)
What am I missing?
William Hugh Murray
New Canaan, Connecticut
==============3902785A8BCEECC5D83962CC
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
==============3902785A8BCEECC5D83962CC==
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Can I have some opinions please?
Date: 23 May 99 17:11:48 GMT
Pwrk ([EMAIL PROTECTED]) wrote:
: (Don't ask for source code, I lost that ages ago.)
Maybe you remember what the algorithm was? Otherwise, unless it is
*really* bad, it will be hard to say anything about it just by running it.
And disassembling a program is a _lot_ of work.
John Savard
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: Musing on and Factoring of a (special) 782-bit Modulus
Date: Sun, 23 May 99 12:52:06 -0500
Responding to the comments re my posting on the factoring of a
(special) 782-bit modulus, let me note the following:
Let us make a fair assumption that the architects of public key
cryptosystems are both knowledgeable and conscientious. That implies,
among other things, that any modulus they generate, randomly or
otherwise, is throughly tested for all known (to them) vulnerabilities.
Now, how can they be certain that the system they create is, indeed,
secure? Do they carry a liability insurance to protect themselves in
the case the system is not? I am not talking here about grocery shopping
on-line.
I have in my inventory of codes close to a dozen of moduli con-
structions that impart no security to the system. The 782-bit modulus
cited in the posting was created by one of them. I have also some
constructions that, at present, appear to be invulnerable to factoring.
Since an average user of encryption is not likely to be equipped to
test those matters for himself, there is little choice but to trust
the system providers. Frankly, I would think twice (?) about entrusting
my critical transactions to them, grocery shopping excepting.
Finally, the issue of complexity: my impression is that it usually
is linked to a specific factoring algorithm. While I have no data to support
my observation I suspect that the running time of algorithms used to
factor the "vulnerable" moduli is neither exponential nor polynomial.
They seem to use no time at all!
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Sun, 23 May 1999 14:07:45 -0400
Hi there,
> Essentially, the export laws prohibit a U.S. resident or citizen from
>
> - exporting cryptographic software,
> - writing such software while abroad,
> - directly assisting people abroad who are writing such software,
> - having foreign employees write such software abroad.
>
> But they *can* purchase encryption software from a foreign firm, whether
> it is off-the-shelf, or _custom-designed to their specifications_. That is
> the only "loophole" in the export laws as they now stand, and it takes
> good legal advice to walk through it.
It is also (apparently) prohibited to provide crypto-related "hooks"
into which foreign software can plug directly into - the mozilla project
went through some degree of code-pruning to pull out crypto and all
hooks to it before they satisfied the powers-that-be that it was
acceptable to release source (I'm going from memory of an article here,
others may know better).
My read on this is: if the hooks are crypto-specific it's bad, if they
are generic (of which crypto may just be one creative use thereof) then
it's ok ... makes very little sense to me, but I guess that would be the
consensus here anyway. Eg. if a browser/mail product could just try to
load ssleay.dll, cl32.dll or whatever (or the shared-lib Unix
equivalents) at run-time and allow it to handle SSL/SMIME comms that
would be BAD(tm). If on the other hand products expose generic APIs for
handling of arbitrary MIME types (or port numbers for web) then that
would be ok - then if someone actually chose to handle the S/MIME types
(or the https port) then that's ok, the US software didn't actually
supply "crypto"-hooks. Eudora, MS outlook, etc all have foreign written
crypto plugins so I think this must be the case.
I'm not sure if it's straight-forward to hook into Netscape Communicator
or MS-IE to handle all https stuff - but sticking a proxy entry in and
going through a local SSL proxy is a much simpler way anyhow (or using
Fortify to bump Communicator's export-SSL back up to normal).
Anyone in the US more familiar with the details want to clarify the
"hooks" issue?
Cheers,
Geoff
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Sun, 23 May 1999 16:57:56 GMT
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?
William Hugh Murray
New Canaan, Connecticut
------------------------------
From: [EMAIL PROTECTED] (DGoncz)
Subject: Speakable, readable encryption, language dependent
Date: 23 May 1999 18:22:41 GMT
The fellow seated next to me in C programming class said that by allocating a
then-unavailable amount of RAM to a 26 x 26 x 26 x 26 matrix, an output of
synthetically generated printed language could be generated which, when read or
spoke, would sound a lot like English. I assume this can be done with any
character based language. The value of each cell in the matrix would be the
probablity that, in the text sampled, the four characters which are the indices
to that location would be found in that order in the text.
Might an encryption algorithm to scramble text to text be useful, following
this pattern? Such text would be speakable, readable, and yet meaning-free
until decrypted. It would be possible for a stenographer to trascribe the sound
of a conversation without becoming aware of what was said. I think I'll ask my
mother about this. She was an executive secretary for several years and types
as well as steno.
Just another example of information that can be passed through various channels
with certain amounts of noise.
Yours,
Doug Goncz
Replikon Research (PO Box 4094, Seven Corners, VA 22044-0094)
Please DO copy your reply to me via e-mail.
I like and use: 800-CAMPMOR 800-DIGIKEY 800-BATTERIES 800-NASHBAR
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: breaking xor encryption?
Date: Tue, 18 May 1999 01:23:56 -0600
In article <7hqhuv$p08$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> How does one break the simple xor encryption program?
At least the beginnings of it is covered in the FAQ. Though it's not
mentioned in the FAQ, things like known-plaintext attacks render
breaking an XOR absolutely trivial.
> I'm trying to convince my friend that des and other algorithms are
> not "crap" because a very long key for an xor program is not secure
> at all.
That depends on what you mean by "very long" -- if the plaintext is
less than 10 times (or so) the key-length, it can be somewhat secure.
If it's less than twice the key-length (again, approximately) it's
generally quite secure. If the key consists entirely of randomly
chosen characters, and is at least as large as the plaintext, you have
a one-time pad, against which there isn't even a theoretical attack,
not to mention a practical one. IOW, the security runs anywhere from
essentially nonexistent to extremely high, depending on the relative
length of the key and the plaintext.
At the same time, it should be noted that if the key is as large as
the message being encoded, then getting the key to the recipient can
be roughly as difficult as getting the message to them secretly would
have been, so the encryption isn't really accomplishing much. Of
course, it's possible to dream up scenarios where a OTP makes sense --
e.g. you hold an annual meeting and give out CD-ROMs full of random
bytes to be used as keys. Throughout the year, when a person receives
a message, they simply use appropriate data from the CD-ROM to decode
it.
[ ... ]
> What if the person compresses the plaintext and get a real random key?
Compressing the plaintext can help, as it increases the entropy of the
characters prior to encryption. OTOH, if the compression isn't
developed specifically for the job at hand, it can hurt considerably.
For example, if you started with a .ZIP file, then encrypted it,
there's header information in a ZIP file that consists of known values
at known locations. An attacker could use this to determine parts of
the key _extremely_ easily. The same is true of most well-known
archive formats, not just ZIP.
[ ... ]
> By the way, what are the main implementation/protocol mistakes
> that people make that cause des and other strong algorithms to be insecure?
The methods are myriad. Just for example, you might want to take a
look at Counterpane's web site, for a few pieces of information
about MS's implementation of VPN. As I recall, they found not one,
but around a half-dozen distinct problems.
------------------------------
From: [EMAIL PROTECTED]
Subject: Additive RNGs
Date: Sun, 23 May 1999 19:00:54 GMT
Does anybody have a better decription on the design and analysis of
additive rngs (lagged fibbonachi...), cause AC has a bad description...
Also does the entire array produce unqiue output streams (which are
2^n - 1 long)? Can you chain them with relatively prime lengths to get
an even longer generator too?
Thanks, (btw C code would be neato too, but a good description will
suffice).
Tom
(Yes I have seen Terry Ritters page but it's too complicated for me
(and contains little information about the specifics)).
--
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 19:15:45 GMT
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, 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?
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?
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.
Thanks for your help, I appreciate it.
--
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] (John Kennedy)
Subject: Re: HushMail -- Free Secure Email
Reply-To: [EMAIL PROTECTED]
Date: Sun, 23 May 1999 19:27:40 GMT
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.
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.
--
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: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Sun, 23 May 1999 15:10:34 -0700
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...?
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: looking for independant encryption strength analysis
Date: Sun, 23 May 1999 19:53:28 GMT
This is a multi-part message in MIME format.
==============B53D9982E8E0FE4F7058ED15
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Matthew, see "Why Crypto is Harder than it Looks" by Bruce Schneier at
www.counterpane.com. Also see the FAQ.
Matthew Bennett wrote:
>
> Hi,
>
> Since I've had no response to my previous posting, I assume getting an
> independent strength analysis of an "un-tested" encryption method is not
> simple enough to be done casually by someone.
>
> As an independent test of the encryption strength of files outputted by my
> program is required for an interested company, I would be very grateful for
> any information people in this newsgroup might be able to offer. Does
> anyone know of a link/e-mail to someone that would be prepared to offer such
> an analysis. I assume they will ask for a fee, so any likely idea of cost
> would also be appreciated. Please bear in mind that I am a programmer, not
> an encryption expert, so I know very little of this subject. I do however
> believe the encryption produced by my program is secure, though
> understandably this company would rather have an independent test performed
> on the encrypted files produced.
>
> Like I have said, any information would be a great help - though obviously
> an actual "encryption strength analysis" contact is mainly what I am looking
> for. I am sure I am not the only one who has needed such a service!
>
> Best regards,
>
> Matthew Bennett
> DataCloak author
> http://www.btinternet.com/~bennett/datacloak.html
==============B53D9982E8E0FE4F7058ED15
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
==============B53D9982E8E0FE4F7058ED15==
------------------------------
** 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
******************************
