Cryptography-Digest Digest #773, Volume #10 Mon, 20 Dec 99 14:13:01 EST
Contents:
Re: First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Re: Analogue encryption (Johnny Bravo)
Earn CASH for every email you receive! ([EMAIL PROTECTED])
ElGamal Opinions, Please ("David")
Re: First step in finding primes (Anton Stiglic)
Re: Q: transcendental pad crypto ("Tony T. Warnock")
Re: Q: transcendental pad crypto (Lincoln Yeoh)
Re: compression & encryption (Tim Tyler)
Re: First Bijective Arithmetic Compression (Tim Tyler)
Re: Cryptanalysis (Paul Crowley)
Re: US Patent Office: How Stupid? Look Here... (Ian Goldberg)
Re: compression & encryption (Jerry Coffin)
Re: random numbers straight out of MS BASIC (Scott Nelson)
QPK (Medical Electronics Lab)
Re: compression & encryption (Jerry Coffin)
Re: Casio's Multi Dimensional Space Rotation encryption (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: First Bijective Arithmetic Compression
Date: Mon, 20 Dec 1999 15:54:13 GMT
In article <83l6j8$61$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]>
wrote:
>Sorry David,
>You're right and I'm wrong.
>From what I can see there is no way I can gain any information from your 1-1
>compression.
>I finally understand now what you're trying to do.
Great glad to hear that sorry I don't communicate more clearly
>
>I have only noted that all files with the same header have the same
>compressed header, allowing a compressed text attack. However you have
>always stated that the compressor doesn't add to the security of encryption
>it just doesn't allow an attacker to gain any information.
Sometimes I say it improves security. But by that I mean it improves it in
the sense it it was not there and you either did not compress at all or
used some standard file adulterating compression. I guess I could call it
"nonadulterated compression" what do you think.
The whole area is wide open. Matts is the second one I know of and he
used different methods than I did. I may apply those to my conditional huffman
compression since the "finitely odd" file that is one to one is trival to make
for any number of symbols and no specail requirements on building the table
only a little common since on the ending.
>
>My apologies again.
>(An RLE version would have been easier to analyse :))
>
I have a RLE version that I have not posted if you wnat to check
it out please ask I could send you a copy to test.
I will but it up soon but would like it tested some more.
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] (Johnny Bravo)
Subject: Re: Analogue encryption
Date: Mon, 20 Dec 1999 09:54:24 GMT
On Mon, 20 Dec 1999 14:55:37 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> I guess its a politically correct way to say "I'm fucking
>smarter than you asshole". But I tend to be more direct it helps
>to read old issue of MAD magazine to find out what the pompous
>ones really mean when they write.
You get your crypto knowledge from MAD magazine? That explains
quite a bit.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED]
Subject: Earn CASH for every email you receive!
Date: среда, 01 сен 1999 12:59:38 -0600
Earn CASH for every email you receive!
http://www.sendmoreinfo.com/id/37421
Stop searching... Get email about your interests!
FREE membership... Start earning money right now, today!
Fun and Easy!
------------------------------
From: "David" <[EMAIL PROTECTED]>
Subject: ElGamal Opinions, Please
Date: Mon, 20 Dec 1999 10:28:33 -0600
Hi,
I am charged with the task of encrypting session key using a public key
algorithm.
We have opted away from RSA, since the still pending patent entails a large
cost to use. Management here is now leaning towards ElGamal, which seems to
be free to use.
Can I have your opinions as to the suitability of this idea?
TIA,
David
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: First step in finding primes
Date: Mon, 20 Dec 1999 11:32:31 -0500
Tom St Denis wrote:
> In AC he suggests dividing by primes upto 256 which would give you
> 1.12/lnx or ~79.8% of all odd composites. I was thinking wouldn't it
> be easier just to check gcd(n, x) = 1, where n = 2 * 3 * 5 ... * phi
> (256) [phi(x) is the x th prime]. The number would be huge at first,
> but after the first few itterations would get smaller. It would save
> space and probably time as well.
>
You don't care much about space, storing the first 256 primes is
nothing. I think SSLeay does it, other libraries must do it as well.
You get a significant difference in speed by doing it!
Computing gcd takes much more time, you want to try the first
primes so as to get a speed up.
Anton
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Q: transcendental pad crypto
Date: Mon, 20 Dec 1999 09:53:15 -0700
Reply-To: [EMAIL PROTECTED]
The question is not whether a number is transcendental but whether it is
computable. If the number is computable, it does not work for an crypto
key.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Q: transcendental pad crypto
Date: Mon, 20 Dec 1999 16:59:56 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 20 Dec 1999 01:19:39 -0500, "dls2" <[EMAIL PROTECTED]> wrote:
>"Also, a computer-based pseudo-random number generator
>does _not_ qualify as a true one-time pad because of its
>deterministic properties. See `pseudo-random number
>generators as key stream'." -Cryptography FAQ, 4.4.
>
>Do transcendental numbers qualify as pseudo-random, or
>as truely-random, for purposes of one-time pads?
>
Basically if you want OTP, generate good random numbers. Anything less than
random is crap for OTP. Stop wasting time with nice numbers like Pi, e,
foo, bar, etc. Spend your time figuring out how to create a good and secure
source of randomness which no one else can get access to.
If there is a slight hint of a pattern then it's not random. If some fancy
math can explain the numbers then it's not random. If some mortal entity
(INCLUDING YOU!) can predict the numbers it's not random.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: compression & encryption
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Dec 1999 16:55:49 GMT
lordcow77 <[EMAIL PROTECTED]> wrote:
: Show me a modern block cipher so throughly broken that one can use
: known-plaintext characteristics of the first two bytes of the block to
: reduce the keysearch space and I'll show you a block cipher that one
: should never use. Or better yet, give me an ACTUAL EXAMPLE of such an
: "attack" on any reasonable block cipher construction, even a badly
: broken one like FEAL-4.
Brute force against DES qualifies on both these counts, AFAICS.
The known plaintext allows the rejection of > 99.99% of the possible keys
after decrypting a single block, without even bothering to attempt
decompression.
The space you subsequently have to apply a /serious/ search to - i.e.
decrypting (possibly the entire message) and decompressing before
examining plaintext frequencies closely, is reduced to less than 0.01%
of its original size.
Note that decompressing the whole first block is a worst-case scenario.
You can optimise the decrypting program to deal with constant cyphertext,
and a constant target plaintext section - perhaps aborting the search
before the decrypt is over if it is detected that the key can be rejected
before the final round is reached.
Given that brute force DES-cracking machines exsit, these sorts of thing
are likely to massively reduce the time taken to break any individual
message.
Of course you could argue that DES is "so throughly broken" that nobody
should ever use it - but if so, perhaps this should have been argued in
1992, for example, when its approval as a US government standard was
renewed.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Few women admit their age. Few men act theirs.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Dec 1999 17:02:10 GMT
Gary <[EMAIL PROTECTED]> wrote:
: I have only noted that all files with the same header have the same
: compressed header, allowing a compressed text attack. [...]
I /think/ one of David's approaches to defending against this is to
compress once when parsing the file "forwards", and then *again* when
parsing the file "from back to front". This seems like it would be quite
effective at destroying the similarity between compressed versions of
files which shared the same header.
Preprocessing after compressing but before encrypting by applying simple
unkeyed diffusion would be an alternative approach - although perhaps one
which is more computationally expensive on serial hardware.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A good hot dog feeds the hand that bites it.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis
Date: 20 Dec 1999 08:15:37 -0000
David Hopwood <[EMAIL PROTECTED]> writes:
> > however, I have a brief primer on crypto in the first few pages.
> > I need to source everything that is not an opinion. I remember reading
> > something a few weeks ago about how cryptosystems are often created to
> > meet a purpose and you wouldn't use a difficult cryptosystem to apply
> > to a message to send info that will expire in one week.
>
> You may have read that, but you should also be aware that many practicing
> cryptographers strongly disagree with it.
Everything David Hopwood says here is true and you would be well
advised to take it to heart. However you'll be pleased to hear that
there is a sense in which you're right. There *are* tradeoffs between
security and convenience, but they don't lie in the choice of
algorithms, which (barring legal problems) should always be strong.
PGP is very much biased towards the convenience end: it's used on
ordinary PCs rather than dedicated hardware, it allows you to override
the safeguards against key spoofing attacks, and so forth. I think
these are the right decisions for PGPs intended purpose, but a
different purpose would mean different tradeoffs. If you feel obliged
to reach the conclusion you drew up in advance, you could go at it
from this angle.
hope this helps,
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Crossposted-To: talk.politics.crypto
Subject: Re: US Patent Office: How Stupid? Look Here...
Date: 20 Dec 1999 18:10:30 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
>Anthony Stephen Szopa wrote:
>>
>> US Patent Office: How Stupid? Look Here...
>
>Or look here... then you won't be surprised anymore.
>
>http://patent.womplex.ibm.com/details?&pn=US05446889__
It's time to play "stupid patent of the day". Here's an entry:
http://www.patents.ibm.com/details?&pn=US05443036__
Method of exercising a cat
A method for inducing cats to exercise consists of directing a beam of
invisible light produced by a hand-held laser apparatus onto the floor
or wall or other opaque surface in the vicinity of the cat, then moving
the laser so as to cause the bright pattern of light to move in an
irregular way fascinating to cats, and to any other animal with a chase
instinct.
(Luckily, the claim only covers "a beam of invisible light". All the
handheld lasers I've seen clearly produce _visible_ light, so they'd not
be covered.)
- Ian
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: compression & encryption
Date: Mon, 20 Dec 1999 11:38:32 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> I would have thought you should be comparing 1-1 compression with non 1-1
> compression if you're drying to draw any conclusions about its utility.
Apparently you either didn't read, or didn't understand what I was
saying because that's _exactly_ what I was comparing.
> Brute force of the whole keyspace is only what needs to be used if there
> is no other known attack on the block cypher. If you're /seriously/
> trying to read the messages, it would be useful to have some other sort
> of attack as well, to reduce the effective keyspace further.
Of course it's useful. But, if I use, say, Twofish do you have such a
thing available?
> Well, you're still comparing a poor compression scheme to the /awful/
> technique of not compressing at all.
No, I'm not doing anything of the sort.
> The keyspace reduction I mentioned won't generally translate directly
> into improved cracking speed - but depending on the sizes of the
> messages, and how much work is needed to reject keys without the
> known-plaintext, large speed improvements can be on the cards.
I'm not sure I follow exactly what you're saying here. It IS true
that if you have no idea what the plain text looks like, then it gets
pretty tough to do a cipher-text-only attack. At least from what I've
seen, this situation is so rare that it hardly merits consideration
for normal use.
> The message need not be text. It could be fairly short. There may be
> only a few bits of plaintext known. If this is the case, a 2-byte header
> could make the difference between a near certain idintification of the
> file, and a hopless problem, with large numbers of possible solutions.
Even non-text messages typically have fairly specific, detectable
structures -- in fact, in many cases they're far MORE structured than
text, so detecting what's reasonable or not can be even easier. I
used text purely because it happens to be a format that's very common,
with which we're all familiar, so I don't have to write a small book
about the criteria I'm using to define "reasonable" output.
Ultimately, it seems to come down to this: you seem to want to claim
that there is SOME set of circumstances in which this will make a
difference. If you define the parameters narrowly enough, there's
little question that this is true. Unfortunately, in doing so, you've
defined the parameters SO narrowly that virtually nobody has any real
reason to care about them anymore, and to a large extent they're more
or less self-defeating in any case. For example, if a message starts
out so short that it's difficult to collect meaningful statistics on
it, then the compression isn't making much difference to anything:
compression is useful to start with specifically because it makes
collecting statistics more difficult.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: random numbers straight out of MS BASIC
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Dec 1999 18:37:22 GMT
On Sun, 19 Dec 1999 Raddatz Peter <[EMAIL PROTECTED]> wrote:
>Scott Nelson wrote:
>>
>> On Sat, 18 Dec 1999 Raddatz Peter <[EMAIL PROTECTED]> wrote:
>>
>> >I keep reading about how weak and predictable the built in RNG from MS
>> >is, so I did some testing. The MS RNG has a repeat series of approx.
>> >256^3 or 16777215.
>>
>> Mine doesn't. Either there's a flaw in your testing,
>> in my testing or we have different versions.
>> Which MS RNG version are you talking about?
>>
>> >If I create 10 sboxes with 1000 rnd numbers betw. 0 and 256 based on 2,
>> >rather large, seeds (> 111111111111111 & < 999999999999999)
>>
>> That's not reasonable as described.
>>
>> Could you describe that step in a little more detail?
>> How are you using those large seeds?
>> Where are the random numbers coming from?
>> How does the MS RNG fit into all this?
>>
>> Scott Nelson <[EMAIL PROTECTED]>
>
>I'm petty sure that MS does not use the whole 15 digits as its seed, I'm
>pretty sure that there's a MOD in there somewhere. All I'm trying to
>achieve is to have the seed a little larger than TIMER. The point that
>I'm trying to explore is... the numbers generated are betw. 0 and 255
>inclusive the only thing that is "random" is the order in which they
>occurr. 201 15 39 118... or 117 28 93 247 or whatever, it is the order
>of 10, 100 or a 1000 "randomly" arranged numbers within a certain range
>that is of importance here. If the array that holds these numbers is
>only 256 cells and holds 256 values and every value can only occur once
>then the possibilities are extremely limited. In a larger array, though,
>where any number could occur numerous times in any given location poses
>a slightly higher challenge. The large seed I use simply determines the
>order of the numbers not the size.
>I fail to see where numbers within the range of 0 - 255 arranged
>"randomly" by the MS algo are inferior to those 0 - 255 arranged by a
>different algo.
The main difference is that guessing the entire array is
only as hard as guessing what number was used as the seed.
If you're going to be publishing the array, then that's
really not much of an issue. If you expect it to be secret,
then it's a big problem.
Note that the seed can't really be larger than the number
of states in the generator. If the generator has a period
of 2^24-1, then there can only be 2^24-1 _unique_ seeds.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: QPK
Date: Mon, 20 Dec 1999 12:34:08 -0600
> 6. Seeking interest in Quasi-Public Keying
>
> (Totally unrelated to SRP)
> I would like to get information, ideas,
> interest in QPK which roughly means:
>
> An asymmetric encryption key
> may have more than one possible
> decryption keys that decrypt
> any ciphertext to different
> versions of corresponding
> plaintext.
>
> Important: asymmetric can be based on
> one of those 'hard' problems.
>
> Does anybody know if anybody is doing,
> has done something in that direction? Even
> contemplating on similar concepts? I am kind
> of desparate in need of ideas and enlightment.
>
> I have a version that I conjecture to be
> working. However, it seems very, very wasteful.
> Huge key(s), many-rounds protocol, etc.
> Any information, a pointer for example, will
> be greatly appreciated.
There are 2 ways to do something like this. One is just
straight forward "probablistic encryption", which gives
you multiple possible outputs. They don't necessarily mean
anything, only 1 will be the useful answer. Another idea
is something like a "k out of n scheme", which uses multiple
dimensions to allow many key holders to have some information
about a key, but it takes at least k of them to figure out
all the equations to find the key. If you have k-1, you can
do a search over a vastly reduced key space, which is kind
of like probalistic encryption.
Should be a few places on the net that have info.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: compression & encryption
Date: Mon, 20 Dec 1999 11:42:38 -0700
In article <83jrid$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Jerry Coffin) wrote:
>
> >my expectation would be that in many cases we'll be able
> >to accept or reject a trial decryption within the first
> >few of bytes in either case. Yes, you're going to
> >decrypt a few extra blocks without known plaintext,
> >but you need VERY low criteria for what looks reasonable
> >before you expect it to happen even one percent of the time.
>
> #$^8`L&2c$@(Q&>+ Is there a way one could exploit this by sticking
> random characters somewhere in the plaintext prior to encryption?
> In other words, does the trial decryption always try to decrypt
> the same place in the plaintext? Maybe at one end?
Sure -- unfortunately, the general notion of things is that the
attacker knows the complete algorithm you're using, so if it's added
in a deterministic fashion, the attacker knows how to ignore it.
The only way this really works is if the locations (and possibly
values) used depend on the key. In that case you've got something
that looks awfully similar to chaffing and winnowing -- IOW, your idea
may not be particularly original, but it can almost certainly be
effective and useful.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: Mon, 20 Dec 1999 11:56:28 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Hideo Shimizu wrote:
>
> > CASIO don't disclose any detail. Only outline.
>
> I really can not understand why they would disclose
> a part of the algorithm but not the details.
> It just does not make any sense.
Sure it does. Your problem is that you're interested in security
while they're interested in sales.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
