Cryptography-Digest Digest #229, Volume #10 Mon, 13 Sep 99 18:13:03 EDT
Contents:
Re: Mystery inc. (Beale cyphers) (Jim Gillogly)
Re: Sources of randomness (Medical Electronics Lab)
Re: Make a point on KRYPTOS ("Douglas A. Gwyn")
Re: ECC questions... (Medical Electronics Lab)
Re: Desperatly seeking throw-away password verification (Anton Stiglic)
Re: 13 reasons to say 'no' to public key cryptography (Thierry Moreau)
40-bit ssl (Fiji)
Re: Ritter's paper (John Savard)
Re: primes in dh (Tom St Denis)
Re: Mystery inc. (Beale cyphers) ("Douglas A. Gwyn")
Re: primes in dh ("Michael Scott")
Re: Looking for Completely-Free Strong Algorithms (Volker Hetzer)
Performance benchmarks (Jim Goodman)
Re: Mystery inc. (Beale cyphers) (Curt Welch)
Re: primes in dh (Tom St Denis)
Re: Looking for Completely-Free Strong Algorithms ("Joseph Ashwood")
Re: Mystery inc. (Beale cyphers) (Curt Welch)
Re: Random and pseudo-random numbers (Eric Lee Green)
First draft of Ocotillo now online (Eric Lee Green)
Re: H.235 Keys from Passwords algorithm (John Savard)
Re: Sources of randomness ([EMAIL PROTECTED])
Re: H.235 Keys from Passwords algorithm (Paul Rubin)
Re: Mystery inc. (Beale cyphers) (Curt Welch)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Mon, 13 Sep 1999 17:10:07 +0000
John Savard wrote:
>
> [EMAIL PROTECTED] (Curt Welch) wrote, in part:
>
> >As Jim already pointed out, you can't really prove a cypher is a hoax just
> >by analyzing the numbers. All good cyphers will look like ramdom numbers.
> >Either you can decode it, or you can't. If you say "It's a hoax", what
> >you are really saying is "I give up, it's too hard for me to figure out."
What I said was, the Beale ciphers are interesting because you <usually>
can't prove a cipher is a hoax just by analyzing the ciphertext. The fact
that long coherent and monotonic but intelligence-free strings can be
decrypted from B1 using the very same key used to decrypt B2 puts the
Beale ciphers into a different category: one where you <can> offer
convincing evidence that it's a hoax by analyzing the numbers.
> There were two papers; one was decoded, and implied the second one was
> coded in the same general system. So one can prove that this was not
> the case, and additionally, as the papers were encoded at a given date
> in the past, one can eliminate from consideration such methods as DES
> encryption.
Carl Hammer wrote a paper discussing the statistical properties of B1 and
B2, and concluded that they were enciphered in the same general system.
sha99y0000's notes about the lack of "duplicates" in B1 and B3 compared
to B2 are also interesting and bear further investigation.
--
Jim Gillogly
Mersday, 22 Halimath S.R. 1999, 17:02
12.19.6.9.10, 3 Oc 18 Mol, First Lord of Night
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: Mon, 13 Sep 1999 12:31:11 -0500
Mok-Kong Shen wrote:
> If an implementation is hard, it's a one time matter and presumably
> doesn't cost too much. What I meant is that there are abundant
> potential sources of randomness than from radioactive decay, etc. etc.
> To take my (maybe a bit fancy) example, I could well imagine
> that when I work on PC I have something attached to my arm and that
> feeds the pulse recording to the computer where the random bits are
> obtained by a subroutine for use. I personally would prefer such a
> device than, say, loading random bits from some sites which have
> collected these from radioactive decay. Of course, maus movements,
> etc. can also deliver random bits. I suppose, however, that it is
> useful to think about diverse different possibilities and that
> something that is autonomous could in the present context be
> psychologically more satisfying than what is under certain conscious
> control of the mind.
If you know the characteristics of the signal, you can subtract off
the "known" components and leave the "random" one. This amounts to
having an accurate model of your input system. If it's not accurate,
too much "signal" will get thru your processing.
For a description of how to find "randomness" in a signal, see
http://www.terracom.net/~eresrch/detecting_random.ps
The source is radiation, but the math will work on any signal.
Radiation is more fun for me, that's all :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Make a point on KRYPTOS
Date: Mon, 13 Sep 1999 17:01:52 GMT
collomb wrote:
> I wish a real discussion based on solid arguments.
No you don't, because we had those already.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: ECC questions...
Date: Mon, 13 Sep 1999 12:39:56 -0500
Teh Yong Wei wrote:
>
> Currently, I am writing a program to simulate the ECC encryption. There
> is some doubts about it:
>
> 1)The receiver will generate the secret key, k that is a random integer
> number. What is the range?
The web page describes math over GF(p), so k should be less than p.
It doesn't have to be, but you'll be doing a mod p on k anyway, so
you should use k<p.
> 2) When doing encryption, the sender will generate another secret key, r
> that is a random integer number and used to encrypt a message. What is
> the range?
Same thing, less than p. You probably want to pick a hamming weight
of both r and k in the range of log(p)/2, but that's not strictly
necessary.
>
> For further reference, you can refer to this page:
> http://ge.ge.kochi-ct.ac.jp/%7Etakagi/crypto/eccs.html
My poor old browser had trouble with some of the columns, but the
last one came out ok.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Desperatly seeking throw-away password verification
Date: Mon, 13 Sep 1999 13:40:29 -0400
>
There is something called a One-Time-Password, I don't know if this
is what you need. See RFC 2289.
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 13 reasons to say 'no' to public key cryptography
Date: Mon, 13 Sep 1999 12:37:38 -0400
Paul Koning wrote, in part:
>
> Would you care to offer alternative approaches?
>
> With supporting reasoning as to why they are better in large
> scale real world settings?
>
Yes, this is the "SAKEM implied security model" as a general approach
and the "SAKEM procedure" itself for initialization (SAKEM stands for
Secret Authentication Key Establishment Method) SAKEM is well suited to
large scale deployment.
See http://www.connotech.com/sakem.htm
- Thierry
------------------------------
From: Fiji <[EMAIL PROTECTED]>
Subject: 40-bit ssl
Date: Mon, 13 Sep 1999 13:13:01 -0400
I know that it is weak but the questions is what is the fastest that it
has been cracked? Searching on the web I find instances of it being broken
in about a week but that was back in 95. What is the fastest that it could
be brute forced with todays computing power...i.e. linux clusters, etc.
-Fiji
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Ritter's paper
Date: Mon, 13 Sep 1999 17:21:25 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>There appears to be a .PDF copy of the article on-line; see:
> http://computer.org/computer/co1999/r8toc.htm
Appearances can be decieving. The PDF copy is only available to
service subscribers. But COMPUTER is widely available at libraries.
I've finally figured out a halfway-plausible rationale for the East
German cipher machine that uses a 12-level tape to XOR with a
"12-level form" of 5-level characters,
http://www.ecn.ab.ca/~jsavard/ro020404.htm
And I've extended my page on shift-register-based stream ciphers
noting how the timing of a device based on such principles might
interact with the usual method of serial transmission of 5-level
characters:
http://www.ecn.ab.ca/~jsavard/co041101.htm
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: primes in dh
Date: Mon, 13 Sep 1999 18:10:15 GMT
Forget what I said, I will use the modulus you gave me, and I may choose to
use a different one later... (not in peekboo though). I will generate a g
value later today using lip
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Mon, 13 Sep 1999 17:08:50 GMT
Curt Welch wrote:
> The alphabetic strings that appear when #1 is decoded with the DOI
> is far from random so that's a _big_ clue to the encoding.
Unfortunately, the better those clues, the *more* likely that it is
all a hoax. The reason is, this *type* of cipher does *not* produce
long alphabetic runs when the wrong key is used nor when the right
key is incorrectly applied; it produces garbage that has a
distribution approximately the same as initial letters of words in
the language of the key document.
There are *other* types of encipherment where a wrong guess in the
cryptanalysis can produce causal clues anyway, but that's not what
has been going on in this case. Either the alphabetic strings are
purely accidental or they are the actual plaintext.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: primes in dh
Date: Mon, 13 Sep 1999 19:37:39 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:7rj7r2$r7t$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Bob Deblier <[EMAIL PROTECTED]> wrote:
> > Here's a (probable) 2048 safe prime. Both this number and (number - 1) /
2 are
> > probable primes, which simplifies the finding of a generator.
> >
> >
b478a3fa33b1eac4ac8838ff8118999aacd9ea174143f0a9e06b68004836c63598897ae0e873
8764659b3902926258df809a5453b50d57438a3c765b1ea9e64089606376fd6da94a43686d8e
3fe574eb5b77d55d1b84a9de2dd96042938036837082f753f42296696a808e5df937a48c3b5f
fe5c509752227b14c17f612d9950370337d62dcad7031071a3710b5ed7c59e061eb6540a8b10
8318f0334a6bd6780da6ebdc4988b658a42d8a57548019811f41af62aa463562c3cdd3db018a
91fb956d6663ddea34c427935177611d3eaa883f1665eb036e3423dbfea9bafe81513dde34f3
056d6014b081404ca205ba2858434d55b91764a2703e46578f9e254f
> ......
> >
> > > Can I iterate this to find one or is there a more efficient method? I
just
> need a single generator. So I iterate this from G = 2 to n can I expect
to
> find a generator soon?
> (all new to me :) )
Simpler than that. Use G=3 or G=4. Either will generate the prime order
subgroup, of order (p-1)/2.
--
Mike Scott
=========================================
Fastest is best. MIRACL multiprecision C/C++ library for big number
cryptography
ftp://ftp.compapp.dcu.ie/pub/crypto/miracl.zip
>
> Tom
> --
> damn windows... new PGP key!!!
> http://people.goplay.com/tomstdenis/key.pgp
> (this time I have a backup of the secret key)
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Fri, 10 Sep 1999 11:11:22 +0200
Volker Hetzer wrote:
> If you want to encrypt a channel, you might want to look for a good stream
> cipher too. What about RC4?
Sorry, I forgot that RC4 is owned by RSA.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: Jim Goodman <[EMAIL PROTECTED]>
Subject: Performance benchmarks
Date: Mon, 13 Sep 1999 15:58:01 -0400
Hello,
I was wondering if anyone knew of a collection of performance
numbers on the web (or in papers) for various companies' public
key implementations (rather than having to surf each of their web
pages myself). I'm interested in all forms (IF, DL, and ECC).
I'd really appreciate it if someone could give me a pointer.
Thanks!
Jim
------------------------------
Subject: Re: Mystery inc. (Beale cyphers)
From: [EMAIL PROTECTED] (Curt Welch)
Date: 13 Sep 1999 20:22:30 GMT
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] (Curt Welch) wrote, in part:
>
> >As Jim already pointed out, you can't really prove a cypher is a hoax
> >just by analyzing the numbers. All good cyphers will look like ramdom
> >numbers. Either you can decode it, or you can't. If you say "It's a
> >hoax", what you are really saying is "I give up, it's too hard for me to
> >figure out."
>
> There were two papers;
There are three.
> one was decoded,
#2 was decoded, #1 and #3 were not.
> and implied the second one was
> coded in the same general system.
No. According to the story, information about how to decode the papers
should have been sent to the person holding the papers (in the event
that the owners of the treasure never returned). This "key" never showed
up (and the owners never returned either). Nothing was said about what
these papers were for, let alone how they might be encoded or if they all
were to be decoded with the same key, or different keys. All that was
know was that the information for decoding the papers was to be sent.
I think it was the person holding the papers that started trying to
decode their meaning. He figured out (after a lot of work) that the DOI
was the key to decoding the #2 document. Because the #1 paper and the #3
paper are very similar (lists of numbers that "look" at first examination
much like the #2 document) an obvious guess is that the "key"
to decoding them would be to use some other document -- or some other
way of creating numbers from the same document. Many people have tried
many different documents and have gotten nowhere (or at least never
published their work if they did).
The #2 document (when decoded), tells of the treasure, and says that
the #1 document describes it's location and the #3 document describes
the people envolved so their descendants could claim the treasure.
Here's the decoded #2 document (you have to add the spaces):
ihavedepositedinthecountyofbedfordaboutfourmilesfrombufordsinane_cavationor
vaultsi_feetbelowthesurfaceofthegroundthefollowingarticlesbelongingjointlyt
othepartieswhosenamesaregiveninnumberthreeherewiththefirstdepositconsistcdo
ftenhundredandfourteenpoundsofgoldandthirtyeighthundredandtwelvepoundsofsil
verdepositednoveighteennineteenthesecondwasmadedeceighteentwentyoneandconsi
stedofnineteenhundredandsevenpoundsofgoldandtwelvehundredandeightyeightofsi
lveralsojewelsobtainedinstlouisine_changetosavetransportationandvaluedatthi
rteenrhousanddollarstheaboveissecurelypackedinironpotswithironcoversthevaul
tisroughlylinedwithstoneandthevesselsrestonsolidstoneandarecoveredwithother
spapernumberonedescribesthce_actlocalityofthevarltsothatnodifficultywillbeh
adinfindingit
So nothing we know about the documents tells us how they were encoded.
The alphabetic strings in the #1 document when decoded like the #2 document
is very strong evidence that the key to decoding the #1 document is not
just some other text than the DOI. It's very strong evidence that key
was somehow constructed using the number/letter pairs that make up the
key to the #1 document.
Ed's idea of building a table of letters and numbers from the DOI, and
then adding more letters say across the top to create a new key makes
a lot of sense. It would be simple to send this page as the "key" to
the documents with instruction to use the top letters for the #1 document
and the left side letters for the #2 document.
> So one can prove that this was not
> the case,
Since there was nothing implying how the #1 document was encoded, you
can't prove that at all.
> and additionally, as the papers were encoded at a given date
> in the past, one can eliminate from consideration such methods as DES
> encryption.
Yes, the age of the text gives good clues to what might have been possible.
We know the text is at least as old as the publication which dated back to
I think something like the mid 1800s. And if you believe the story as told
in the pamphlet (and the #2 document) the cyphers were created many years
before that (after 1821?)
--
Curt Welch http://CurtWelch.Com/
[EMAIL PROTECTED] Webmaster for http://NewsReader.Com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: primes in dh
Date: Mon, 13 Sep 1999 20:17:54 GMT
I don't quite understand the page...
----
E.1. Well-Known Group 1: A 768 bit prime
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
15525180923007089351309181312584817556313340494345143132023511949029662399491
02107258669453876591642442910007680288864229150803718918046342632727613031282
98374438082089019628850917069131659317536746955176311984337163722100721057791
9
--- this is the decimal value of the 768 bit prime right (which is dh safe?)
The representation of the group in OAKLEY is
Type of group: "MODP" Size of field element (bits): 768 Prime modulus:
21 (decimal) Length (32 bit words): 24 Data (hex): FFFFFFFF FFFFFFFF
C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22
514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF Generator: 22
(decimal) -- so it's 22^x mod p ? Length (32 bit words): 1 Data (hex): 2
-- or is it 2^x mod p?
I don't understand the layout that's all...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Mon, 13 Sep 1999 14:09:06 -0700
[snipped]
> > > How long do the streams tend to be?
> >
> > In one session there are several different streams, ranging from one
<1KB to
> > one that I've seen at slightly over 1GB, the average though can be
expected
> > at about 1MB
>
> OK, are all the different streams in the session protected by the same
> shared secret?
There will be different key for each one, or if it's the same key there will
be obfuscation put in place so that they are no longer the same key (e.g.
different initialization vectors). It's also extremely doubtful that any of
the information will ever be repeated, probably a 1:2^36 for a 64-bit block,
but I'm trying to lower it further.
Joseph
------------------------------
Subject: Re: Mystery inc. (Beale cyphers)
From: [EMAIL PROTECTED] (Curt Welch)
Date: 13 Sep 1999 20:28:29 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> What I said was, the Beale ciphers are interesting because you <usually>
> can't prove a cipher is a hoax just by analyzing the ciphertext. The
> fact that long coherent and monotonic but intelligence-free strings can
> be decrypted from B1 using the very same key used to decrypt B2 puts the
> Beale ciphers into a different category: one where you <can> offer
> convincing evidence that it's a hoax by analyzing the numbers.
Opps. Sorry for mis-quoting you. I clearly didn't understand your point.
I however don't see it as convincing evidence. I do see how some people
would see it that way, I just didn't think you were one of them.
--
Curt Welch http://CurtWelch.Com/
[EMAIL PROTECTED] Webmaster for http://NewsReader.Com/
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Mon, 13 Sep 1999 13:57:38 -0700
[EMAIL PROTECTED] wrote:
>
> Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> : Eric Lee Green wrote:
> : > None of these are working for me if I'm wanting my code to run on
> : > HPUX, Solaris, or SCO Unix in unattended mode.
> Simply require the user to type several lines of random characters at the
> keyboard, and use that input as the starting point.
This meets the primary concern, which is predictability. Unfortunately,
I do not have a keyboard available in most environments. Most of the
machines involved live in closets or in equipment racks at a remote ISP
site.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: First draft of Ocotillo now online
Date: Mon, 13 Sep 1999 14:24:33 -0700
The first draft source of Ocotillo is now online at:
http://www.estinc.com/~eric
Note that because it uses cryptographic components, source code is only
available to U.S. residents. Please respect the CGI form because
otherwise my employer will force me to take the page down.
Anyhow: That's a first attempt at a pseudo-random number generator for
Unix platforms which do not have a cryptographically secure PRNG. It
uses two input pools into a crypto algorithm outputting into an output
pool. The two input pools are MD5 hashes, one is used as a 128-bit key
and the other is used as the input value to the algorithm. The output
pool is an MD5 hash. The encryption algorithm doesn't matter, as long as
it's a cryptographically secure 128-bit block cipher that will accept
128-bit keys (such that the output looks statistically random). I've
used RC6 there, I'm currently using TwoFish there, I'll probably take a
close look at Rijndael within the next day or two. My thanks to Dr.
Brian Gladman for the use of his encryption routines.
Note: There is a more detailed README within the archive. The algorithm
itself is quite simple, though the actual MD5 and TwoFish are not.
My worries:
1) Finding sources of adequate initial entropy. I don't think I've done
a good job there, there's just not many sources on raw Unix :-(.
However: There is provisions for adding more values to the input pool.
One suggestion was to use the "jitter" between the times that keystrokes
came in, etc.
2) How random is the output when asked to give huge numbers of values?
I've done some initial frequency intervals and on a long-term basis my
distribution appears quite random, but somebody with more cryptoanalytic
expertise is likely to see a problem there.
3) How random is the distribution of initial values, considering that
this thing will primarily be used as part of a server that starts up
near system boot time and stays running for as long as the system is
running? This is a place where I'm going to be doing further study.
4) Is the MD5 hash on the output necessary? I've tried it both ways,
with and without the hash. In both cases the output appears to be
statistically random. The thought is that the MD5 hash on the output
prevents backtracking attacks, is that reasonable?
All in all, because I used proven cryptographic components I'm confident
that it is at least stronger than most "random" number generators used
by consumer products, but I still get that niggling feeling that because
I'm a newby to crypto I overlooked something obvious...
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: H.235 Keys from Passwords algorithm
Date: Mon, 13 Sep 1999 21:30:27 GMT
"Douglas Clowes" <[EMAIL PROTECTED]> wrote, in part:
>is it just me, or is this less than secure for generating keys
It is indeed inadequate, since the first three bits of all lowercase
letters, for example, are all the same. As an _absolute minimum_, if
the password is longer than the desired key, when an extra password
character is XORed to an existing key byte, that key byte should first
be rotated (right or left) by three bits. (A hash function in that
case is, of course, much better.)
For passwords equal to, or shorter than, the key in length, there is
no need for improvement because the only thing that can be done to
interfere with a brute-force search is to deliberately slow the
process, something along the lines of the Blowfish key schedule.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Sources of randomness
Date: Mon, 13 Sep 1999 21:19:03 GMT
Mok-Kong Shen wrote:
> Question: How about [...]
> obtaining random bits from apparently periodic phenomena?
> Since perfectly periodic events are rare in real life and one has
> mostly at best only 'almost periodicity', I think one can somehow
> filter out the periodic wave form to obtain the noise that is
> superposed on it.
We wouldn't want to filter out the non-randomness, so
much as condense down the randomness. A good method
is to XOR the low entropy source bit stream into the
feedback of a large linear feedback shift register
(with taps corresponding to a primitive polynomial,
as usual). The nice fact about the technique is that
as long as the source stream is independent of the
register state, the register never loses entropy.
The technique is similar to computing a CRC over the
source - the only difference is that CRC polynomials
are invariably not primitive.
The remaining question is how long we have to run
the LFSR before it's state is almost all entropy. Of
course that depends on the source stream, and there
is no measurement that can establish a reliable lower
bound.
> A related question (posted also in another thread): What is the order
> of magnitudes of the demand of random bits per unit of time for
> generating session keys in some typical environments?
Well, I'd say None. We need true randomness to start
in an unknown state, but after that we can generate
the keys we need deterministically. If entropy is a
precious resource, we should invest most of it in
ensuring our initial state is unpredictable, rather
than in generating truely independent session keys.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: H.235 Keys from Passwords algorithm
Date: 13 Sep 1999 21:06:22 GMT
In article <bZXB3.10800$[EMAIL PROTECTED]>,
Douglas Clowes <[EMAIL PROTECTED]> wrote:
>Section 10.3.2 of ITU-T H.235 states in part:
>
>The encryption key is length N octets (as indicated by the AlgorithmID), and
>is formed as follows:
>� If password length = N, Key = password;
>� if password length < N, the key is padded with zeros;
>� if password length > N, the first N octets are assigned to the key,
>then the N + Mth octet of the password is XOR'd to the Mmod(N)th octet (for
>all octets beyond N) (i.e. all "extra" password octets are repeatedly folded
>back on the key by XORing).
>
>is it just me, or is this less than secure for generating keys to be used in
>algorithms like RC2, DES, 3DES, MD5, SHA1?
This sounds like a terrible scheme. If password length = 2N and
consists of a phrase repeated twice (e.g. N=7 and
password=abcdefghabcdefgh), the key is set to all zeros.
------------------------------
Subject: Re: Mystery inc. (Beale cyphers)
From: [EMAIL PROTECTED] (Curt Welch)
Date: 13 Sep 1999 21:36:05 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Curt Welch wrote:
> > The alphabetic strings that appear when #1 is decoded with the DOI
> > is far from random so that's a _big_ clue to the encoding.
>
> Unfortunately, the better those clues, the *more* likely that it is
> all a hoax. The reason is, this *type* of cipher does *not* produce
> long alphabetic runs
A multiple substitution cypher has enough degrees of freedom to make
it very easy to create the long alphabetic runs when decoding the cypher
with the wrong key. For that matter, it's also very simple to encode two
completely different clear text messages in one cypher text given a "key"
made from a 26x26 table of numbers. The numbers would only have to range
from 1 to 676 (26^2) to provide for two completly independent clear text
encodings in the same cypher text. All three of the Beale cyphers have
numbers larger than that. The DOI has over 800 words.
So it's very easy to see how the strings _could_ appear in #1 when decoding
with the wrong key, and how at the same time, the associated cypher text
numbers could translate to other valid clear text when using the correct
key. But the question then becomes, why would this happen?
You can take the easy way out and say "hoax", or ...
You can look at Ed's table theory is one very simple example of how and why
this could have happened. If you don't understand his theory because you
didn't take the time to read my message, then go back and read it again.
If you didn't understand my message, I'll be happy to explain it so you can
understand it. If you think the theory is a poor explaination for the
strings, I'd like to hear your thoughts on that.
What the alphabetic strings shows in my mind is that there is some type of
correlation between the key for #1 and the key for #2.
It's also easy to see that if some other key document was used to encode
#1, it would be very unlikely for the strings to appear (as everyone keeps
pointing out). And though it would be possible, it would be a lot of work
on the part of the encoder to intentionaly create the strings - and I for
one can see no reason the encoder would bother to take the time to do that.
(even if this was a hoax).
This leaves us with the concept that the key for the #1 document was
not some type of book cypher created from some text other than the DOI,
but that most likely, the "key" (i.e. letter to number mappings) was
generated from the DOI key used for the #2 document. And that the list of
numbers was sorted alphabetically at some point in the process (if not, the
alpha strings, once again, would not happen by chance).
There's no "proof" that this is the correct path to search for a solution,
but there sure is strong evidence in my mind that this is the way to go.
And I've seen no other explanation for the alpha strings that would lead to
another path to search.
--
Curt Welch http://CurtWelch.Com/
[EMAIL PROTECTED] Webmaster for http://NewsReader.Com/
------------------------------
** 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
******************************
