Cryptography-Digest Digest #957, Volume #11 Tue, 6 Jun 00 15:13:01 EDT
Contents:
Re: bamburismus (Sundial Services)
Re: XTR independent benchmarks ("Eric Verheul")
Re: bamburismus (Sundial Services)
Re: Quantum computers (Mike Rosing)
Re: Some dumb questions (Jim Gillogly)
Re: Some dumb questions (Joaquim Southby)
Re: Solution for file encryption / expiration? (Frank M. Siegert)
Re: slfsr.c (Mike Rosing)
Re: Some dumb questions (Joaquim Southby)
Re: bamburismus (Terry Ritter)
Re: Some dumb questions (Joaquim Southby)
Re: Some dumb questions (Mike Rosing)
Re: Question about recommended keysizes (768 bit RSA) (Bob Silverman)
Re: slfsr.c ([EMAIL PROTECTED])
Re: Need "attack time" measurements on a toy cipher... (long) (Mike Rosing)
Re: Solution for file encryption / expiration? (Andru Luvisi)
Brute forcing for Counterpane's Password Safe ("Joeseph Smith")
Request for review of "secure" storage scheme (Rodd Snook)
Re: Some citations (wtshaw)
Re: Cipher design a fading field? (wtshaw)
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Some citations ("Douglas A. Gwyn")
Re: Some dumb questions (Jim Gillogly)
----------------------------------------------------------------------------
Date: Tue, 06 Jun 2000 10:15:51 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: bamburismus
Gentlebeings, do we ever reach the point where the strength of the
cipher is "strong enough?" I mean, you could theoretically keep piling
on layer upon layer of crypto-algorithms until the chances of anyone
cracking them all "through the front door" becomes zero. It's like
putting a bank vault inside a bank vault inside a tomb. There comes a
point when you are just not going to try to break in through the
front-door. You are going to attack the key-management, the translation
of the user's pass phrase, what-have-you. The front door might be
impregnable but right next door to that there might be an open window.
Douglas A. Gwyn wrote:
>
> John Savard wrote:
> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
> > >Which part?
> > That, at (presumably) a specific date in the past, the NSA definitely
> > could not crack 3DES.
>
> At some unspecified time in the past nobody could crack 3DES,
> so far as I know, but how long ago, and how complete is my
> knowledge? It is obviously true if you go back far enough,
> and anyway it is generally believed that 3DES is uncrackable.
>
> > That, at a specific date in the past, the NSA was in posession of
> > theoretical results relevant to the cracking of 3DES ..
> [...]
>
> > As to the question of _genuine_ damage to national security,
> > however, I will admit to being unqualified to comment.
>
> I am quite careful not to damage legitimate US national security
> interests. If you want, I can put you in touch with the
> appropriate people to discuss the matter; send me e-mail. An
> open forum like this is not appropriate for such a discussion.
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: XTR independent benchmarks
Date: Tue, 6 Jun 2000 18:59:16 +0200
> + somewhat lower bandwidth (512 vs 342 bits)
> + faster parameter generation
> +- may be somewhat faster or slower key-pair generation and
key agreement
> depending on optimization choices
If chosen right, XTR can be more than twice as fast as LUC.
> +- neither can take advantage of precomputation
> - slower key validation
>
> All this is probably irrelevant because the differences are
just not great
> enough to matter. People are either going to use ECC when
bandwidth is
> important, or DH over GF(p) when it's not.
You missing the point: ECC's security is not Rock Solid. Compare
this
with the paper of A. Odlyzko in Codes Designs and Cryptography
where
he advises 300 bit ECC keys for moderate security!
XTR is based on the DL problem in a finite field, the security
of which is [more] Rock Solid.
------------------------------
Date: Tue, 06 Jun 2000 10:18:30 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: bamburismus
Umm, didja notice that Mr. Gwyn's address is "@arl.mil?" We must at
some point assume that perhaps he -cannot- "publish some of the key
ideas," mmmm? Once you get a clearance you don't wanna lose it -- you
might wind up in Leavenworth. ;-)
>Mok-Kong Shen wrote:
>
> >"Douglas A. Gwyn" wrote:
> > [...]
> I understand. But you could at least publish some of the key
> ideas on a webpage. Maybe oneday some readers would be able
> to combine these with some of their own to obtain certain concrete
> significant results. If you could develop the ideas with your own time
> and energy, that's of course the best. Otherwise I suppose it is also
> satisfying for you, if you see oneday some published papers where
> the authors acknowledge your contribution.
>
> M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Quantum computers
Date: Tue, 06 Jun 2000 12:15:10 -0500
JCA wrote:
>
> Read what I wrote more carefully. I never said, or implied, that
> the NSA knows nothing about ECC. I just said when the fundamentals
> of ECC were published the NSA guys were not even considering
> such crypto avenues, as they have publicly acknowledged, and as
> an agency ex-member mentioned to me.
OK, I see where I misunderstood. It makes sense they wouldn't care
much about it if it was academic and unproven, but I guess I am suprised
they'd admit to ignoring it. They certainly aren't ignoring it now,
which is how I took your statement in the first place.
> Please show better manners before accusing someone in public of
> issuing clueless statements, especially when your counterarguments
> are so weak and subjective.
It's certainly in everyone's interests to write clearly.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Tue, 06 Jun 2000 17:21:44 +0000
Mok-Kong Shen wrote:
> 1. If a bit sequence has a certain known small bias in
> frequency but is uncorrelated, how can one exploit
> that fact to analyse messages encrypted with xor?
One can get more or less confidence that a possible plaintext
is associated with this particular ciphertext message, meaning
that some semantic information is leaked (unlike the ideal OTP
case) -- less information for smaller bias and shorter messages,
but some information nevertheless.
A few years ago an experiment was done in The Cryptogram (the
American Cryptogram Association's magazine): plaintexts were
encrypted with keys that were more and more random, and the
members were challenged to try to recover plaintext. It didn't
have to get too messy before I was unable to recover full
plaintext, but I don't recall the final scores, if they were
reported.
> 2. If an ideal OTP is misused, in that it is used a small
> number n of times, how is one going to attack, if
> absolutely no known plaintext is available?
Using assumed or guessed plaintext and crib-dragging. As n
increases, it becomes progressively easier to pick out strings
by eyeball. You might check further in the VENONA book you recently
recommended for a proof of principle. I don't know whether the extra
code step in VENONA makes it a more or less difficult first stage:
sometimes encoding plaintext makes it apparently more redundant.
Regardless, it was an impressive -- even Herculean -- feat, and the
Arlington Hall cryppies have my deepest respect.
--
Jim Gillogly
Highday, 17 Forelithe S.R. 2000, 17:08
12.19.7.4.17, 10 Caban 20 Zip, Seventh Lord of Night
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: 6 Jun 2000 17:30:05 GMT
In article <[EMAIL PROTECTED]> Volker Hetzer,
[EMAIL PROTECTED] writes:
>> 2. If an ideal OTP is misused, in that it is used a small
>> number n of times, how is one going to attack, if
>> absolutely no known plaintext is available?
>You xor the two ciphertexts together and the keystream falls out.
>What remains is a message encrypted with a decidedly nonrandom key.
>
This must assume that *something* is known about the plaintext. The
actual plaintext may not be known, but there could be knowledge of
headers, frequency of letter usage, etc.
If there is absolutely no knowledge of what's in the plaintext message
(this includes content, language, headers, footers, etc.), there is
little chance this attack will be successful. The ultimate example would
be if the OTP were used to encipher perfectly random numbers (an exercise
in futility, to be sure). Removal of the key stream would reveal two
sets of random numbers XOR'ed together -- not much to hang your hat on.
That said, the "absolutely no knowledge" is a fairly big risk. How can
one be assured the adversay has no knowledge of the plaintext? Ask them?
(Oops!)
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: Solution for file encryption / expiration?
Date: Tue, 06 Jun 2000 17:03:09 GMT
On 6 Jun 2000 16:32:35 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote:
>> It will stop people from 1) altering the PDF contents
>
>Oh. Why is this an issue? People can write notes in their books. This
>is considered good scholarly practice. (I don't do it myself because it
>makes the books manky.)
Neither do I, I love my books too much for that :-)
I think this is considered important for keeping forms and agreement
texts from being altered. So folks issuing PDF forms usually set this
protection. You can think of it as to disable the edit functions and
the "Save"/"Save as" command in the PDF reader/editor.
Of course this makes not much sense if you do not prevent printing the
PDF - as soon as it is PostScript again you can redistill it and
change the contents. Annotations and form fields may be lost during
this conversion step but could be reintegrated manually given time and
effort.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: slfsr.c
Date: Tue, 06 Jun 2000 12:39:37 -0500
tomstd wrote:
> Yeah my polynomial is invalid, please don't use SLFSR...
>
> Anybody no Maple enough to help out? I am basically copying the
> math from page 374 of Applied Crypto and it doesn't seem to
> work...
Can't afford Maple yet, but I've got C code that will find irreducibles
really fast. Check this out:
http://www.terracom.net/~eresrch/polymath/polymain.c
(and see page 49 in Implementing ECC).
Patience, persistence, truth,
Dr. mike
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: 6 Jun 2000 17:44:35 GMT
In article <[EMAIL PROTECTED]> Mok-Kong Shen,
[EMAIL PROTECTED] writes:
>(2) if there is a number of messages intercepted, one has to correctly
>pair the messages according to the OTP segment used (how is that
>going to be done?).
>
One crib might be if the plaintext uses a standard header. Let's say the
word "Attention" is the first word in every message. To pair one message
with another using the same OTP segment, you could try XOR'ing your first
intercepted message with all others. If you get zeroes where you expect
the word "Attention" to appear, that means that the messages must have
been enciphered with the same OTP segment. (This requires a lot of
cooperation on the part of the sender, to be sure.)
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: bamburismus
Date: Tue, 06 Jun 2000 17:46:05 GMT
On Tue, 06 Jun 2000 10:15:51 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Sundial Services
<[EMAIL PROTECTED]> wrote:
>Gentlebeings, do we ever reach the point where the strength of the
>cipher is "strong enough?" I mean, you could theoretically keep piling
>on layer upon layer of crypto-algorithms until the chances of anyone
>cracking them all "through the front door" becomes zero. It's like
>putting a bank vault inside a bank vault inside a tomb. There comes a
>point when you are just not going to try to break in through the
>front-door. You are going to attack the key-management, the translation
>of the user's pass phrase, what-have-you. The front door might be
>impregnable but right next door to that there might be an open window.
I think the answer to this is: "Yes."
Unfortunately, we don't -- and perhaps can't -- know when we have
reached that point. We are never sure that any particular cipher
system is "strong enough."
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: 6 Jun 2000 17:47:08 GMT
In article <[EMAIL PROTECTED]> Mok-Kong Shen,
[EMAIL PROTECTED] writes:
>Your argument is correct. But it lacks the desired 'concreteness' of
>solution to my problem. Note that I can only assume the frequencies
>of the characters in the language (at best that the frequency values
>assumed are exact) but otherwise I have no additional informations
>(digrams etc. are assumed to be largely destroyed through e.g. a
>simple transposition). One has to show a 'concrete' way how to get
>anything from the xor of the two messages. Note also that, if the
>OTP is used exactly twice, then (1) the xor of different pairs of
>messages (each pair has the same OTP segment, but different pairs
>have different segements) are essentailly unrelated to each other and
>(2) if there is a number of messages intercepted, one has to correctly
>pair the messages according to the OTP segment used (how is that
>going to be done?).
>
I understand your frustration. Too many "solutions" of problems lack
substance. Statements of the form "If you have x, then you can get y"
resemble the assumption that if you can jog 100 yards, you can run a
marathon.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Tue, 06 Jun 2000 12:46:35 -0500
Mok-Kong Shen wrote:
> Your argument is correct. But it lacks the desired 'concreteness' of
> solution to my problem. Note that I can only assume the frequencies
> of the characters in the language (at best that the frequency values
> assumed are exact) but otherwise I have no additional informations
> (digrams etc. are assumed to be largely destroyed through e.g. a
> simple transposition). One has to show a 'concrete' way how to get
> anything from the xor of the two messages. Note also that, if the
> OTP is used exactly twice, then (1) the xor of different pairs of
> messages (each pair has the same OTP segment, but different pairs
> have different segements) are essentailly unrelated to each other and
> (2) if there is a number of messages intercepted, one has to correctly
> pair the messages according to the OTP segment used (how is that
> going to be done?).
By autocorrelation. You take all possible combinations of xor and
offset
and look for similar sequences. If the OTP is used more than 2 times,
you have a very good chance of finding the same pad data, which means
you
can decode all n messages.
Might take a while for long files, but for short messages and a modern
computer, not more than a few seconds.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Tue, 06 Jun 2000 17:54:00 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8hiv0a$v21$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > You want a "high-end" machine in 1977? Try the CDC-6600.
>
> Bob, I hate to point it out, but your knowledge of the history of
> computing seems badly defective.
ROTFL.....
I was *there*. I was working at DEC when the VAX was first introduced
and was coding on high end CDC machines in 1978. (doing linear
programming). I was even coding on the CRAY-1S in 1980.
The VAX was considered a 32-bit MINI-Computer, even by DEC when it
was introduced. It was anything but a high end machine.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: slfsr.c
Date: Tue, 06 Jun 2000 17:54:28 GMT
hello tomstd !!!
i have modified your prog
/* return a shrunk bit */
static int lfsr_bit(unsigned long *l)
{
int a, b;
// do { a = lfsr_step(l); deleted
b = lfsr_step(l);
// } while (a); deleted
return b;
}
and after i do a diehard test no problem the test
is ok can you explain the utility of your routine
thanks !!!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Need "attack time" measurements on a toy cipher... (long)
Date: Tue, 06 Jun 2000 12:55:14 -0500
TheGPFguy wrote:
> While we are on the topic of cryptanalysis, which of the books in the
> FAQ list are the best starting point for learning about cryptanalysis
> of real algorithms? Also, I wonder if anyone can recommend a good
> text for brushing up on the necessary math skills? (My discrete
> math is both rusty and [currently] weak.)
Check this out:
http://www.counterpane.com/self-study.html
Take lots of side trips and get your math back up to speed. It's fun!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Solution for file encryption / expiration?
Date: 06 Jun 2000 10:54:33 -0700
Don't bother. It can't be done, and to the extent that you do
succeed, you will be making life hard on your customers, which is not
good business practice.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: "Joeseph Smith" <[EMAIL PROTECTED]>
Subject: Brute forcing for Counterpane's Password Safe
Date: Tue, 06 Jun 2000 18:12:39 GMT
I've been asked to help the executor of the estate
of a fellow who recently died in Florida. The fellow
was techno-savvy enough to use Password Safe
from Counterpane to hold his various account names
and passwords. Unfortunately, he was not real-world
savvy enough to leave a way for his heirs to recover
the data. The executor has tried various obvious
passwords (names of grandchildren, significant dates
and places, etc.), but they have not worked.
Does anyone have a program that does brute
force password guessing for Counterpane's
Password Safe program? Alternatively, does
anyone have the details of the file format and
algorithms so I can write one? Bruce's website
says that it uses Blowfish and that a 2.0 version
would be published with source, but I don't think
the 2.0 version was ever published. Does anyone
have source to it?
Please reply to the list, since I believe the answer
will be generally useful.
Joe
------------------------------
From: [EMAIL PROTECTED] (Rodd Snook)
Subject: Request for review of "secure" storage scheme
Date: 6 Jun 2000 18:16:37 GMT
Hi,
I'm looking for advice on a scheme that I have cooked up for storing
sensitive customer data (i.e. credit-card numbers) in a fairly secure
format in a web-based environment. I'd like to know if there are any
obvious holes in the procedure, what encryption algorithm (asymmetric)
I should use, and whether I will weaken this algorithm by my manipluations.
I know that storage of card numbers is, in general, a bad idea.
However, the storage is provided for the users' convenience and is at
their own discretion.
So, without further ado, here is my plan:
Aim:
To provide for the storage of customer credit-card numbers in the
most secure manner possible.
Premises:
1. No single machine should have sufficient information in permanent
store to recover a customer credit card number
2. No single machine should have unrestricted access to a permanent
store of information that is sufficient, in combination with data
stored on the machine in question, to recover a customer credit card
number.
Storage:
1. The credit card number is supplied by an authenticated customer.
2. The card number is tested for checksum validity.
3. Provided that the number passes the checksum test, the check digit
is removed from the number (since redundancy is a hint to plaintext)
4. The remainder of the card number is converted to a packed format
(e.g. hex encoding of integer or BCD number) and combined with some
padding and length information, in a parseable format(1). For
increased defence against differential cryptanalysys the position of
the card number within the string should be varied randomly.
5. The combined string is encrypted by the web server using a
public-key encryption algorithm, encoded in a printable format
(string) and the result split into two parts.
6. One of the two parts is appended to a customer-supplied
cookie containing other such fragments and returned to the customer.
7. The remaining part is passed to the database for storage with the
customer's other details.
Retrieval:
1. The fragment of encrypted data corresponding to the card number
requested by the customer is retrieved from the cookie.
2. The fragment, together with sufficient information to identify
both the user and the particular card requested is passed to the
database server.
3. The database server concatenates the supplied fragment with the
stored fragment and decrypts the result with the key complementary to
that used for the encryption at point 5 of the previous section.
4. The plain-text card details are returned to the web server.
5. The web server uses the length information to strip the padding,
then calculates the check digit for the card number.
Weaknesses:
1. All data are encrypted with a single public/private key pair.
2. Card details are passed in clear text from the database server to
the web server.
3. Revealing part of the ciphertext in the cookie would allow a
brute-force attack -- provided that the format of the plaintext
string is known to the attacker.
Strengths:
1. The possibility of an attacker making use of some form of
differential crypanalysis is greatly reduced by the random salting
of the plantext (preventing complete knowledge of the plaintext).
(1) The proposed format is:
Bits Data
------------- ---------------------------------------------------
0-15 Starting bit of card number data (never < 32)
16-23 Encoding format of card number (1=BCD,2=long-int)
24-31 Length of card number data in bits
32-BLOCKSIZE card number embedded within random padding
Many thanks in advance for any advice/criticism,
Rodd
([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Some citations
Date: Tue, 06 Jun 2000 10:53:37 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> I think that the following citations may be of some interest,
> because they may presumably not be unanimously accepted by
> us all and hence could trigger some discussions:
>
> Bandwidth expansion is not necessarily either a drawback
> or a strength of a system, merely a feature.
>
> The Kerckhoffs principle is neither a correct description
> of, nor a self-evident prescription for, all secrecy
> design projects.
>
I like it.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cipher design a fading field?
Date: Tue, 06 Jun 2000 10:51:48 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> Well what if one has no way at all to verify whether X is true, and has
> to 'believe' that it is, like in religion? The sheer number of people
> believing something being true (but without any proof) can be a very
> important matter in e.g. politics, but shouldn't play a role in science
> in
> my humble view.
>
> M. K. Shen
In theory, everything basic is science that will ever be discovered is
availablem to be discovered not. Some things take steps of backgroud
development, but they are not necessarily difficult.
Crypto design can be mere making of logic steps like: After defining
hundreds of block ciphers related to base translation block in the time
given to that pursuit, and after seeing how simple stream ciphers can be
made with any base, it does not take much to see how block ciphers and
stream ciphers can be combined in a given algorithm. Even though simple in
minute definition, many are practically, and, at their origination,
insovable for the moment.
Due to the sheer multiplicative nature of algorithm possibilities
involving design parameters, who dares say that anyone, much less me, will
envision them all, nor, much less, be able to attack them all? Yet the
technology to put the algorithms together can be available to anyone who
can assimilate the simple ideas involved.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Tue, 6 Jun 2000 16:41:31 GMT
Mok-Kong Shen wrote:
> "Douglas A. Gwyn" well:
> > Mok-Kong Shen wrote:
> > > The problem is, I guess, that the knowledge can't be perfect and
> > > often leaves much to be desired, e.g. what concerns the resources
> > > of the opponents or certain yet unproved propositions related to
> > > number theory, etc.
> > That's not really an obstacle; a large number of theorems take
> > the form "assuming X, then Y".
> Well what if one has no way at all to verify whether X is true, and has
> to 'believe' that it is, like in religion? ...
I don't understand your argument. "If the enemy can encrypt chosen
plaintexts at will, then system X ..." is a useful theorem whether
or not the enemy actually *does* encrypt chosen plaintexts.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Some citations
Date: Tue, 6 Jun 2000 16:43:07 GMT
Mok-Kong Shen wrote:
> To paraphrase: (1) It doesn't matter if the ciphertext is
> several times as long as the plaintext. (2) One can rely
> on the secrecy (obscurity) of the encryption algorithm
> as a factor contributing to the security of the system.
> So far, there seems to be almost unanimous agreement on
> these (though I didn't expect this).
I don't know on what basis you judge that. Neither one is
correct, according to my own observations.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Tue, 06 Jun 2000 18:31:48 +0000
Mok-Kong Shen wrote:
> Your argument is correct. But it lacks the desired 'concreteness' of
> solution to my problem. Note that I can only assume the frequencies
> of the characters in the language (at best that the frequency values
> assumed are exact) but otherwise I have no additional informations
> (digrams etc. are assumed to be largely destroyed through e.g. a
> simple transposition).
This is not always a safe assumption -- at least not with a simple
transposition. On a layered system of that sort one can often
optimize the transposition and substitution simultaneously. With
larger N (number of overlapped messages) it gets progressively
easier. With a respectably large N you can get a good idea of the
key at each point <without> unwinding the transposition just by
picking the values of k[i] that minimize the number of low-frequency
characters (or, alternatively, give you a best least-squares fit
on the standard frequency of your target plaintext, or even (horrors)
do the <right> statistical test on the distribution). Using these
assumed keys sorted by goodness of fit, you can put together a
string of potential (matched) plaintexts and <then> unwind the
transposition using multiple anagramming, if it's a constant
transposition.
With N=2 I assume even a simple transposition would make it quite
challenging. I'd need to see a demonstration that it affected
national security or my wallet before trying it. I think I'd
start by studying common n-grams of the target plaintext XORed
with itself and using that to guide the transposition attack.
--
Jim Gillogly
Highday, 17 Forelithe S.R. 2000, 18:21
12.19.7.4.17, 10 Caban 20 Zip, Seventh Lord of Night
------------------------------
** 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
******************************
