Cryptography-Digest Digest #788, Volume #10 Fri, 24 Dec 99 01:13:01 EST
Contents:
Re: "Variable size" hash algorithm? (Dan Day)
Re: "Variable size" hash algorithm? (Dan Day)
Re: "Variable size" hash algorithm? (Dan Day)
Re: More idiot "security problems" ("Trevor Jackson, III")
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Greg)
Re: need help with randomly generated numbers ("John E. Gwyn")
Re: If you're in Australia, the government has the ability to modify ("John E.
Gwyn")
Are PGP primes truly verifiable? (Greg)
Re: Classic Cryptanalysis Tools Needed ("Leslie Wagner")
Re: More idiot "security problems" (Bruce Schneier)
Re: compression & encryption (Kenneth Almquist)
Is it a hash or a cipher? (wtshaw)
Re: "Variable size" hash algorithm? (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: "Variable size" hash algorithm?
Date: Thu, 23 Dec 1999 23:17:14 GMT
On Wed, 22 Dec 1999 22:55:42 -0000, "Gary" <[EMAIL PROTECTED]> wrote:
>Alternatively you can use a standard cryptographic algorithm such as XTEA
>block as a hash function by using the data to be hashed as a key (iterating
>for long keys) on a constant value set to the number of 64 bit blocks you
>want. (XTEA block is relatively unusual in that it treats all fo the data to
>be encrypted as a block).
Due to some terms that I find ambiguous in the above paragraph, I
don't fully understand the process you're describing above. Could
you please spell it out in a little more detail?
I'm especially unclear on "iterating for long keys", and "a constant
value set to the number of 64 bit blocks".
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: "Variable size" hash algorithm?
Date: Thu, 23 Dec 1999 23:49:27 GMT
On Thu, 23 Dec 1999 00:32:55 +0100, Pelle Evensen <[EMAIL PROTECTED]> wrote:
>[snip]
>> 2) Reduce a large volume of data to a smaller (but
>> still large) volume of "random" data (again, no
>> larger than the amount of entropy in the original
>> "seed" data), to be used as a one-time-pad.
>
>Why would you want a "large" volume of data as hash?
Because I'm not actually using it "as a hash". I'm just using
a hash-like algorithm to produce bits that I'll use for purposes
other than as a hash value.
In this case, think of "hash" not so much as "a hash value",
but more in terms of "corned beef hash" -- that is, something
that has been chopped and stirred.
In the above example, I just want to "scramble" the data in
order to turn possibly recognizable or reconstructible bits
into something that's unrecognizable, and that can then be used
as a pseudo-random batch of bits.
For example, lacking a source of a large number of truly random,
I might decide to take an online copy of "Oliver Twist", append
my hard disk's current FAT, followed by 32 bits that I
generated by coin-flip, and then scramble them down to
1/100th of their original size, which ought to be much less
than the number of bits of entropy involved. The result
will be a decent batch of "random" bits.
And yes, I know that in theory this is much easier for
an adversary to reproduce than N bits of truly random bits,
but in practice it's going to be pretty damned hard to
recreate whatever bizarre combination of "source" data I
decided to pull out of a hat and throw into the "mixing bowl".
> With an algorithm
>producing a 160 bit hash it's 50% that you'll get a collision after 2^80
>(~2 * 10^24) messages. This is an awful lot. :-)
But I'm not hashing messages, I'm using hashing, in its
general sense, to scramble "source" bits into a bit stream that
is a reasonable facsimile of random bits.
Think of it this way -- I want to make a pseudo-random number generator
that works by "seeding" it with a really huge seed, and that then
produces all output in "one" step by doing a "really huge hash"
on the input.
>> 3) "Stir" a batch of random bits, to further randomize
>> it and/or obscure the source material.
>
>You can do this with a function with a "short" blocklength, 128 bits.
>Keep a pool, keep it separate from the output of the function.
>
>See
>http://www.counterpane.com/yarrow-notes.html
>http://www.counterpane.com/pseudorandom_number.html
I've glanced over those documents, and don't immediately see where
it helps to explain your comment. What do you mean by "keep a pool",
and "keep it separate from the output"?
>> Is there such an animal? Or do most cryptographically
>> useful hash algorithms generally produce a fixed-size output,
>> without an option to specify the desired output hash size?
>
>Any "pure" one-way functions I know of produce a "fixed size" output, in the
>sense "up to n bits of data", where n is well defined. You *can* of course
>combine outputs from one or several functions, chain or mix as much as you
>like and thereby end up with a hash of arbitrary length, the question is if
>you or anyone else will know what the actual strength of what you've
>created is.
That's sort of why I wanted to avoid chaining and/or combining in the
first place -- that can indeed end up in a "mathematical rut" which
makes the results more interdependent than it would first appear.
I was hoping that there was already some sort of cryptographically
"safe" hash algorithm that could be extended to "really big hash
values", which would presumably avoid that pitfall.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: "Variable size" hash algorithm?
Date: Fri, 24 Dec 1999 00:04:52 GMT
On 22 Dec 1999 19:59:18 -0800, [EMAIL PROTECTED] (Gregory G Rose) wrote:
>I believe "HAVAL" is your answer. It's a variable
>length hash algorithm from well-respected authors
>(Pieprzyk, Seberry, ...). Published in one of the
>Springer-Verlag journals some years ago.
Something tells me that my local library won't
carry the "Springer-Verlag journals"...
A quick online search for it reveals some bibliographic
references, and some mostly unannotated source code...
However, the source I found seems to imply that the
output hash size can only be one of the following:
128, 160, 192, 224 or 256 bytes. I'll have to dig
deeper to see whether that can actually be generalized
to larger values -- perhaps it's only a limitation of
the memory available in the implementation I found.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
Date: Thu, 23 Dec 1999 20:17:27 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: More idiot "security problems"
lordcow77 wrote:
> In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
> > > You could just shuffle the order of the items and check if
> > they are in
> > > order. If not shuffle again.
> > I suppose this would be worse than O(N!). More like O(2^(N-1)).
> > Let's see, if we use a universal compression mechanism on the
> > elements does it raise the work
> > factor to O(2^N) ?
>
> Isn't O(n!) > O(2^n)? I though that factorials grew faster as n become
> arbitrarily large than any exponential function of n?
I think you are right. Brain fade strikes again.
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Fri, 24 Dec 1999 03:10:57 GMT
> In article <[EMAIL PROTECTED]>,
> "fuck echelon" <[EMAIL PROTECTED]> wrote:
>
> Love the name. You had celebrity parents too,huh?
>
> But seriously, I agree that the main problem would be
> that somebody (probably _not_ the police, actually)
> would break in and covertly install a bug or alter the
> software in the computer.
>
> I think the best that can be done is to make it
> impossible for them to do it _covertly_.
> And there may be ways to do this in software,
> or at least I suspect that there are,
> but apparently anyone who knows anything
> is not talking.
> At least not in this group.
>
> ZZ
>
> >
> > But neither are likely your main problem. If you've done something
to
> > attract the attention of the local police, they'll use the easier
> methods of
> > either breaking into your home covertly, or through use of a warrant
> (or
> > whatever the legal process is in your country).
> >
Why does anyone think that a warrant is needed in America
any more? FBI agents walked into a home in central CA
looking for evidence, no warrant, no request to enter,
just brushed the owner aside- looking for evidence of two
militia men's attempt to blow up two huge gas tanks.
So the man who was brushed aside (yes, they just walked
in right in front of him) decided he should leave that
militia after the FBI visit.
Now, about modifying an OS on a computer- why would any
one need to enter your home and break apart your PC when
Microsoft has done so much to help NSA up load anything
they want to over the internet? Did you think Bill got
to become the richest man in the world because he sold
software?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: need help with randomly generated numbers
Date: Thu, 23 Dec 1999 21:41:25 -0600
[EMAIL PROTECTED] wrote:
> lets imagine i have about a hundred valid 14-digit numbers out of
> maybe 1-3 million valid ones. how can I find the algorithm which
> was used to generate these numbers and extrapolate new valid ones?
As stated, it's an insoluble problem. (For example, the numbers
might be taken from a hard-coded table.) A better question might
be, what is the simplest algorithm that will generate the observed
sequence.
> is there any program to calculate the relationship between randomly
> generated numbers?
Of course not; there is no relationship (that's what "randomly
generated" is usually taken to mean).
- Douglas ( not John)
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify
Date: Thu, 23 Dec 1999 21:51:33 -0600
Greg wrote:
> Why does anyone think that a warrant is needed in America
> any more? FBI agents walked into a home in central CA
> looking for evidence, no warrant, no request to enter,
> just brushed the owner aside- looking for evidence ...
If there weren't exigent circumstances (probable cause for
immediate public danger), the aggrieved party should have
initiated legal action (conspiracy to violate civil rights).
Despite what you seem to believe, most courts, district
attorneys, and law enforcement agencies know the rules and
try to follow them.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto;
Subject: Are PGP primes truly verifiable?
Date: Fri, 24 Dec 1999 03:45:09 GMT
Since PGP primes are getting to be very large now (to keep
up with demand for strength against newer computers), it
seems to me that they are becoming more impossible to
verify as true primes.
Is this a reasonable assumption?
With ECC, a private key is simply an integer (any value will do)
and the public key is always a valid result of a point multiply.
To be specific, ECC keys are all valid. Yet, PGP and other IFC
keys are getting to the point where verifying their validity
of strength is impossible.
Any comments?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Leslie Wagner" <[EMAIL PROTECTED]>
Subject: Re: Classic Cryptanalysis Tools Needed
Date: Thu, 23 Dec 1999 23:14:01 -0500
Unfortunately after contacting ATRA, the utility is out-of-stock and they
suggested
that it was requested to be pulled from distribution by the Intelligence
arm of the
ACA. Apparently they go to extreme lengths to ensure that knowledge of
these tools stay only within the walls of this shadowy organization.
Jim - stop following me around shilling for the cryptos. Hounding me day and
night,
Everywhere I turn, calling at 2am, reciting eight letter pattern tables,
sending cutout
magazine letters pasted onMcDonald's place mats quoting from Hitt and
Friedman,
rambling on and on about mysterious organizations where no one is allowed to
use
their real name.
....I can't stand it any more..............
... I'll join, I'll join.
Jim Gillogly <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> John Savard wrote:
> > Boaz Lopez <[EMAIL PROTECTED]> wrote, in part:
> > >Leslie Wagner wrote:
> > >> Does anyone have any crib dragging and shotgun hill climbing
> > >> routines or programs thay can share?
> >
> > >Yes, there is a click and drag crib spreadsheet available from
> > >ATRA Corp. The multidimensional sorting utility is automatic.
> > >The so called "shotgun hill climbing" is implemented using
> > >an expandable disk-cache scheme, with unlimited volume. Based on
> > >the Koligranikova-Samolian Recursion, the hill-climbing is
> > >the matrix expansion while the shotgun section depletes the
> > >candidate list. It was $129 when I bought by Crypto-Pak for
> > >Windows 98.
>
> Gee, is it April already?
>
> > I saw a recent reference in another thread to the power of the
> > "shotgun hill-climbing" technique. Web sites describing it?
>
> Not in detail, but for the basic idea see:
> http://www.pbs.org/wgbh/nova/decoding/rupp.html
> which has a pointer to the issue of The Cryptogram which describes
> it in detail (Nov-Dec 1995).
> --
> Jim Gillogly
> 1 Afteryule S.R. 2000, 22:01
> 12.19.6.14.11, 13 Chuen 19 Mac, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: More idiot "security problems"
Date: Fri, 24 Dec 1999 04:48:33 GMT
On 17 Dec 1999 09:55:08 GMT, [EMAIL PROTECTED] (Xcott Craver)
wrote:
>Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>>
>>There is no reason to expect crypto to be better than average in algorithm
>>research. There are lots of reasons to expect crypto to be worse than
>>average. Chief among these is the fact that the author is unable to tell,
>>without great effort, when he has failed.
>
>>But encryption is almost the exact opposite of sort(). The removal of order
>>rather then the imposition thereof. So the average coder can't
>>tell a good output from a bad one. Even an expert cryptologist requires
>>an effort to distinguish the really bad from the merely fatally flawed.
>>
>>The effect of these conditions is so predictable it ought to have a name like
>>"<Someone>'s Law of Cryptology"
>
> Bruce Schneier and Counterpane have been known to assert, in
> talks and white papers, that good crypto/security cannot be
> distinguished from bad crypto/security. I've always considered
> this "Schneier's first law."
A corollary is that: "Anyone can create an encryption algorithm that
he himself cannot break."
> His second law being a remark he made at HOPE-II, which, in context,
> referred to the tendency of people to simply disable annoying or
> restrictive security measures: "The user will pick dancing pigs
> over security every time."
Thanks, but that second quote is originally from Butler Lampson. I
can't take credit for it.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: compression & encryption
Date: 24 Dec 1999 05:28:37 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <83ofas$omq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kenneth
>Almquist) wrote:
>> So in most applications an attacker can get sufficient information that
>> additional information provided by a compression algorithm will not make
>> an appreciable difference. The solution is to use an encryption algorithm
>> which can resist a known plaintext attack.
> Sure one should try to use secure methods which resist a known plan
> text attack. But there are newer plaintext attacks everyday and many
> that are not published in the open literature. How do you protect
> against them. You can't.
You can encrypt twice, using two different algorithms. This will
protect you if one of the algorithms is broken. It may even protect
you if both algorithms are broken, because it does not allow an
attacker to apply a known plaintext attack to either algorithm.
Compressing using a nonbijective algorithm and then encrypting twice
may be faster than compressing using a bijective algorithm and then
compressing once. That is because some of the compression algorithms
which provide the best combination of speed and compression ratio
(such as the one used by gzip) are not bijective.
I believe that except in special circumstances, it is a mistake to
assume that an opponent will not be able to mount a known plaintext
attack. For this reason, I believe that the apparent improvement
in security offered by bijective compression is an illusion. If
your encryption is strong enough to resist a known plaintext attack,
then it doesn't matter if your compression algorithm is bijective or
not. If your encryption algorithm is vulnerable to a known plaintext
attack, then the chances are that a determined attacker will obtain
a known plaintext an break your cipher, so it is not likely to matter
whether you use bijective encryption. Sure, it's *possible* for
bijective compression to stop an attack on a cryptosystem, just
as it's possible that prefixing the encrypted text with an obscene
message will stop an attacker with delicate sensibilities. My point
is that "possible" is not the same as "probable." Designers of
cryptographic systems do better to concentrate their efforts on
other approaches.
Kenneth Almquist
P.S. Now that I've posted this, is it too late for me to apply
for a patent on the use of obscenity as a cryptographic
technique? :-)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Is it a hash or a cipher?
Date: Fri, 24 Dec 1999 00:25:10 -0600
I had a lengthy interresting discussion today about the tridigital
*cipher*. The working key of the beast is a deranged alphabet grouped
into 8 clumps of 3 characters and 1 group of 2 characters. These 9 groups
are assigned each a digit from 0 to 9. The unassigned digit is used to
separate words.
I'll give the example key, if I copy it correctly, without the weird means
it was made:
0:AET 1:LMZ 2:NJW 3:GHU 4:YP 5:OIV 6:DBQ 7:RCS 8: FKX 9:(separator)
*Encryption* means finding each letter of the message and using a digit to
replace it. The problem that the results can be ambigious. As English is
redundant in structure, the substitutions are often apparent. Since 26
characters and space are represented by 10 digits, lots of the randomness
is eaten up. The system is therefore not deterministic in nature, rather
depending ion context and imagination at times. A given series of digits
might be convertable into several real, but different words.
It rather meets the definition of a hash, and a pretty poor one at that.
In my way of refering to these things, encryption here is deductive and
decryption is inductive, making the tridigital rather backwards of better
ciphers were encryption is inductive and decryption is deductive.
The tridigital is an awkward cousin to say the least, more a puzzle than a
true cipher. The classic keystructure has the problem that one of the
keywords may also be ambigious. As aids to the memory, tridigital
*ciphertext* may be just the sort of thing you want, pretty wishy washy to
be taken seriously.
--
Only a little over a year left to go in this centrury....
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: "Variable size" hash algorithm?
Date: Fri, 24 Dec 1999 00:25:26 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Dan Day) wrote:
..
> Because I'm not actually using it "as a hash". I'm just using
> a hash-like algorithm to produce bits that I'll use for purposes
> other than as a hash value.
>
> In this case, think of "hash" not so much as "a hash value",
> but more in terms of "corned beef hash" -- that is, something
> that has been chopped and stirred.
There is nothing wrong with this idea, but a hash is usually a distilled
product, often less than what you started with.
>
> In the above example, I just want to "scramble" the data in
> order to turn possibly recognizable or reconstructible bits
> into something that's unrecognizable, and that can then be used
> as a pseudo-random batch of bits.
>
....
> But I'm not hashing messages, I'm using hashing, in its
> general sense, to scramble "source" bits into a bit stream that
> is a reasonable facsimile of random bits.
>
> Think of it this way -- I want to make a pseudo-random number generator
> that works by "seeding" it with a really huge seed, and that then
> produces all output in "one" step by doing a "really huge hash"
> on the input.
So, for little effort or lots, depending on the situation, you want a
runtime key of some size. OK, but, remember if asked that the security
depends on the actual input used.
I have done lots of this sort of thing, wanting permutations of one sort
or another instead of just bits, but the same reasoning should apply. The
upper limit on actual randomness would be reflected in the full meal deal,
ground up potatoes and all, while substance is still there, symbolically
in the bits of meat throughout.
The value is that any input less than the maximum allowed is usable. It is
a common notion that short, bad, trivial keys be locked out, but for test
purposes or marginal security needs, they are most useful.
If an immense runtime key can be generated in a myrid of ways involving
different strengths, the studies of what strength means with that
algorithm are practical, if you are into that sort of thing. As it turns
out however, cracking the algorithm could mean more cracking the key
generation system, which ccould be hard to deduce, even if the encryption
algorithm is known.
Wanting to set algorithm strength by actual runtime keylength such as in
AES are shortsighted, as the actual strength can be in key generation
instead. What we get is less than a scaled approach, but sometimes
different algorithms with the same name that are tweaked to pass through a
keysize hoop. It is better to dream up something that is fearfully strong
in the first place if strength is the real goal.
So, you are ahead of most of the big names in where you seem to be
headed, at least you are not afraid to tread off the beaten path.
....
>
> ..... I wanted to avoid chaining and/or combining in the
> first place -- that can indeed end up in a "mathematical rut" which
> makes the results more interdependent than it would first appear.
> I was hoping that there was already some sort of cryptographically
> "safe" hash algorithm that could be extended to "really big hash
> values", which would presumably avoid that pitfall.
>
One option is a multiseeded approach if done appropriately for your
encryption algorithm. Another is to be able to process really large text
files in methods I have explored and talked about some time ago, that do
effectively allow tremendous sized hashes directly. You can make any
sized runtime key you want from whatever you have to input.
I assure you that you can find your own custom means; don't be afraid to
do it or keep asking. The pat answer is that you are apt to get will
discourage trying, as some key people really think too small to get
anything of the sort actually done.
--
Only a little over a year left to go in this centrury....
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
------------------------------
** 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
******************************
