Cryptography-Digest Digest #531, Volume #11 Tue, 11 Apr 00 23:13:01 EDT
Contents:
Re: Skipjack algorithm. (CLSV)
Re: Equivalent permutation polynomials (Tom St Denis)
Re: Q: Entropy (Bryan Olson)
General principles of design (Mok-Kong Shen)
Re: Equivalent permutation polynomials (James Felling)
Re: Q: Entropy (Bryan Olson)
Re: Examples of topology related to crypto ? (Diet NSA)
Re: Q: Entropy ("Trevor L. Jackson, III")
Re: Compaq invents more efficient RSA?! ("Michael Scott")
Re: Compaq invents more efficient RSA?! (David A Molnar)
Re: Encode Book? (Paul Rubin)
Re: Equivalent permutation polynomials ("Douglas A. Gwyn")
Re: strength of altered vigenere cipher? (Paul Koning)
Re: General principles of design ("almis")
Re: Processing encrypted data (David Hopwood)
Re: Quantum Teleportation (Darren New)
Re: Encode Book? (Tom St Denis)
Re: DES (Jim Gillogly)
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Jerry Coffin)
Re: General principles of design (John Savard)
Re: General principles of design (John Savard)
Re: Looking for crypto short course or workshop (Paul Koning)
ENCRYPTION DEVELOPMENTS AND MARKKU'S COMMENTS ([EMAIL PROTECTED])
Re: Encode Book? (lordcow77)
Twofish problems... (JONATHAN DINERSTEIN)
----------------------------------------------------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Skipjack algorithm.
Date: Tue, 11 Apr 2000 21:35:53 +0200
"Brian K. Ogilvie" wrote:
> [EMAIL PROTECTED] (John Savard) writes:
> > I remember Bruce Schneier saying that attempting to extend the length
> > of its keys would be unsafe.
> Certainly the work of Biham, Biryukov, and Shamir on "Cryptanalysis of
> Skipjack Reduced to 31 Rounds using Impossible Differentials" would
> lead one to believe that the full Skipjack cipher has only 80-bits of
> strength and the key size and algorithm strength were "balanced" by
> NSA in its design. Their work shows clearly that Skipjack does not
> have a large overdesign safety margin and gives 80-bit strength with
> 80-bit keys.
This is what I mean. Maybe I was dreaming about an official
statement being made about weakening the algorithm by
extending the key length. However I still think that such
a (secret?) design criterium exists among a few others.
Regards,
CLSV
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Equivalent permutation polynomials
Date: Tue, 11 Apr 2000 19:37:04 GMT
"Douglas A. Gwyn" wrote:
>
> Tom St Denis wrote:
> > F(x) = 0 + 3x + 5x^2 + 0x^3 + 7x^4 + 0x^5 [mod 16]
> > F(x) = 0 + 11x + 13x^2 + 0x^3 + 7x^4 + 0x^5 [mod 16]
> > Now for you math gurus this is probably a joke, but why are these two
> > polynomials congruent?
> > BTW: they both create [0, 15, 10, 13, 12, 3, 6, 1, 8, 7, 2, 5, 4, 11,
> > 14, 9] as the output [when stepping from F(0)..F(15)].
>
> Call the second one G(x).
> Consider D(x) = G(x)-F(x) = 8x(1+x) [mod 16].
> D(i+1) = D(i) + 16(i+1) = D(i) [mod 16],
> so all D(i) = D(0) = 0. I.e., F(i)=G(i) for all i.
> The key is that that the coefficients differ by 0 or 8,
> which is half of 16..
> I don't know if there is any deep significance.
So whenever all the coefficients differ by 8 they are congruent? Why is
that?
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Tue, 11 Apr 2000 19:27:44 GMT
Xcott Craver wrote:
> The fact that different machines
> can give different complexity metrics for finite strings
> does not IMHO invalidate talk of Kolmogorov complexity of
> finite strings. One may as well argue that it's meaningless
> to talk of P, NP, or even recursive languages, because
> different machines result in different classifications for
> a single language.
So can you tell me a set of one finite string that's not it
P? How about a finite set of finite strings that's not in
P? You chose an example that does characterize (time)
complexity, but only for _infinite_ objects.
P and NP are language independant. The description of time
complexity by P or NP is not sensitive to additive
constants, multiplicative constants, or even constant
exponents.
How about saying an algorithm is O(n^2)? The notation does
not capture either additive or multiplicative constants, so
it says nothing about the time for a particular finite
input. One cannot use big-O notation to compare performance
on a specific input string. It is only meaningful because n
can grow arbitrarily large.
The language-independent metric of Kolmogorov complexity
ignores additive constants. It's not useful to describe
things that are constants, such as the complexity of a
specific finite string.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: General principles of design
Date: Tue, 11 Apr 2000 21:53:00 +0200
I believe it is interesting if we could have some discussions
on possibly useful general principles of design of encryption
algorithms.
Allow me to begin this thread with a topic that I personally
consider to be important, namely variability, i.e. to let the
opponent who analyzes the design to have as little amount of
'detailed' knowledge of the actual algorithm being used as
possible. To be concrete, let's look at a block cipher with a
number of rounds. Suppose the opponent studying the algorithm
is at the boundary between two rounds and want to procede
further (in one or the other direction, depending on encryption/
decryption). If the cipher is such that the details of the next
round are not 'completely' known to him, then he has evidently
big difficulties. He is forced to do some try and error, i.e.
to guess the unknown features that are somehow determined by
the key, which he unfortunately doesn't have. This state of
affairs clearly leads to sort of combinatory explosion when he
attempts to go through all the rounds, thus contributing to
defeat his analysis attempts. Let me perhaps use an analogy
to illustrate. If I come as a tourist to a big city, say Los
Angeles, and without a map and other aid want to go from one
point to a distant location, then I'll clearly have a
practically unsolvable problem. For at each street crossing
point I'll have to guess which way I should properly take. Since
I have no certain knowledge to guide me to make the choice, the
chance of my reaching the target destination is infinitesimally
small.
Yours comments as well as initiations of discussions on other
general principles of design are sincerely solicited.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Equivalent permutation polynomials
Date: Tue, 11 Apr 2000 14:56:04 -0500
James Felling wrote:
> Tom St Denis wrote:
>
> > I just discovered equivelent permutation polynomials. In my test I use
> > this initial polynomial
> >
> > F1(x) = 0 + 3x + 5x^2 + 0x^3 + 7x^4 + 0x^5 [mod 16]
> >
> > And then I did all the modular inverse of the coefficients [mod 16] to
> > get
> >
> > F2(x) = 0 + 11x + 13x^2 + 0x^3 + 7x^4 + 0x^5 [mod 16]
> >
> > Now for you math gurus this is probably a joke, but why are these two
> > polynomials congruent? I was aiming for something else at the time and
> > found this :)
>
> It is simple why that is the case. ( I renamed them above to allow myself
> to be clear).
>
> F2(x) = F1(x) + P(x) mod 16.
>
> Where P(x) = 8x + 8x^2 = 8(x + x^2)
>
> Since x + x^2 is always even P(x) = 0 mod 16.
>
> >
> >
> > BTW: they both create [0, 15, 10, 13, 12, 3, 6, 1, 8, 7, 2, 5, 4, 11,
> > 14, 9] as the output [when stepping from F(0)..F(15)].
> >
> > Tom
In fact since sign is preserved by exponentiation any P(x)= 8*( polynomial
with an even number of terms) will be equivalent.
Given any composite base B there will always be a set of polynomials Q such
that Q(x)= 0 mod B for any int x. Then given any F(x). F(x) mod B will be
equivalent to F(x) + Q(x) mod B for any and all Q(x) contained in the set Q.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Tue, 11 Apr 2000 19:49:04 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > Given a string of, say, a million zeros and a "random"
> > million-bit string, Kolmogorov complexity does not say which
> > is more complex.
>
> If the shortest program to describe the former is shorter than
> the one for the latter (a case which seems fairly likely), then
> by definition the former has less Kolmogorov complexity than
> than the latter.
Wrong. Kolmogorov complexity allows the program to be
written in a large class of languages. For any pair of
distinct finite strings there's a pair of legal language that
disagree on which string has the shorter program.
Kolmogorov complexity starts to get interesting with the
observation that the same is not true of infinite sequences.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Examples of topology related to crypto ?
From: Diet NSA <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Date: Tue, 11 Apr 2000 13:01:25 -0700
In article <[EMAIL PROTECTED]>, Tim
Tyler <[EMAIL PROTECTED]> wrote:
>I don't know much about any connections between cellular
automata and
>topology, though. Perhaps the most /obvious/ connection
concerns
>automata with differing sorts of boundary conditions - e.g.
toroidial
>ones.
>
In addition to the connections already
mentioned, topology and CA are related
regarding: the periodic orbits of CA, the
topological entropy of CA, and the
consideration of CA as maps on the reals
(or real analysis). I'm certain that others
(perhaps Chris Hillman) know more about
this than I do.
[I used to be "the_nsa@deja" but have
switched to remarq.com]
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: Tue, 11 Apr 2000 16:23:01 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Bryan Olson wrote:
> Xcott Craver wrote:
> > The fact that different machines
> > can give different complexity metrics for finite strings
> > does not IMHO invalidate talk of Kolmogorov complexity of
> > finite strings. One may as well argue that it's meaningless
> > to talk of P, NP, or even recursive languages, because
> > different machines result in different classifications for
> > a single language.
>
> So can you tell me a set of one finite string that's not it
> P? How about a finite set of finite strings that's not in
> P? You chose an example that does characterize (time)
> complexity, but only for _infinite_ objects.
>
> P and NP are language independant. The description of time
> complexity by P or NP is not sensitive to additive
> constants, multiplicative constants, or even constant
> exponents.
>
> How about saying an algorithm is O(n^2)? The notation does
> not capture either additive or multiplicative constants, so
> it says nothing about the time for a particular finite
> input. One cannot use big-O notation to compare performance
> on a specific input string. It is only meaningful because n
> can grow arbitrarily large.
>
> The language-independent metric of Kolmogorov complexity
> ignores additive constants. It's not useful to describe
> things that are constants, such as the complexity of a
> specific finite string.
Given the above, is there any context in which it is meaningful to distinguish
an infinite string (or an infinite collection of finite strings) from the
source of the string(s)?
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Compaq invents more efficient RSA?!
Date: Tue, 11 Apr 2000 21:28:40 +0100
Good God they have some nerve patenting the idea.
I came across the idea first as an end-of-chapter example in a crypto book
about 10 years ago. In our own RSA example source code (which hasn't changed
in many years) there is a
#define NP 2
statement at the top which allows the RSA method to be trivially generalised
to more than 2 primes
Mike Scott
=====================
Fastest is best.
MIRACL multiprecision C/C++ library for big number cryptography
http://indigo.ie/~mscott
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Compaq invents more efficient RSA?!
Date: 11 Apr 2000 20:26:07 GMT
Felix von Leitner <[EMAIL PROTECTED]> 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?
I have a vague feeling that the idea of using multiple prime factors in
the secret key is almost as old as RSA itself. At least, chinese
remaindering methods to speed up decryption seemed to appear early; the
generalization to multiple smaller factors seems natural.
Most recent work along these lines that I know of is due to Takagi in
CRYPTO '98 and is on "A Fast RSA-Type Cryptosystem with p^2 q" . This
repeats a factor in order to get a speedup; no idea if this is what
Compaq does or not.
oh, and also Boneh, Durfee, and Howgarave-Graham's paper on
"Factoring Moduli of the form p^r q for Large r", which suggests that
you must be very careful with repeating such prime factors. Unfortunately
their result doesn't seem to say much about the p^2 r case.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Encode Book?
Date: 11 Apr 2000 20:46:25 GMT
In article <[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>> Come to think of it I haven't seen anything here on the ng lately
>> by Shamir, Knudsen, Simmons, etc. etc. either. You just aren't looking
>> in the right places.
>
>Adi Shamir did Twinkle did he not? Knudsen did Serpent [with Biham
>et al] and some other papers related to AES and I have never heard of
>Simmons
>
>Tell me again they haven't done anything lately?
I'm saying none of them have been personally posting to the ng. Of course
other people have posted stuff about their work. The same is true of Flannery.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Equivalent permutation polynomials
Date: Tue, 11 Apr 2000 20:19:15 GMT
Tom St Denis wrote:
> So whenever all the coefficients differ by 8 they are congruent?
No, I didn't say that. If you examine the proof I gave for
your specific polynomials, you should see that 8 being half
of 16 was the key that made it work out as it did.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: strength of altered vigenere cipher?
Date: Tue, 11 Apr 2000 16:54:29 -0400
Mok-Kong Shen wrote:
>
> Paul Koning wrote:
> >
> > Mok-Kong Shen wrote:
>
> > > The strength question has been answered by others. I just want
> > > to say that, if you want to use polyalphabetic substitution,
> > > then don't use Vigenere with all alphabets being shifted versions
> > > of one another but use so-called independent alphabets (i.e.
> > > the the characters of the alphabets are randomly ordered) and
> > > long keys.
> >
> > That will only help a little. As soon as I get enough ciphertext,
> > I can determine the period (key length) and at that point the
> > problem reduces to that many simple substitution ciphers. If the
> > key length is less than 3% or so of the message length, you're
> > in trouble...
>
> It depends upon how many alphabets you have and whether you can
> get actually 'enough' ciphertext that you need.
Yes, that's what I said.
> > An interesting approach is to use Tom Jefferson's cipher device
> > instead, picking a different row each time. (See Kahn for a
> > description. Nice widget...)
>
> This is in fact a polyalphabetic substitution.
Yes, but with a difference.
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...
paul
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Re: General principles of design
Date: Tue, 11 Apr 2000 16:01:12 -0500
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...'
...al
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I believe it is interesting if we could have some discussions
> on possibly useful general principles of design of encryption
> algorithms.
>
> Allow me to begin this thread with a topic that I personally
> consider to be important, namely variability, i.e. to let the
> opponent who analyzes the design to have as little amount of
> 'detailed' knowledge of the actual algorithm being used as
> possible. To be concrete, let's look at a block cipher with a
> number of rounds. Suppose the opponent studying the algorithm
> is at the boundary between two rounds and want to procede
> further (in one or the other direction, depending on encryption/
> decryption). If the cipher is such that the details of the next
> round are not 'completely' known to him, then he has evidently
> big difficulties. He is forced to do some try and error, i.e.
> to guess the unknown features that are somehow determined by
> the key, which he unfortunately doesn't have. This state of
> affairs clearly leads to sort of combinatory explosion when he
> attempts to go through all the rounds, thus contributing to
> defeat his analysis attempts. Let me perhaps use an analogy
> to illustrate. If I come as a tourist to a big city, say Los
> Angeles, and without a map and other aid want to go from one
> point to a distant location, then I'll clearly have a
> practically unsolvable problem. For at each street crossing
> point I'll have to guess which way I should properly take. Since
> I have no certain knowledge to guide me to make the choice, the
> chance of my reaching the target destination is infinitesimally
> small.
>
> Yours comments as well as initiations of discussions on other
> general principles of design are sincerely solicited.
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
Date: Tue, 11 Apr 2000 21:23:44 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Processing encrypted data
=====BEGIN PGP SIGNED MESSAGE=====
zapzing wrote:
[...]
> Could this sort of scheme be used to, say, write an encryption program
> such that the encrypting machine itself has no idea what it is
> encrypting?
That's relatively easy (if you only require that the encryption machine
be the holder of the private key, rather than that it performs the whole
process).
The machine can just generate a random session key (for a symmetric
cipher) encrypted with its private key. You encrypt the message with
the session key, and include the encrypted session key with the
ciphertext. Note that this will work whether the machine's private key
is for a symmetric or public key cipher.
- --
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
iQEVAwUBOPLMRzkCAxeYt5gVAQEC1Af6A5e14xg5lxgJPpkKAcfo5aBK7vPYfI3S
pTFEUnymPtQJTqKv+AVYQ/8EvJkPyLOuORjrB8Y7UsWVIL3mufTMjRJZ9tNRcZQc
tax0afnpmeE8tPknmqAzrCMJzjOoSRWqT5dBMnp4pjuNhDtnfUAhLSSRyt1i3bkg
KEibVImZrUSV2f8De8D7lJOOtp2vtfgibauNi6V95qF2LAvpzJU8COJbIKZh2oy6
9y48JAPsBJ162IsEaA6LoEWTis60RX4wS3abf/eNAKBOS9RLOjEfyZvCZZcHu9GR
eg+vxTBxApp8VUMzH6AXohShRskEMHk+UgguOM1HtVdfVT6hg037ZQ==
=KK8V
=====END PGP SIGNATURE=====
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Quantum Teleportation
Date: Tue, 11 Apr 2000 21:03:25 GMT
Doug Goncz wrote:
> The genetic code of all living things is "sort of" transmitted without
> knowledge.
Or, as Laurie Anderson says, "They [sperm] have no eyes, they have no ears,
yet some of them already know they will be bald." :-)
(From USA Live, in case you're interested. A great album.)
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Everybody is unique:
that's why we all have different numbers.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encode Book?
Date: Tue, 11 Apr 2000 21:24:51 GMT
lordcow77 wrote:
>
> In article <[EMAIL PROTECTED]>, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
> >> In any case, I doubt I could create a fast new public-key
> algorithm
> >> right now. I *know* I could not have done it at her age. It
> remains an
> >> impressive acheivement.
> >
> >So what, I tought myself Pascal when I was 12, big deal. It's
> nice to
> >know she understands it enough to break her own algorithm
> though.
> >
>
> Teaching yourself Pascal is not a big deal. Inventing a new
> public key cryptosystem that is at least plausibly difficult to
> break and then attacking it yourself at her age is a big deal.
> If you don't realize this, I'm afraid that it wouldn't be
> productive to explain this any further.
You try teaching pascal to a 12 year old, and tell me that.
Tom
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Tue, 11 Apr 2000 21:37:14 +0000
"Douglas A. Gwyn" wrote:
>
> Jim Gillogly wrote:
> > Also possible is "practical cryptanalysis", which of course exposes you
> > to greater risks if it's an unauthorized activity.
>
> Since the fellow's a newbie, he probably doesn't understand that
> term. "Practical cryptanalysis" involves approaches other than
> analytic, e.g. looking for passwords on Post-It notes on an
> administrator's console, etc.
Roger. The above attack falls into the traditional subcategory of
practical cryptanalysis known as "black-bag cryptanalysis". Other
specialties include wiretaps, "fat checkbook cryptanalysis", "rubber
hose cryptanalysis", and "svelte blonde cryptanalysis".
--
Jim Gillogly
Highday, 21 Astron S.R. 2000, 21:32
12.19.7.2.1, 6 Imix 4 Pop, Fifth Lord of Night
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Tue, 11 Apr 2000 16:46:52 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> 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.
That's not at all surprising -- Numerical Recipes is quite well known
for presenting algorithms that don't work well. I don't recall
anything about its matrix inversion code in particular, but it
definitely presents a number of algorithms that are NOT at all
stable; about all they're really good for is demonstrating how
algorithms that might work in theory can break down completely when
implemented in limited precision.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: General principles of design
Date: Tue, 11 Apr 2000 22:05:16 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>I believe it is interesting if we could have some discussions
>on possibly useful general principles of design of encryption
>algorithms.
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.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: General principles of design
Date: Tue, 11 Apr 2000 22:07:44 GMT
"almis" <[EMAIL PROTECTED]> wrote, in part:
>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...'
Well, it's definitely true that you shouldn't transmit messages which
have been encrypted only halfway through your algorithm, but with your
current key.
In other cases, it doesn't hurt to hide everything as deeply as you
can, whether or not it is deep, although if it isn't deep, it also may
not be worth the effort.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Looking for crypto short course or workshop
Date: Tue, 11 Apr 2000 17:05:39 -0400
"Kim J.-H." wrote:
>
> I would like to want to know about crypto short course or workshop to be
> held.
> The topic may be general or specific.
> I am waiting for your guidance.
Alex Biryukov's course is open to Internet participants...
http://www.wisdom.weizmann.ac.il/home/albi/public_html/cryptanalysis/
paul
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: ENCRYPTION DEVELOPMENTS AND MARKKU'S COMMENTS
Date: Tue, 11 Apr 2000 22:20:55 GMT
I JUST ENJOY READING THESE MARKKU'S (MARKKU J. SAARELAINEN) MESSAGES
FROM MARCH, 1999 TO 2000. ONE ASPECT THAT HE SEEMED TO HAVE ADDRESSED
VERY WELL SINCE 1993 AND/OR BEFORE IS CRYPTOGRAPHY AND ENCRYPTION
TECHNOLOGIES. IT IS CLEAR THAT HE UNDERSTOOD THAT THE ACADEMIC
CRYPTHOGRAPHY IS LIGHT YEARS BEHIND THE REAL MILITARY LENGHT
CRYPTOGRAPHY AND ITS VARIOUS APPLICATIONS. I AM POSITIVE THAT THOSE IN
THE MILITARY INTELLIGENCE COMMUNITY KNOW THIS VERY WELL. MANY SECRET
SERVICES CONTROL MANY BRILLIANT MATHEMATICIANS. IT DOES APPEAR THAT
MARKKU HAD (AND MOST LIKELY STILL HAS) A GIFT FOR MATHEMATICS. IN ONE
POSTING I READ THAT HE RECEIVED A SMALL AMOUNT OF FUNDS IN HIS TEEN
FROM THE LIONS CLUB TO CONTINUE HIS MATHEMATICAL INTERESTS. AS I
UNDERSTAND THIS LIONS CLUB IS A GLOBAL MULTI-FACETED BUSINESS CLUB TO
SERVE PEOPLE. WHAT ELSE CAN I FIND ABOUT MARKKU AND HIS INTERESTS IN
1990'S ON THE INTERNET?
BRIVET,
VLADIMIR
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Encode Book?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Tue, 11 Apr 2000 15:26:43 -0700
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.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (JONATHAN DINERSTEIN)
Subject: Twofish problems...
Date: 11 Apr 00 16:23:31 MDT
Can somebody help out a struggling college student???
I'm working with Twofish, and I'm checking my results as compared to the
standard test ones on the Twofish webpage
(http://www.counterpane.com/ecb_ival.txt). I am using ECB mode to match the
test vector, and I get the same S-box keys. What's wrong is I get completely
different Subkeys. I therefore also get different cipher-text. However, I am
able to correctly decrypt what I encrypt.
Does anyone have any suggestions or advice? Is there a known issue? I'm using
the CryptPak Twofish implementation (modified to be ECB).
Thanks in advance!
Jonathan Dinerstein
[EMAIL PROTECTED]
------------------------------
** 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
******************************
