Cryptography-Digest Digest #599, Volume #10 Sat, 20 Nov 99 17:13:04 EST
Contents:
Re: technical writing skills required! (William Rowden)
Re: Distribution of intelligence in the crypto field (Jerry Coffin)
Re: ATTN Scott Nelson (CoyoteRed)
Re: Apparently, Hushmail does work (Ian Wehrman)
Re: AES cyphers leak information like sieves (wtshaw)
Re: AES cyphers leak information like sieves (wtshaw)
Re: AES cyphers leak information like sieves (wtshaw)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: AES cyphers leak information like sieves (Lincoln Yeoh)
Re: AES cyphers leak information like sieves (Lincoln Yeoh)
Re: Distribution of intelligence in the crypto field (wtshaw)
Re: AES cyphers leak information like sieves (wtshaw)
Re: ATTN Scott Nelson (Scott Nelson)
Re: Bracking RSA Encryption. Is it possible. (wtshaw)
----------------------------------------------------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: technical writing skills required!
Date: Sat, 20 Nov 1999 18:08:07 GMT
In article <814ded$8gb$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
[snip]
> > Your best bet is to write up sections and post them
> > here for comments.
I think that's a good idea. Posting short sections in a single thread
would make comments easy to find, and edits easy to suggest using the
Usenet quote-response convention.
> > "Practice makes perfect", so start practicing. The skills you
> > learn will include writing, learning (because you learn more when
> > you try to explain things) and politics (because you have to deal
> > with criticism).
Dealing with criticism can be difficult. The noise (name-calling,
arrogance, swearing, etc.) and flames of some when challenged attest to
this. A few posters in sci.crypt only recently received a reprieve from
my killfile. (Though I doubt they know or care.)
> Well the general idea was that I would be writing it, but I wanted to
> have a list of contactees I could get to incase I got stuck.
Those who post a response can be your "contactees."
You already know my *real* email address.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Distribution of intelligence in the crypto field
Date: Sat, 20 Nov 1999 11:20:07 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> See? Echelon is our friend ;) I'm in Sweden - I hardly believe the NSA
> has a black van outside my apartment.
At least in theory, you're a lot MORE likely to have an NSA van
outside your apartment in Sweden than I am here in the US.
I, OTOH, live about halfway between NORAD's headquarters and Falcon
Air Force Base, which is dedicated to working with Air Force (spy)
satellites. I'm _sure_ nobody has any sort of listening equipment
around here... <G>
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: ATTN Scott Nelson
Date: Sat, 20 Nov 1999 18:35:47 GMT
Reply-To: this news group unless otherwise instructed!
So I take it we have a workable scheme to generate/capture really
really random numbers on a common desktop machine without any exotic
hardware?
BTW: Another signal test that we would have to test for is clipping.
Any clipping would destroy our randomness in a blink.
This kind of sounds like a form of encryption, also.
SHA1 a passphrase to get a x bit hash (60, 128, 256 bits, or whatever
is strong), distill this down to 7 bits and with this number to do a
ROT[7 bit variable] (or something) on the first character of your
message and grab that digit as your ciphertext for your first
character. Add the first plaintext character of your message to your
passphrase and then SHA1 /that/ and distill to get the variable for
your ROT[7 bit variable] for the next character in your plaintext and
continue... ANY mistake, that an attacker makes, results in
jibberish.
For each character, your cipher stream in dependant on everything that
came before it. You'll have a unique cipher stream for every
message/passphrase combination.
It just seems too simple to be secure, though.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: Ian Wehrman <[EMAIL PROTECTED]>
Subject: Re: Apparently, Hushmail does work
Date: Sat, 20 Nov 1999 13:42:44 -0600
http://www.hushmail.com/faq.htm#publickey
45. How can it be proved that the HushMail system is actually secure?
Team Hush is currently using a beta version of HushMail. It is in this
beta period that we expect a variety of computer users to test the rigor
of our cryptosystem. The Java source code of HushMail is available to
everyone, free of charge. Security experts and computer enthusiasts
worldwide have the unrestricted ability to try and find any holes within
our system. Our source code can be found at
http://www.cypherpunks.ai/~hush.
later,
ian
John Savard wrote:
>
> A posting in
>
> jyu.ohjelmonti.coderpunks
>
> mentions
>
> http://www.hushmail.com/how_it_works.htm
>
> which seems to indicate that the resident application from Hushmail
> works basically the same way that PGP did; thus, except for the fact
> that its source isn't available, and worries of that nature, there is
> no reason to believe that it doesn't "work".
>
> John Savard (don't snooze, don't snore)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 13:14:53 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I am not in a good position to comment on the weaknesses or otherwise
> of your GVA system. I know that Thomas Jefferson's cypher was pretty
> secure for its time - and that your system certainly appears to offer
> better security than it did.
>
> The system relies on large "random" tables of permutations of the
> alphabet. You do not appear to specify how these tables should be
> generated.
The method of choice defines the security of the system since the security
is totally in the keys. *where it ideally should be*. I have
demonstrated many methods, but those discriptions have been bypassed
recently your convenience; I see the algorithm and the keys as more or
less separate issues, which bothers many who can't imagine athat cipher
ideals are anything but unobtainable goals.
>
> It appears to me that one /potential/ source of weaknessees may lie
> in the manner in which these tables are generated - which does not
> seem to be covered in the description you offer.
>
> I'm arguing that /if/ some types of weakness are discovered, a
> failure to diffuse the plaintext information through the file
> will be likely to make things worse.
Ah! The so called cause and effect of avalanching. Of course, if you want
it, that is not hard to add in some sort of preencryption grooming, or
elsewhere
>
> *If* there is no weakness in the first place, this argument lacks force -
> but who can say with any certainty that their cypher is lacks weaknesses?
Or any other cipher. I can suggest that comments from those who normally
do not talk have been most interesting, as in respect mixed with jealousy,
and what are we going to do now since really strong yet simple encryption
is out of the bag
>
> You can undoubtedly have strength without diffusion. However diffusion
> appears to me to increase whetever strength is already there.
It can, and for some seems to be their only hope, their product becoming a
super-flea as compared with the GVA elephant. The comparison is not out
of line; run the numbers.
...
> Error recovery is not always useful for many types of files with built-in
> compression anyway. With JPEGs, etc it is not easy to recover gracefully
> from point errors, since it is in the nature of the data to magnify
> any faults that occur, during the process of decompression. This /may/ be
> irrelevant - or it may be critical, depending on the appliction.
Jpegs already skirt the line of minimum redundancy, dropping too far down
lots of times. Consider a PICT or a bitmap that does more faithfully
represent the input, being a larger file usually. The results of errors
are as I expect, 1 to 1.
>
> You can still get good error correction by intelligently employing the
> transmission protocols. I believe the cases where this is insufficient
> are now rare - and are becoming rarer as communication fidelity improves.
We could get into rather extensive modem discussions here. There will
always be noise and if not, all or nothing service. The pity is when
service is unobtainable because of unrealistic demands of poor links
bythose that assume they do not exist; the errors get pooled into denial
of service rather than handled as slight problems.
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 13:35:29 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Sat, 20 Nov 1999 00:20:07 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
> >I certainly never said the section you placed quotation marks around.
>
> The quotation marks weren't intended to indicate a direct quote.
> However, if I've inaccurately characterized your views, I'm glad; I
> much prefer it that you are not advocating such things. But David A.
> Scott certainly _does_ seem to hold that kind of viewpoint, which is
> why he has few admirers on this NG.
Scott has some interesting things to say, some I disagree with, some I
agree with, and others that need more discussion.
Best to not be blinded with unfamilair style, which can be from almost any
quarter, from academic and/or insider to...well....picturesque, which
sometimes I may favor with my own flavor; he does have his on vibrado once
you get him going. Best, be ye well entertained by his exuberance.
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 13:48:55 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> My plan is rather to throw out fixed-size block cyphers from my
> intellectual world. I want to avoid EOF issues completely.
Don't do that, studying the obsessions of others is a requirement for
helping them.
>
> From what little I can see, I don't like chaining much, either.
> It's a hack. It's hard to parallelise. I /know/ that having things that
> are hard to parallelise has its benefits in terms of preventing
> cryptanalysis - but I'm not convinced chaining fixed blocks together
> is the way to do this.
A particular chaining defines a new algorithm, which might be useful.
>
> I think that on this occasion, it's best to start again, rather
> than try to work with what you have ;-/
Try not to include all of what logic includes, but I know the feeling;
sitting alone with a blank piece of paper can be a chance to clear away
the cobwebs.
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 20 Nov 1999 20:20:41 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
{...} snip
>I hasten to reiterate, though, that the devil is nearly always in the
>details -- it's entirely possible that in implementing the wrapped
>PCBC mode (or something similar) you could do something that helped
>security a great deal. It's also possible, however, that you could do
>something that hurt security even more. A study has been done to
>prove that CBC does NOT hurt the security of underlying cipher, but
>I'm not at all sure the same can be said of W-PCBC mode. Without
>defining the precise details of how it works (something David Scott is
>unlikely to assist with in any way) it's virtually impossible to do
>such a proof.
Bull Shit Mr J.C. I have never inticated that I would not be willing
to help or assit someone using "W-PCBC" but I have stated that
since it was not invented by the phony Crypto Gods it is highly
unlikely to see the light of day in any AES kind of thing.
>
>Other people are doing research in roughly the same direction, and
>some of them are people who are far more likely to provide useful
>information about it. When/if I know of something similar to the
>study on CBC, it's likely that I'll have a great deal more trust in
>using it.
>
Then they should get there Fuckin asses in gear. Since your
the kind of asshole who cann't decide on the truth or value untill
some phony clown in a suit tells you how to think.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 19:30:02 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 16 Nov 1999 20:53:14 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>It might, but whenever you tie too much of a message into an interlocking
>structure, its survivability as information becomes more fragile. The
But I feel that fragility isn't so much a problem for most civilian
applications.
For military applications I do see why error recovery in crypto is a good
and often necessary thing, coz the attacker can try to jam signals.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 19:35:36 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 16 Nov 1999 21:45:17 -0700, [EMAIL PROTECTED] (Jerry Coffin) wrote:
>You're also apparently ignoring the fact that David Scott's choice of
>chaining mode is a complete disaster in some situations as well. If,
>for example, you're receiving an encrypted message over a radio, and
>interference prevents you from receiving a bit of the message, his
>chaining mode prevents ANY of the message from being decrypted in any
>useful fashion at all. His dynamic pre-compression would prevent the
>remainder of the message from being decrypted, even if the chaining
>mode wasn't used.
For most civilian applications such "fragility" isn't a big problem. The
transport layer should take care of it- it doesn't have to be the crypto's
responsibility at all.
For military apps it could be a problem - especially when the enemy is
trying to jam your signals. For civilian apps, if your opponent is jamming
your signals you can usually sic the lawyers on em.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Distribution of intelligence in the crypto field
Date: Sat, 20 Nov 1999 14:16:34 -0600
In article <[EMAIL PROTECTED]>, M Okra
<[EMAIL PROTECTED]> wrote:
> I think the best way to solve once and for all the questions of whether
> and how far ahead NSA is of the commercial and hobbyist world of
> crypto is to poll this newsgroup. Who could be dissatisfied with that?
>
To be statistically accurate, include an equal number of NSA personel.
(Don't fat chance and slim chance mean the the same thing?)
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 14:09:51 -0600
In article <816fun$p2s$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>.... Guessing the entries to a random S-table is very hard.
> But guess a function that has lower complexity is much easier as the
> number of permutations decreases.
>
This goes to the heart of my wanting to separate main algorithms from
keys, although a suggested key generation procedure might be recommended.
As I do, you do too, have a large enough runtime key that can be produced
by a number of methods. It seems to me that this is a good way to divide
a cryptosystem into better handled subassemblies.
Surely an immense S-table could just as well be generated from a single
pRNG seed to a handpicked series of values equal to the size of the table;
true keysize would be from very small to very large, but the algorithm
would work the same. Don't forget many intermediate generation approaches
that are doable.
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: ATTN Scott Nelson
Reply-To: [EMAIL PROTECTED]
Date: Sat, 20 Nov 1999 19:54:50 GMT
On Sat, 20 Nov 1999 18:35:47 GMT, [EMAIL PROTECTED] (CoyoteRed)
wrote:
>So I take it we have a workable scheme to generate/capture really
>really random numbers on a common desktop machine without any exotic
>hardware?
>
Yes, if you don't count a 16 bit A/D as exotic.
Despite "common knowledge" to the contrary, true random numbers
aren't that hard to come by. But all solutions have their bad
points. Either they're too slow, or they don't work on all
platforms, or they insist on hardware that may not exist,
or they're too expensive. Also, there are lots of bad ones,
and it's hard to seperate the good from the bad. Even if
you have a really good technique it doesn't matter if you
can't prove it works. Who's going to trust it? How can
the average Joe tell it's not another snake oil product?
>BTW: Another signal test that we would have to test for is clipping.
>Any clipping would destroy our randomness in a blink.
>
>This kind of sounds like a form of encryption, also.
>
>SHA1 a passphrase to get a x bit hash (60, 128, 256 bits, or whatever
>is strong), distill this down to 7 bits and with this number to do a
>ROT[7 bit variable] (or something) on the first character of your
>message and grab that digit as your ciphertext for your first
>character. Add the first plaintext character of your message to your
>passphrase and then SHA1 /that/ and distill to get the variable for
>your ROT[7 bit variable] for the next character in your plaintext and
>continue... ANY mistake, that an attacker makes, results in
>jibberish.
>
>For each character, your cipher stream in dependant on everything that
>came before it. You'll have a unique cipher stream for every
>message/passphrase combination.
>
>It just seems too simple to be secure, though.
>
Well, one of your steps is SHA1, which I wouldn't classify
as simple. And there are some problems with it (you'd want
to add a random IV for example, so the same message doesn't encrpyt
to the same cipher text) but overall it's workable. Note that
"workable" is very different from "works as well as an AES finalist."
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Bracking RSA Encryption. Is it possible.
Date: Sat, 20 Nov 1999 14:26:51 -0600
In article <[EMAIL PROTECTED]>, Ted Kaliszewski <[EMAIL PROTECTED]> wrote:
> The security of RSA system does not depend ONLY on the size of the modulus
> used but also on the method used to construct it. Thus, a random selection
> of the factors does not guarantee "security". Moduli can readily be
constructed
> of any size that can be factored faster than I can type this message. It
> is. therefore, a misconception to use the size of the modulus as the proof
> of its security. This is not to say that safe moduli cannot be constructed.
> They can and, hopefully, such moduli are used by the system providers.
> Otherwise we are all in a deep trouble.
> Reagrds,
> Ted
Similiar comment different thread: Keys that define a level of security
may be separate from the algorithm itself.
While RSA is a algorithm, the choice of modulus is definied as part of the
key. Remember that in an ideal cipher, one criteria is that the key
defines the security. I hold open the question of whether RSA is
otherwise ideal, if it is not cryptoheresy to be cautious.
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
** 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
******************************
