Cryptography-Digest Digest #727, Volume #10 Sun, 12 Dec 99 17:13:01 EST
Contents:
Re: New RNG Technique (Scott Nelson)
Re: Attacks on a PKI (Larry Kilgallen)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
The Cracking of SecurityPlus! 4.32 (JPeschel)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: The Cracking of SecurityPlus! 4.32 (Troed)
Re: How do you get past the password screen to the crypto? (Joseph Durusau)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Linear Congruential Generators (wtshaw)
Re: Attacks on a PKI ("Lyal Collins")
Are thermal diodes as RNG's secure ([EMAIL PROTECTED])
Re: Brute Force Time (Maximum v Probable) ([EMAIL PROTECTED])
Re: Questions about message digest functions (wtshaw)
Re: Scott's Screaming Security Method (wtshaw)
Re: Linear Congruential Generators (Mok-Kong Shen)
Re: Insecure PRNG? (CLSV)
Re: Insecure PRNG? (Guy Macon)
Please help this newbie crack a potentially simple encryption (John)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: New RNG Technique
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 17:53:53 GMT
On 10 Dec 1999 [EMAIL PROTECTED] (Steve Harris) wrote:
[suspiciously troll-like stuff sniped]
>3.) For DIEHARD, you collect four bytes, then store them as a 32-bit number. For
>other implementations, harvest as many bytes (or bits) as desired.
>5.) You probably know that you need at least 2,867,200 numbers for DIEHARD.
>
Considering the rest of the post, this is but a minor quibble,
but... you usually need less than 2110000 numbers.
The squeeze test can in theory require more, but it's
exceptionally unlikely. The documentation for DiehardC
includes a list of the exact numbers of bytes used by
each of the tests. If you use Diehard at all,
it's probably worth downloading DiehardC just to read
the documentation.
ftp://ftp.helsbreth.org/pub/helsbret/random/
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Attacks on a PKI
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 18:13:32 GMT
In article <82vqnl$q1d$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> writes:
> What seems "revolutionary" to me _now_ is that the key infrastructure
> does not seem to be as well understood, as accountable, or as well
> regulated as many of the other third parties I depend on. It's not
> completely clear what I should expect from a PKI, while in many real
> life cases the expectations are so amazingly clear that stating them
> seems pedantic.
But real life cases are not so clear. If you buy a house in the
United States you typically need a title search. In Massachusetts
you need a lead paint certification, etc.
The main difference with a vendor of PKI services is that the
governing law is mainly limited to contract law, so you have
to read the contract with your chosen vendor before signing it.
You should not expect anything not stated in the contract, and
your contract should not impose ridiculous constraints. For
example, if you agree to run your CA with a BBN Safekeeper
using at least 3 out of 5 physical keys you should expect
the same degree of security from your PKI vendor.
Larry Kilgallen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Sun, 12 Dec 1999 18:29:57 GMT
[EMAIL PROTECTED] (Guy Macon) wrote:
> [...] [EMAIL PROTECTED] (Tim Tyler) wrote:
> >Guy Macon <[EMAIL PROTECTED]> wrote:
> >: [EMAIL PROTECTED] (Tim Tyler) wrote:
> >:>OTPs are [...] useless against simple complete known-plaintext
> >:>attacks.
> >
> >: It depends on what you mean by "useless". I would say that
> >: being able to send other plaintexts without the attacker being
> >: able to decode them is quite usefull, wouldn't you?
> >
> >If (as I specified) the attacker has a "complete known plaintext",
> >he has no need to decode and read the encrypted message - since he
> >knows its entire contents completely anyway.
>
> Except for the (huge!) hole of allowing the attacker to substitute
> his own plaintext if and only if he can stop the senders messsage,
> a known plaintext attack that only reveals the known plaintext and
> no other would seem to be, to coin a phrase, useless. [...]
The attacker gets the key. This means that - if he can get a number of
consecutive messages - he can *directly* examine the random numbers that
compose the OTP for deviations from randomness.
Since such deviations from randomness are not practical to completely
eliminate - and these have existed in a number of hitorical sources of
numbers for actual OTPs - this might even be worth doing.
Sometimes, if the eavsdropper has knowledge that there's a 50/50 chance
of a message being a complete known plaintext, he can verify this by
substituting a message that would provoke some action upon receipt
(the substitution being made on the assumption that the message
contains the plaintext he knows) and then observing the reaction of
the recipient.
Requests to resend garbled messages on the part of the recipient can
also convey this type of information.
Apart from these possible attacks - and allowing substitution of fake
messages that decode correctly (if the messages are unsigned) - I
would agree that complete known-plaintext attacks against OTPs don't
typically give the attacker much that he does not already know.
--
__________
|im |yler
A bug in the code is worth two in the documentation.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: The Cracking of SecurityPlus! 4.32
Date: 12 Dec 1999 18:49:10 GMT
Part of A. of Casimir's essay, "The Cracking of Security Plus,"
is now up on my web site. Parts B and C will soon follow.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Sun, 12 Dec 1999 20:16:14 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > As discussed in the past in this group, there can be no
> > scientifically rigorous yet practically useful quantitative
> > measure of strength of crypto algorithms.
>
> That should not be taken as gospel. In fact there are papers
> on provable minimum work factors for certain schemes. I've
> also explained (ages ago) what form proper statistical
> (information-theoretic) criteria could take.
That however has been the result of past discussions, as far as I
understand. The point is that it is very hard (in my humble opinion
impossible) to compare two different crypto algorithms and say that
the one is r times stronger than the other, where r is a certain
precise real number. (Compare on the other hand e.g. the relative
strength of materials.) One basic reason underlying that, I believe,
is that, given any properly designed algorithm, one generally has no
way of knowing which is the most efficient way of attacking it and
hence one normally can't determine the factor of expense of cracking
one algorithm relative to another algorithm. (The person who succeeds
to crack an algorithm in a clever way may choose to keep his result
unpublished.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: The Cracking of SecurityPlus! 4.32
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 19:13:15 GMT
[EMAIL PROTECTED] (JPeschel) wrote:
>Part of A. of Casimir's essay, "The Cracking of Security Plus,"
>is now up on my web site. Parts B and C will soon follow.
Nothing on Kremlin's implementation of IDEA? :) I must confess to
having forgot my password for a file I encrypted long ago ...
(yes, it's very embarassing .. )
___/
_/
Nazister, rasister och andra d�rar - ger bara sig sj�lva kalla k�rar
------------------------------
From: Joseph Durusau <[EMAIL PROTECTED]>
Subject: Re: How do you get past the password screen to the crypto?
Date: Sun, 12 DEC 99 14:08:59 -0500
<[EMAIL PROTECTED]> writes:
>My PC harddrive is encrypted, so when I start it up, it asks for a
>password to decrypt. If the wrong password is entered 3 times then the
>computer jams up.
>
>The question is how does an attacker get past the password bit to the
Assuming that it is really 'your' computer, and that you
have a lot of time on your hands, go into the bios setup and make it
boot from floppy first. Put a DOS floppy into the A drive ( you might
have to install one if it has been removed). Then turn the machine off
and back on. Once DOS boots, you can either use debug or one of the
disk utility progs to probe the disk till your heart is content.
If someone who uses the machine regularly knows how to use
it, a better solution is to install a bus monitor card with lots
on memory inside the thing. Set the monitor up to record the first
bus cycles, then read it out later. You will probably have to try
several times until you find out what you need to look at, but
finding the password stuff should not be all that hard.
Speaking only for myself,
Joe Durusau
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Sun, 12 Dec 1999 14:42:20 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
> I think Microsoft(tm) "improved" the HTML format. They _call_ it HTML, but it
> isn't.
>
> It's funny that they started as a language company, and WHG3 understands
the value
> of good tools. But they keep screwing things up just enough to
disqualify them
> for serious work. I suppose if they are aiming Really Bad Software at
the masses
> of amateur developers quality doesn't matter -- most of their customers
can't tell
> the difference.
>
There slogan has seemed to be for years, *mediocrity for the masses, and
spoils for us.*
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Sun, 12 Dec 1999 14:40:04 -0600
In article <82t706$m7l$[EMAIL PROTECTED]>, "Rick Braddam"
<[EMAIL PROTECTED]> wrote:
> Why? Would you, for example, need to view Windows98 help files on a
> machine running Linux or Mac's OS? Well, if you want to, you *can* read
> Information Server, JScript, Transaction Server, Personal Web Server,
> and VBScript help files with a browser... but why would you want to? If
> you have those programs for another platform, you should have the html
> files or the OS specific help files for them.
I look at files cross platform all the time. It is amazing what you find
out about incompatibilities, and hanky panky. Consider looking a html as
text so you can learn how and what someone is doing.
>
> I don't have a man page reader. There are hundreds if not thousands of
> "help" files for *nix systems that I can't read. So far, that hasn't
> been a limitation. OTOH, web browsers are widely and freely available,
> so there's no reason why anyone shouldn't have one.
I fall back to Mosaic as the fundamental one, as it tends to handle the
pages of those who are warry of riding the wave. Backwards compatibilty
is important, indeed, the text compatible mandate from government is
around the corner, something I do agree with. This has everything to do
with encryption, as vertical and horizonal integration as well as platform
and historic compatibility are important to be considered for all
essential program areas.
>
> BTW, I've used FrontPage (because it's what I've got) to generate a text
> file as an html file -- a text web page. I only used two hyperlinks,
> for file downloads, and nothing else specific to html. It was as easy as
> using a word processor or text editor. Of the two downloads, one is a
> prototype VxD device driver for allocating locked memory, the other is a
> dummy for developing and testing the BTree routines which will be used
> in the VxD. The page is at
> http://www.aic-fl.com/rbraddam/workin.htm -- it ain't much, but it
> shows how little more than a plain text file an html page can be.
It is not so difficult to cut the apron strings and write html from scratch.
....
>
> I'm sure you've seen Terry Ritter's pages with the embedded graphics.
> Have you also checked out his newsgroup archives to see how some of them
> looked as text files? I like his web pages much better. I've seen other
> pages which added animation to show data flow, and I consider that
> another step forward. Terry's pages *are* help files for me, and I'm
> glad they aren't just text files.
>
They are appropriate, and you are stretching the topic. Helps are an
option for a program, and there are several ways to do them. Making them
a route to add one more justification for a failed idea shows the scum
that the government is trying to clean up, which has nothing todo with
many of the people that work for the scum.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Linear Congruential Generators
Date: Sun, 12 Dec 1999 14:47:26 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Using a RNG under these circumstances is like using a screwdriver to crack
> a nut - it's simply the wrong tool for the job.
Close, since a pRNG is a tool, it does matter how you use it at to its
effectiveness. Like cracking an algorithm, consider how much of the seed
state(s) you must crack to have anything.
--
When the horse dies, get off.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Mon, 13 Dec 1999 07:27:01 +1100
"should" and "will" mean difference things.
Those who beleive in "should" for PKI live in hope - one day, perhaps this
year...
Lyal
Douglas A. Gwyn wrote in message <[EMAIL PROTECTED]>...
>David A Molnar wrote:
>> None of these is the real expectation. The real expectation is that
>> "this food won't make me sick." The rest is professionalism.
>> The difference seems to me that with a PKI, I take a look at a key
>> and it's not clear immediately what kind of keys "won't make me sick."
>
>Come on, at that level it is obvious: You should be able to get
>the authentic public key for any communicant.
>
>The details are at the same level as for food transport and
>storage..
------------------------------
From: [EMAIL PROTECTED]
Subject: Are thermal diodes as RNG's secure
Date: Sun, 12 Dec 1999 20:38:26 GMT
Is a termal diode being used as a RNG secure?
Is it possible to manipulate the electronics to make the output of the
diode not-so-random?
Any URLs would be nice
David
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Brute Force Time (Maximum v Probable)
Date: Sun, 12 Dec 1999 20:35:33 GMT
In article <82ui9k$rt1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (UBCHI2) writes:
> ...
> >The industry should shift from quoting maximum time to crack a key
to quoting
> >probable time to crack a key.
>
> The estimates are so crude that the difference between the two is
> irrelevant.
>
>
It is often more quicker to analyse, identify weakness and then attack
the PRNG, or look for a side channel (or some window) attack.
Problem is that vendors will use the largest time to crack their
package as a selling point. In reality, a serious attacker will resort
to brute force as a last means (and only then is the key is small)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Questions about message digest functions
Date: Sun, 12 Dec 1999 14:59:41 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
>
> :> Have there been any papers published on
> :> 1a) Whether SHA-1 is a permutation for a message the same length as the
> :> digest-length (160 bits)? [snip]
> :> 1c) Is this true (or can it be true) for any other, supposedly secure,
> :> one-way, collision resistant, hash-functions?
>
> : 1c holds a host of sins of presumption.
>
> Another wtshaw cryptic comment ;-)
>
> What is the answer to 1c?
>
> Is it true? Tim does not know for certain, but thinks the answer is
> "yes":
>
> Hash functions may be made from block cyphers. Block cyphers are
> reversible. Consequently, a message hash of a message with the hash
> size, the block size and the message size all equal will be a bijection.
>
> *Can* it be true? *Definitely* "yes".
Since you asked, I resolve a portion of my comment: collisions and
security of a hash function work in opposition, no collisions meaning that
the input can be solved, be that perhaps inconvenient. But, if lots rode
on the solution, it might be worth it.
As for block ciphers being so simple and symmetric as to be reversable, I
know of at least one that is not, depending on whether you call it a block
cipher. Surely there is a war of data to have just sufficient collisions
to maximize a function as a hash and insufficient reversability to allow
its solution.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.compression,alt.security
Subject: Re: Scott's Screaming Security Method
Date: Sun, 12 Dec 1999 15:09:15 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Loney Ramik) wrote:
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> >Any thoughts on this by my nonadmirers.
>
> I'm a little puzzled by the name you chose. How will screaming help, Scott?
Probably helps if you have lots of hair too, but since Scott is a bit shy
on that department, I figure that he is not the intended one to do the
screaming. It's a catchy name, however.
--
When the horse dies, get off.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sun, 12 Dec 1999 22:41:17 +0100
Herman Rubin wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >I surmise that it might be better to use the parity bits of the output
> >of PRNGs. From experiments I found that parity bits from LCPRNGs
> >have fairly good statistical properties. I am not aware of methods
> >of inference on parity bits. But perhaps experts would like to furnish
> >such informations.
>
> But this would mean that one would only get one bit from an
> iteration, greatly adding to the cost.
>
> I presume you mean the parity of the number of 1's. The least
> significant bit here is not likely to be good.
You are certainly right that the cost is considerable but it is quite
comparable to using the most significant bit. On the other hand, while
according to a follow-up in this thread there is method of analysis
in the case of the most significant bit, no method of analysis of
the parity bit appears to have been developed.
To avoid confusion perhaps I should point out that in one of my own
algorithms the 'parity bit' is obtained in a somewhat special manner.
I divide the LCPRNG output by its modulus to obtain a real number
which is then multiplied with 2^24 to result in 24 bits. Then the
parity bit of groups of 32 bits is taken. So a 'parity bit' there
stems from more than one single number output from the LCPRNG.
M. K. Shen
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Sun, 12 Dec 1999 21:39:17 +0000
Mok-Kong Shen wrote:
> [...] The point is that it is very hard (in my humble opinion
> impossible) to compare two different crypto algorithms and say that
> the one is r times stronger than the other, where r is a certain
> precise real number.
It is impossible to compare anything without giving
a context. You could however compare two cryptographic algorithms
in the context of a specific attack (e.g. differential cryptanalysis).
> (Compare on the other hand e.g. the relative strength of materials.)
So what is stronger: a steel or a wooden beam?
Again, given no context there is no valid comparison.
*Proving* real-world characteristics is much harder than proving
theoretical concepts.
> One basic reason underlying that, I believe,
> is that, given any properly designed algorithm, one generally has no
> way of knowing which is the most efficient way of attacking it and
> hence one normally can't determine the factor of expense of cracking
> one algorithm relative to another algorithm. (The person who succeeds
> to crack an algorithm in a clever way may choose to keep his result
> unpublished.)
We can discuss security against known attacks in both a practical
and scientific way as long as we do keep in mind that we do not have a
computable absolute security measure. Of course the last fact is
good to mention when someone is claiming absolute security.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Insecure PRNG?
Date: 12 Dec 1999 16:43:55 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>
>Mok-Kong Shen wrote:
>> As discussed in the past in this group, there can be no
>> scientifically rigorous yet practically useful quantitative
>> measure of strength of crypto algorithms.
>
>That should not be taken as gospel. In fact there are papers
>on provable minimum work factors for certain schemes. I've
>also explained (ages ago) what form proper statistical
>(information-theoretic) criteria could take.
Certainly there is a scientifically rigorous yet practically
useful quantitative measure of strength in the degenerate
cases of no encrytion at all and an OTP with true random key.
If one was to vary slightly from the above (say, encrypting one
character out of 100 and leaviong the rest plaintext), you could
still derive a scientifically rigorous yet practically useful
quantitative measure of strength. On the other hand there are
encryption methods that sure do seem to fit your secription.
It's the phrase "there can be no" that I object to, not the main
point which seems to be true in most cases.
------------------------------
From: [EMAIL PROTECTED] (John)
Subject: Please help this newbie crack a potentially simple encryption
Date: Sun, 12 Dec 1999 15:01:35 -0700
Hello there
I am new to cryptology and cryptanalysis, but find it great fun. I have
found your web site to be helpful. You seem to be fairly knowledgeable
bunch in the subject and I assume you are of comparable ability in
decipherment. I have received a recent challenge to "crack" a code and
have come up with little success. I am hoping that you may be able to
lend me some guidance on how to proceed from the point I am at.
Here is the "code", as presented to me:
82 44 22 67 83 11 35 93 52 11 51 64 71 45 15 31 94 51 66 32 58 93
83 15 52 77 94 21 47 96 34 22 71 56 22 63 82 48 23 31 85 73 16 39
72 15 11 55 47 96 34 22 71 51 26 91 95 12 16 92 91 19 12 35 71 54
33 23 11 96 31 31 73 82 91 33 79 82 34 52 81 78 52 75 31 27 72 93
95 22 57 92 93 79 22 59 17 96 35 11 73 51 27 93 96 15 35 37 87 18
54 71 54 14 33 92 76 71 16 67 95 71 37 39 95 46 11 93 82 44 29 57
44 71 91 13 15 56 23 35 71 14 55 94 66 35 17 54 13 91 71 72 26 39
85 17 58 87 91 18 46 84 51 47 17 58 48 96 66 21 47 77 33 33 72 52
27 38 95 71 37 51 46 82 33 24 59 31 85 14 53 87 38 33 13 84 53 44
16 66 77 15 57 85 35 11 71 94 98 51 83 11 33 91 94 15 27 92 51 27
42 93 65
Additional information given to me:
"The solution is a single sentence taken at random from a renowned
English�language encyclopedia. Punctuation is ignored"
What information I have gathered while analysing this sequence:
o I make the assumption that "Punctuation is ignored" includes the
absence of spaces
o All numbers are double digits, the zero digit is completely absent.
This hints towards the use of grid having x and y axes of 1 to 9. This
leaves for a potential of 81 different double-digit numbers
o 81 is 3 times 27, which is one greater than the full english alphabet.
Possibly the alphabet is repeated 3 times with a space between each
instance of it
o of the 81 possible numbers, only 65 are used, indicating that 16
numbers are not used, either being spaces between alphabets or letters
not used "such as possibly z,x,j etc"
o the code has 223 individual numbers, which leads me to believe that the
numbers represent individual letters, or the sentence would be incredibly
long (223 times 2 letters would be 446 letters, or about 70+ average
length words......while 223 times 1 letter /6 letters per word is about
35 words)
o
the number of incidences of the numbers and the frequency are relayed
below:
Number #Instances Frequency (%)
71 12 5.4%
11 8 3.6%
33 8 3.6%
51 8 3.6%
15 7 3.1%
35 7 3.1%
91 7 3.1%
93 7 3.1%
22 6 2.7%
31 6 2.7%
82 6 2.7%
96 6 2.7%
27 5 2.2%
52 5 2.2%
94 5 2.2%
95 5 2.2%
16 4 1.8%
17 4 1.8%
44 4 1.8%
47 4 1.8%
54 4 1.8%
66 4 1.8%
72 4 1.8%
85 4 1.8%
92 4 1.8%
13 3 1.3%
14 3 1.3%
23 3 1.3%
34 3 1.3%
37 3 1.3%
39 3 1.3%
46 3 1.3%
57 3 1.3%
58 3 1.3%
73 3 1.3%
77 3 1.3%
83 3 1.3%
87 3 1.3%
12 2 0.9%
18 2 0.9%
21 2 0.9%
26 2 0.9%
38 2 0.9%
48 2 0.9%
53 2 0.9%
55 2 0.9%
56 2 0.9%
59 2 0.9%
67 2 0.9%
79 2 0.9%
84 2 0.9%
19 1 0.4%
24 1 0.4%
29 1 0.4%
32 1 0.4%
42 1 0.4%
45 1 0.4%
63 1 0.4%
64 1 0.4%
65 1 0.4%
75 1 0.4%
76 1 0.4%
78 1 0.4%
81 1 0.4%
98 1 0.4%
10 0 0.0%
20 0 0.0%
25 0 0.0%
28 0 0.0%
30 0 0.0%
36 0 0.0%
40 0 0.0%
41 0 0.0%
43 0 0.0%
49 0 0.0%
50 0 0.0%
60 0 0.0%
61 0 0.0%
62 0 0.0%
68 0 0.0%
69 0 0.0%
70 0 0.0%
74 0 0.0%
80 0 0.0%
86 0 0.0%
88 0 0.0%
89 0 0.0%
90 0 0.0%
97 0 0.0%
99 0 0.0%
Further analysis of the code shows a number of repeated sequences (where
two or more numbers are adjacent to each other on more than one
occasion):
Combination Start position in code
82 & 44 1 129
83 & 11 5 211
31 & 85 40 188
35 & 71 64 140
71 & 54 65 112
35 & 11 99 205
51 & 27 102 219
95 & 71 & 37 121 179
47 & 96 & 34 & 22 & 71 29 49
The last two combinations seem to be the most useful. I figure that 95 &
71 & 37 may very well be the word "the". Meanwhile, I am thinking that
the longest combination is likely to be a full word, which (being
repeated) may be a noun or verb that is directly related to the topic of
the sentence. Of course, these are only guesses. Now if the code is
split into columns....the two repeats of the five letter combo line up
when in 2, 4 and 5 column formats, meanwhile the three letter combos do
not line up with each other in any column pattern except 2 columns (I
think this is not very meaningful). Three of the other seven combos only
line up in the four column format. This evidence, along with evidence
showing no strong groupings of number frequencies when divided into four
columns (maybe you want to check this for yourself...I could be wrong on
this.....just count number frequencies down the columns of a four column
format), leads me to believe that a typical "key word" is not likely
being used in a Vigen�re-style cipher.
I have tried to guess and assign letters to numbers (not allowing any
letter to be represented by more than 3 separate numbers) based on their
frequencies and the frequency occurance of certain letter combos.
However, this has met with little success, and even using a small qbasic
program I wrote to cycle through the possibilies, a brute force method
could take years. There must be some other "clues" or techniques I have
missed. I am hoping you may have some good suggestions (any charts on
reliable letter frequencies in the english language (especially english
encyclapedias, ranked 2 and 3 letter combos and most common 4 and 5
letter word in the language would also be extremely helpful).
Thank you in advance for all and any assistance you can provide (I am
trying to obtain some books on the topic, but the libraries here are not
well equipped in this topic).
John
------------------------------
** 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
******************************
