Cryptography-Digest Digest #532, Volume #11 Tue, 11 Apr 00 23:13:01 EDT
Contents:
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Mok-Kong Shen)
Re: General principles of design (Mok-Kong Shen)
Re: strength of altered vigenere cipher? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Tim Tyler)
Re: General principles of design (Mok-Kong Shen)
Re: Miami Herald article about ATM ripoffs (O. Lay Merkin)
new cipher design idea (Tom St Denis)
Re: Compaq invents more efficient RSA?! (David Hopwood)
Re: Compaq invents more efficient RSA?! (David A Molnar)
Want to be a genius? ([EMAIL PROTECTED])
Re: computer specs, timing and PK Crypto (Steven C. Den Beste)
Re: Encode Book? (Tom St Denis)
Re: GSM A5/1 Encryption ([EMAIL PROTECTED])
Re: new cipher design idea (Tom St Denis)
Introductory Crypto Books (Josh Tompkins)
Re: new Echelon article (Diet NSA)
Re: 2048 Bit Encryption? (Diet NSA)
Re: Compaq invents more efficient RSA?! (David Hopwood)
Re: manual cypher (MCTER) (David Hopwood)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Wed, 12 Apr 2000 01:08:34 +0200
Gadi Guy wrote:
>
> I'm not sure whether my problem is with inverting the matrix
> or simply with creating an invertable matrix. I find that
> the simple, pivoting Gauss elimination algorithm I copied from
> "Numerical Recipes" fails every time.
>
> It creates 0's in the diagonal and then goes berserk.
>
> MacKay says: "Such a random sparse matrix is not necessarily
> invertable, but there is a probability (for large N) of about
> 0.29 that it is." [Good codes based on very sparse matrices,
> MacKay and Neal]. For large N, it becomes increasingly expensive
> to generate matrices and eliminate them.
>
> My algorithm fails miserably most of the time, which lead me to
> believe that maybe there's something more to inverting boolean
> matrices than they teach in numerical analysis.
Perhaps I am over cautious. But I do want to avoid a probable
language ambiguity. A Boolean matrix is not identical to (though
has the same form as) an integer matrix whose elements are either
0 and 1. One uses Boolean arithmetics, e.g. 1 + 1 = 0. A normal
library Gaussian elimination subroutine, such as the one in
Numerical Recipes, is hence not applicable to a Boolean matrix.
I can't give concrete reasons, but I intuitively believe that
the probability of your having a singular (non-invertible) sparse
Boolean matrix is fairly high, much higher than in case of normal
matrices with integer or real-valued elements.
If your problem is not inverting a Boolean matrix but inverting
a sparse integer matrix whose elements happen to be 0's and 1's,
then I would say that the probability of being singular is also
high (somewhat lower than in the Boolean case, I guess). But here
you can't use the subroutine from Numerical Recipes, since that
employs real arithmetics and hence has rounding errors. You have
to use a version employing integer arithmetics. But then with the
'normal' Gaussian elimination you would very likely get overflow
even with very small dimension of the matrix. With some appropriate
techniques you could handle larger matrices without overflow, but
only to some fairly limited extent. It is then totally out of the
question for matrices of the dimension you gave in your original
post.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: General principles of design
Date: Wed, 12 Apr 2000 01:08:27 +0200
almis wrote:
>
> Hmmmmm..... OK
>
> However; your concept seems to be in conflict with a cryptographic
> maxim that states (something like) '...That which cannot be hidden deeply,
> should not be hidden at all...'
Probably you mean that an algorithm is assumed to be 'known' to the
opponent. But the general construction may be known to him, the
details may be variable, i.e. parametrized and hence dependent
on the key, and hence not exactly known to him. One example is
key-dependent S-boxes. He knows the number of the S-Boxes used
in the algorithm and where are they situated, but he is ignorant
of their contents. There are many other possibilities of variations
which we could later have opportunity to discuss in more details.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: strength of altered vigenere cipher?
Date: Wed, 12 Apr 2000 01:08:46 +0200
Paul Koning wrote:
>
> For Vigenere, or the mixed alphabet variant you suggest, for each
> position in the plaintext each plaintext letter maps to a single
> ciphertext letter. With Jefferson's device, for each 36 plaintext
> letters (if you use the 36 disk version) you get a choice of
> 25 different ciphertexts. If you always pick, say, the row two
> steps away from the plaintext, you have an ordinary polyalphabetic
> substitution of period 36. If you go one row away each time you
> do 36 letters, you have a cipher of period 25 * 36. And if you
> select your cipher row randomly each time, you have a non-periodic
> cipher. That last one is likely to make an attacker's job
> rather painful...
Maybe I am wrong. But I look at it this way: For a particular
character position of the message, i.e. for a particular disk,
if I use the row one step away, I have a substitution, if I use
the row two steps away I have another substitution, etc. All these
form a set. (Note that these form a Vigenere table.) For another
character position I have another set. Now suppose I choose to use
the rows two steps away for encryption. This means I choose the
corresponding substitutions from each of the these sets. And these
constitute my polyalphabetic substitution table for encrypting
36 characters. If I choose to use the rows three steps away for
encrypting the next 36 characters, I'll have another polyalphabetic
substitution table, which may however be obtained from the
previous one through shifting. Yes, the effective number of columns
of the substitution table used for encrypting the whole message
is much greater than 36. But if you consider the choice of the
'steps' as belonging to the key in some sense, you do have a normal
(though large) polyalphabetic substitution in my humble view.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Wed, 12 Apr 2000 01:08:41 +0200
wtshaw wrote:
>
> Playing a good encryption game can mean being highly deceptive. You can
> mix some obscurity into the process, not at all a wrong thing to do.
> After all, in merely picking a passphrase, you try to be obscure and
> deceptive, not mundane and predictable.
Possibly an (to some degree) analogous situation is a comparison
between stategic and tactic decisions in military affairs. I
personally tend to consider the one being at a higher level
than the other and hence needing more intelligence and ingenuity
and the like. Your opponent does not know your password, but
he knows that you use one. That's why I classify such as
technology. But if you somehow cause him to believe something
(a false assertion/statement) long time without knowing it is
false and, if done properly, without ever being able to find out
that you are responsible for that malicious act, that's of a
different quality.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 11 Apr 2000 22:44:23 GMT
Gadi Guy <[EMAIL PROTECTED]> wrote:
: Robert Harley wrote:
:> Gadi Guy <[EMAIL PROTECTED]> writes:
:> > I need to create a large (N = O(10000)) boolean matrix which
:> > has a small number (n = O(3)) of ones in each row, and its inverse.
:>
:> > Real methods (such as Gauss elimination) don't work.
:>
:> Does too.
:>
:> Even if the matrix is dense, a plain Gaussian elimination adapted for
:> booleans should invert your matrix in a few minutes.
: I'm not sure whether my problem is with inverting the matrix
: or simply with creating an invertable matrix. [...]
Calculate the determinant to find out if the matrix you're trying to
invert is singular, and thus has no inverse. This /should/ be a little
bit easier than actually inverting it.
Another simple idea which might help locate the problem
would be to start with a small, simple system, and then work up.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: General principles of design
Date: Wed, 12 Apr 2000 01:16:04 +0200
John Savard wrote:
>
> My web site, I hope, may reveal some of these principles to those who
> study it, even though it mostly illustrates them by examples, instead
> of stating them.
It would be fine, if you would simply provide some key words,
so that we could discuss and elaborate.
My goal is to collect a bunch of clearly delineated (fundamental)
principles that could be useful (though not necessarily used)
in guiding the design of an encryption algorithm.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (O. Lay Merkin)
Subject: Re: Miami Herald article about ATM ripoffs
Date: Tue, 11 Apr 2000 23:38:52 GMT
[EMAIL PROTECTED] wrote:
>It could be worse, yesterday's paper had an article on digital
>signatures. The low point was a paragraph on public key cryptography,
>which uses two keys, a private and a public one. Messages encrypted
>with any private key can only be decrytped with a public one.
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Which is accidentally true..
One example would be a PGP signed message. The writer encrypts a hash of
his message with his private key, and the reader verifies it by decrypting
that hash with the writer's public key. In this sense the hash itself would
be regarded as the "message".
However, it's clear that the news reporter didn't have a full grasp of his
material. As you said, it's accidently true.
--
"O. Lay Merkin" is actually 4875 923106 <[EMAIL PROTECTED]>.
0 123 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: new cipher design idea
Date: Tue, 11 Apr 2000 23:39:32 GMT
For anyone who has seen my hash idea on poly.perms, I have switched it
around to be a 128-bit block cipher. You can check it out at
http://24.42.86.123/cipher.c
It's kinda cool since it's essentially the same algorithm as the hash.
Like the hash it can be switched into a larger/smaller block size easily
[at a cost of speed as you get larger....].
Just more ideas. If anyone has comments on that or the hash
[http://24.42.86.123/hash.c] please let me (the ng) know :)
Spark up some productive conversation...
Tom
------------------------------
Date: Wed, 12 Apr 2000 00:08:54 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Compaq invents more efficient RSA?!
=====BEGIN PGP SIGNED MESSAGE=====
Felix von Leitner wrote:
> Compaq claims a major breakthrough in cryptography by inventing an RSA
> variant called MultiPrimes that uses more than one prime factor for the
> secret key. The white paper is at
>
> http://www.tandem.com/brfs_wps/esscpttb/esscpttb.htm
>
> Does anyone care to comment on this?
That's not a new idea; IIRC it has been proposed on this group at least
twice independently.
There are lots of RSA variants that improve efficiency; the main reason
they're not used very often is that if you're going to use an IF-based
cryptosystem, compatibility with RSA is typically more important than
minor efficiency improvements (or even security improvements; for
example several IF-based schemes are provably as secure as factoring,
but most people still use RSA, for which there is no such proof).
FWIW, here's an RSA variant that is more efficient than MultiPrimes
(because it only requires one exponentiation):
Let p be a prime of about 300 bits (enough to resist ECM factoring)
Let q be a prime of about 700 bits (enough to ensure that n = pq cannot
be factored by general methods)
Let e = 65537 be the public exponent (smaller exponents are not a good
idea for this variant)
Let d = e^-1 mod p-1
(n, e, bitlength(p)) is the public key; (p, d) is the private key.
To encrypt, first apply OAEP padding (modified to create a block of
length bitlength(p)) to the plaintext to get M. The ciphertext is
C = M^e mod n.
To decrypt, recover M = C^d mod p, and unpad according to OAEP.
This reduces the length of data that can be encrypted in a block to
the length of p, but 300 bits is plenty for a symmetric cipher key
in a hybrid system (or for both cipher and MAC keys, if you want to
make the scheme non-malleable over the whole plaintext, in a similar
way to DHAES). It requires at least 3 times less hardware resources
for decryption than MultiPrimes, or is at least 3 times faster on
a single processor.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOPOwWTkCAxeYt5gVAQGPrgf/cMnVUJnaQPH2D3uHbkMpj+FBddYLmwFv
C9xCMddPWTCWal3XvDlo8m2vHaXYL57xHVQj4L8Zq3vf5RwmwChOK+u/jBbqaU3Q
D18yJwiKs2FBlh+Fb0L4L03lTiZTe39twa7wMNoeh24Z/BLlBZq9nMUQz6Kr2lwx
3yw+O74ribQzrckXneVa31SgXVsH+1a7JG7T1+ifvovds4+ypm+9jiU7uJlGWtaE
wm0knRGa9QkGUPuwmO7MsBwNJp0szr+mNEaR1VUqqivlTV/xMmns0Ya5eR5VYWrZ
DrHuLRXx69jZLs/6fKS9+GZMC0uYDHgXSj9eAlhhFUDA3Qk3iSnnng==
=fqhO
=====END PGP SIGNATURE=====
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Compaq invents more efficient RSA?!
Date: 12 Apr 2000 00:06:50 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> FWIW, here's an RSA variant that is more efficient than MultiPrimes
> (because it only requires one exponentiation):
This looks similar to Shamir's "RSA for Paranoids", for whatever that's
worth. The use of OAEP should protect you against the kind of attacks
given in
H. Gilbert, D. Gupta, A. M. Odlyzko, and J.-J. Quisquater: Attacks on
Shamir's 'RSA for paranoids'. In Information Processing Letters 68,
pp. 197-199, 1998
http://www.research.att.com/~amo/doc/rsa.for.paranoids.pdf
which you may want to look at if you don't already know it.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Want to be a genius?
Date: Wed, 12 Apr 2000 00:34:41 GMT
http://www.Great-Mind.com Knowledge Portal Bringing brilliant minds
together, creating an organized structure and environment for knowledge
resources in one centralized portal, for individuals and groups to
converse, debate, develop and share. By this, we are able to assist in
the expedition of progress and the location of real knowledge.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steven C. Den Beste)
Subject: Re: computer specs, timing and PK Crypto
Date: Wed, 12 Apr 2000 00:49:27 GMT
I heard a rumor that Tom St Denis posted this:
>So my idea of hightech computers was off, I admit I was wrong, but
>computers with the required memory still don't exist. So my point is
>half-way valid.
>
>One of my concerns is still valid, for these computers to work at high
>speeds their bus length [physical size, etc] has to be relatively small
>otherwise you get noise? Like why xDSL is not available for some phone
>users...
Noise is actually not the issue; if you're concerned about noise, you just
use more voltage. However, wider voltage swings are slower (because it takes
longer for the junctions to charge or uncharge).
Crosstalk (which is distinct from noise) is a bit more of a problem, but not
really all that big a deal. To defeat crosstalk you can use differential
drive or simply be intelligent about board layout.
The actual reason for making computers small is a little thing called the
"speed of light". Signals propagate through a wire at about 85% of C. It
turns out that the speed of light really isn't as fast as you might think,
given the kinds of time intervals we're talking about in modern computers.
Grace Hopper used to give away "nanoseconds" at her lectures; a nanosecond
is a piece of wire a bit over ten inches long.
Another reason is that at these kinds of frequencies, the combined
resistance and inductance and capacitance of a long run is sufficient that
it will act to some extent as a low-pass filter; it's harder to maintain
signal integrity on long runs. (On a short run the values are lower and it
is less of a problem.)
I might mention that at these kinds of frequencies, all paths have to be
waveguides; you're not doing wiring, you're doing plumbing. You don't put
sharp corners on the runs, for instance, because they'll reflect and cause
standing waves. It's also necessary to match path-lengths on multi-line
busses so as to not induce phase differences, and there are other things to
concern yourself with too. Gigahz+ frequencies are a real bitch.
========
Steven C. Den Beste [EMAIL PROTECTED]
Home page: http://home.san.rr.com/denbeste
CDMA FAQ: http://home.san.rr.com/denbeste/cdmafaq.html
"I'm a 21st century kid trapped in a 19th century family"
-- Calvin
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encode Book?
Date: Wed, 12 Apr 2000 01:03:29 GMT
lordcow77 wrote:
>
> In article <[EMAIL PROTECTED]>, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
> >
> >You try teaching pascal to a 12 year old, and tell me that.
> >
>
> Every time I read one of your posts, I remind myself how
> wonderful it is that I don't teach middle school or high school
> students. The number of people who learned a computer
> programming language at age 12 is greater than the number of
> people who are capable of designing a public key based on matrix
> multiplication and elementary number and then *breaking it* at
> any age, but even moreso for 12 year olds. Pascal is not
> difficult to learn; neither is C, C++, Java, Scheme, Ada, LISP,
> or any other modern general programing language. What *is*
> difficult is computer science: the art of applying general
> knowledge to a specific situation and integrating different
> pieces of information into a coherent and elegant whole.
I forgot I was in the presence of a genius.
How about we call a draw to this shirk[*] fest. I personally don't care
to argue this anymore.
Most 12 year olds I know couldn't learn a programming language. I am
not claiming to be a genius or anything, just someone who applies a
little knowledge once in a while.
Tom
[*] shirk is referred to in Dilbert as a type of peer-to-peer flamewar.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: GSM A5/1 Encryption
Date: Wed, 12 Apr 2000 00:56:03 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > ...
> > I would like your opinion as to what you think is a suitable (
"strong")
> > stream cipher for something like a GSM crypto system. As I said in
my
> > previous post, one Euro company has developed a strong GSM crypto
> > phone..but they are using a block cipher for some strange
> > reason ( the only reason I can think of is that they are
> > using a crypto core which has an embeded symmetric
algo)...interested in
> > your comments....
>
> Why does it have to be a stream cipher?
>
> Anyway, any block cipher can be turned into a stream cipher, that's
> elementary stuff. So pick a good block cipher: 3des, idea, cast,
> etc.
This is tooo slow for GSM...yes any Block cipher can be turned into a
stream cipher using CFB for sure....tooo slow...GSM is real time voice
encryption,
and its better to use a stream cipher for performance reasons...
>
> Alternatively, pick a stream cipher with a good reputation, such
> as RC-4.
>
> The way I look at this: one of the first things any good student of
> crypto learns is that he isn't qualified to design a good cipher,
> and won't be for many years if ever. Clearly, no good students of
> crypto were involved in the A5 process, because they flunked that
> test...
I dont think that is the case. Read David Wagner's threads here. I
think the designers of A5 new exactly what they were doing...and the
they were surely no students of crypto...
> (They also never heard of the Kerckhoff criteria, apparently...)
>
> paul
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: new cipher design idea
Date: Wed, 12 Apr 2000 01:13:18 GMT
First cryptanalysis of the cipher...
The whitening keys are completely non-random when your key is under 256
bits.... that's a bad idea.
Ideas to fix it? Maybe generate 8 extra round keys for the whitening
keys? Hmm..
Tom
Tom St Denis wrote:
>
> For anyone who has seen my hash idea on poly.perms, I have switched it
> around to be a 128-bit block cipher. You can check it out at
>
> http://24.42.86.123/cipher.c
>
> It's kinda cool since it's essentially the same algorithm as the hash.
> Like the hash it can be switched into a larger/smaller block size easily
> [at a cost of speed as you get larger....].
>
> Just more ideas. If anyone has comments on that or the hash
> [http://24.42.86.123/hash.c] please let me (the ng) know :)
>
> Spark up some productive conversation...
>
> Tom
------------------------------
Subject: Introductory Crypto Books
From: [EMAIL PROTECTED] (Josh Tompkins)
Date: Wed, 12 Apr 2000 02:20:15 GMT
Hello, everyone.
Before I begin, I KNOW that this is a newbie question. Please don't flame
me.
I just finished reading "Cryptonomicron" (or however you spell it) by Neal
Stephenson. The book re-sparked an interest in crypto I've had for a
while, so now I'm looking for some source material.
I've almost finished reading "The Code Book" by that guy who wrote
"Fermat's Enigma" (can't remember his name right now), and I've got Applied
Crypto. What's your opinion on these books?
Do you have any other suggestions? I've in a position to purchase books
right now (as opposed to limiting myself to websites), so any hardcopy
recommendations?
Thanks,
Josue
________________________________________________________________
"Destined For Great Things -- but pacing myself."
- From a t-shirt.
E-Mail: [EMAIL PROTECTED]
ICQ: 21219667
AIM: JosueTheGreat
Web: http://www.crosswinds.net/~josht
_________________________________________________________________
------------------------------
Subject: Re: new Echelon article
From: Diet NSA <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto
Date: Tue, 11 Apr 2000 19:28:39 -0700
In article <8cu4kl$foq$[EMAIL PROTECTED]>
, [EMAIL PROTECTED] wrote:
Mr Tenet has done a wonderful job
protecting the interest's and
>security of the United States of America! Every American should
be
>respectful to his accomplishments. Sincerely, TCMCOMSPECUSA1
>
>
We don't have the info needed to fairly
assess what kind of job Mr. Tenet (the
DCI) is doing. Only the NSC and certain
politicians (including the President) have
access to this info. Anyways, Clinton is
probably more interested in evaluating
the "performance" of interns than of intel
directors.
I toy with Big Brother, yet He does not share His toys with me :-(
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: 2048 Bit Encryption?
From: Diet NSA <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Date: Tue, 11 Apr 2000 19:34:46 -0700
In article <
8cu53g$gb3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>> Is this site great or what? I love it! TCMCOMSPECUSA1
>
>
What site? From where I am, deja.com
sucks for newsgroups and only works
about half the times I try to use it (it
could be too much traffic & the local
server).
I toy with Big Brother, yet He does not share His toys with me :-(
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Wed, 12 Apr 2000 00:53:41 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Compaq invents more efficient RSA?!
=====BEGIN PGP SIGNED MESSAGE=====
David Hopwood wrote:
> FWIW, here's an RSA variant that is more efficient than MultiPrimes
> (because it only requires one exponentiation):
[...]
> To encrypt, first apply OAEP padding (modified to create a block of
> length bitlength(p)) to the plaintext to get M. The ciphertext is
> C = M^e mod n.
That should be "(modified to create a block of length bitlength(p)-1)"
(as opposed to bitlength(n)-1).
Also note that, analogously to normal OAEP, if the decrypted plaintext
is >= p, the message is considered invalid.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOPO60jkCAxeYt5gVAQGAQwf6AkNQqnh3LriX2z/Tu/SWc0nupJumfcTO
K7WlUIpm7PvhTlOMa0mDpaYxuze0Z7Cu5rSjpA6Alxb5aMUZy76ZrDEUof1lw7Q9
/R8s7tlbUyH8679Rz+XqG1KdfkCFmW1yZwWB7muevPh1uI28VhURdl+KUuqcK9i5
Zj9SqKq9ujbcZZAi/GTDWbQGzxFi83RhSetmjvzcAaTxV0Cl9cqmVdY8lM3he3fP
TWENtj2yINdwxOe6UZyU3v9cCVH8Tp1BhS7DbMhcpMI/WFhfpRvcLN2hQEBQ5706
VQW6VTqLt9GQiJcT+2vh/ImUe1vo2Pcz2J97ryW+0QljCviPUvCZXw==
=19H1
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 12 Apr 2000 01:14:20 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: manual cypher (MCTER)
=====BEGIN PGP SIGNED MESSAGE=====
Jacques Th=E9riault wrote:
[cipher description snipped]
An obvious weakness of this is that for plaintexts requiring
more than one block (> 52 characters), the state of CRPT after
the first block is completely determined by the keystream
used for the first block. I.e. a known plaintext attack can
break every block after the first easily.
Even for a single block, the hash applied to the CRPT array
(i.e. the loop over k) seems to be quite weak. In particular,
the three lookups used to get c3 aren't a good way to obtain
an unbiased value - consider what happens when the first
character of CRPT is 'A', for example.
I don't have enough time to spend on this to break it, but I'm
pretty sure it is easily breakable.
- -- =
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOPO/tzkCAxeYt5gVAQEKpAgAxgehQnMVI4s4Wkh3eB0JI5J4CkAGKkrg
BMbSnqcVlkSlfqDQpfqNRUNIdtdWMxIbvfIfH/omrg9M0yexCWeJ4y0Rcgge7v6+
IUXsVtJz9L4hJK7IMbzRaXcPRY5wfPPsOtMtjXh4FEoNhsXDPEsab4EMdQ+OdI6i
xb2DJnkgI1kWEYy63ZKuwKUEUc6cPX59L4kHXYTpYVZCU5+OOjX1/uOq6pgvySzn
DBr7ANDUhEoqcFAxndNmvSPn6ptUcUVFgpNxO6jWmOv8V58FAmPWe3Z2ohUEbt7o
8OcMiiMRPk+FOw1Xl1ywXcJQdSqGxScuo9bybufp0cOqwnCFSzVeWQ=3D=3D
=3DmSn7
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
