Cryptography-Digest Digest #520, Volume #13 Mon, 22 Jan 01 02:13:01 EST
Contents:
Re: cryptographic tourism in Russia (stanislav shalunov)
Re: Where can I find software tools for Known-text decryption (Bob Silverman)
Re: KASUMI Analysis? (Was: Re: 3G crypto algorithms) (David Wagner)
Re: Comparison of ECDLP vs. DLP (David Wagner)
Re: JPEG infidelity for crypto (wtshaw)
Re: JPEG infidelity for crypto (wtshaw)
Re: using AES finalists in series? ("Douglas A. Gwyn")
Re: Transposition code (Richard Heathfield)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Re: Transposition code (John Savard)
Re: cryptographic tourism in Russia (Steve Roberts)
Re: using AES finalists in series? (Bryan Olson)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
----------------------------------------------------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: cryptographic tourism in Russia
Date: 21 Jan 2001 22:48:24 -0500
Dido Sevilla <[EMAIL PROTECTED]> writes:
> The US Government will not even let you visit the NSA; it's even more
> doubtful that the Russian Government will allow you to visit GOST.
"NSA"? GOST is "GOsudarstvennyj STandart" (State Standard), and its
anologue in the U.S. would be ANSI, not NSA.
--
Stanislav Shalunov <[EMAIL PROTECTED]> Internet Engineer, Internet2
I never let school stand in the way of my education. -- Mark Twain
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Where can I find software tools for Known-text decryption
Date: Mon, 22 Jan 2001 03:41:17 GMT
In article <946lft$tgq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> It is my understanding that when you know some of the test in a file,
> the rest of the file can be decrypted.
Sorry, but no. It can't.
--
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/
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: KASUMI Analysis? (Was: Re: 3G crypto algorithms)
Date: 22 Jan 2001 03:57:24 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Sam Simpson wrote:
>Has anyone had a look at KASUMI, the 'new' block cipher to be used with
>3GPP? Any comments or critical appraisal?
Yes, it is based on MISTY, a cipher that has been published for several
years in the academic literature. Thus, it seems likely to me that the
3GPP cipher, KASUMI, will provide a considerably higher assurance of
security than the GSM algorithms. (Of course, this is just speculation.)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Comparison of ECDLP vs. DLP
Date: 22 Jan 2001 03:59:51 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Paul Rubin wrote:
>Really, statistical tests can only detect catastrophic RNG failures. They
>won't detect a simply poorly seeded RNG.
Right. For instance, no statistical test would have detected the bad
RNG in the old (1995) versions of Netscape browsers and servers, because
that RNG was essentially equivalent to running the output of rand()
through MD5. See <http://www.ddj.com/articles/1996/9601/9601h/9601h.htm>
for details.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: JPEG infidelity for crypto
Date: Sun, 21 Jan 2001 21:58:35 -0600
In article <[EMAIL PROTECTED]>, Dido Sevilla
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > Along with GIF's, bitmaps on PC's and PICT's on Mac's are amongst
> > acceptable formats for faithfull bit representation, within available
> > resolution of the monitors, of course.
>
> What relation does this have to cryptography? Have you missed saying
> something? Maybe your post should go to comp.dsp or
> sci.image.processing. You've said nothing at all that discusses
> cryptography and JPEG images.
>
This is important for stegnography, to illustate technical limitations as
means around them are addressed. I understand that there are some for
dishonorable reasons whop wish to cloud this area of crypto so as to
dissuade understanding of its potential. If you are unwilling to advance
in the field, don't try to stop others.
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: JPEG infidelity for crypto
Date: Sun, 21 Jan 2001 22:01:36 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Sun, 21 Jan 2001 17:03:18 +0800, Dido Sevilla <[EMAIL PROTECTED]>
> wrote, in part:
>
> >What relation does this have to cryptography? Have you missed saying
> >something?
>
> Well, the relation is obvious: simple forms of steganography, which
> depend on preserving things like the LSB of every single pixel, don't
> work with .JPG files.
>
> You could complain that we already knew that, and that there are more
> sophisticated (but less efficient) methods of steganography that even
> work with JPEGs; they're mainly used for watermarking.
>
You just saved me from the direct followup. Thanks. Meanwhile, my images
are sporting even more examples of simple stegnography. It is an open
workshop.
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Mon, 22 Jan 2001 05:05:24 GMT
Mok-Kong Shen wrote:
> Terry Ritter wrote:
> > That idea that we need "key efficiency" represents a time now long
> > gone. In the context of modern communications, why should anyone be
> > anxious about sending additional keying material? Do we really worry
> > about sending another 256 bits, or 1024 bits, or whatever? This is
> > message key material, random and endless; we can take all we need, and
> > send it at almost no cost.
This is utterly wrong. I'm currently working on the design of a
new communication system, and key distribution is a major issue.
------------------------------
Date: Mon, 22 Jan 2001 05:04:45 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Transposition code
Benjamin Goldberg wrote:
>
> Richard Heathfield wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > This only writes items, one row at a time, into columns in shuffled
> > > order. I want to output the data reading down the columns.
> >
> > Have you considered using a two-dimensional array? Or have I
> > misunderstood you?
>
> A 2d array is just what I want, except that since I have to allocate it
> dynamically (the number of columns matching the length of the key),
That's easy enough...
> I have to implement the 2d array as a 1d array.
Why?
Not difficult, of course.
#include <stdlib.h>
T *p;
p = malloc(sizeof *p * maxcols * maxrows);
if(p != NULL)
{
/* Get to p[row][col] */
offset = row * cols + col;
p[offset] = 6;
/* Get to p[col][row] */
offset = col * rows + row;
p[offset] = 42;
/* Now that I've said it's not difficult, I expect I've introduced a
bug. C'est la vie... */
}
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fitting Dynamic Transposition into a Binary World
Date: Mon, 22 Jan 2001 05:44:36 GMT
On Mon, 22 Jan 2001 01:11:58 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Of course, this kind of begs the question of how to devise an
>efficient coding for arbitrary strings into balanced strings. From
>arbitrary binary strings, one could use a simple numeration of
>balanced strings...
>00000000 = 0000011111
>00000001 = 0000101111
>00000010 = 0000110111
>00000011 = 0000111011
>...
>11111011 = 1111100000
>11111100 ... coded to something else
>and maybe there *might* be a simple algorithm to do this for strings
>too large to put in a table
>but my second idea, coding unbalanced strings to balanced ones, seems
>less likely to be workable. Of course, if an algorithm _did_ exist, it
>would produce a nicely weird mathematical structure.
I've started to think of an algorithm for the conversion that gives a
mapping that eliminates the need for the second idea, because it keeps
a close relationship between the original binary sequence and the
balanced one to which it is mapped.
Essentially, since my target code has the constraint of having the
same number of ones and zeroes, why not use the number of ones and
zeroes in the input string to indicate how to manipulate it to form
the result string.
For mapping an arbitrary 8-bit string to a balanced 10-bit string
(with four codes left out):
If the 8-bit string is balanced, map it to 01 + the original 8-bit
string.
If the 8-bit string has 3 zeroes and 5 ones, map it to 00 + the
original 8-bit string.
If the 8-bit string has 5 zeroes and 3 ones, map it to 11 + the
original 8-bit string.
Then, the code 100 would precede the representations of strings with
more than five ones, and the code 101 would precede the representation
of strings with more than five zeroes.
But after the initial start, it seems to get complicated, and there's
no obvious way to do better than a plain enumeration.
Instead of going straight to the mapping from an arbitrary 160-bit
string to a balanced 164-bit string, there is a good value at an
intermediate point.
2^39 is
549,755,813,888
and there are
538,257,874,440
42-bit balanced strings
The codes can start like this:
111 + 21 zeroes and 18 ones
110 + 20 zeroes and 19 ones
001 + 19 zeroes and 20 ones
000 + 18 zeroes and 21 ones
but again, it's unclear what to do for the next step.
Maybe there already is a mapping to balanced strings that has a simple
and optimal algorithm, faster than the one for the mapping in binary
numerical order.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Transposition code
Date: Mon, 22 Jan 2001 05:31:54 GMT
On Mon, 22 Jan 2001 05:04:45 +0000, Richard Heathfield
<[EMAIL PROTECTED]> wrote, in part:
>Why?
Well, he is using C. So, if he is using malloc, it is more convenient
to have a one-dimensional array, although one could always use an
array of pointers to get a two-dimensional notation.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: cryptographic tourism in Russia
Date: Mon, 22 Jan 2001 06:29:16 GMT
[EMAIL PROTECTED] wrote:
>As a high-tech person interested in cryptography, espionage,
>telecommunications, internet, satellite systems and a related gamut of
>topics, I would like to visit interesting places in Moscow and St Petersburg
>on my impending tourist jaunt there. For instance, visiting buildings that
>were or are, the equivalent of the NSA and GCHQ, or whatever other relevant
>sites. Can readers offer me suggestions ?
>
>[EMAIL PROTECTED]
>
Well the KGB's former codebreaker school is now called the Institute
of Mathematics. It's in Moscow somewhere, I can dig up the address.
These guys are fairly up front these days.
Steve Roberts
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Mon, 22 Jan 2001 06:28:43 GMT
Terry Ritter wrote:
[...]
> Even a contest with no payoff can encourage some entries.
Coppersmith, Biham, Rivest, Daemen, Rijmen, Schneier,
Wagner, Vaudenay, Schroeppel, Massey, Adams, Knudsen.
"Some entries" indeed!
> However -- and in marked contrast to theory and guessing -- I can
> personally attest that I was prepared to enter the competition, until
> it became apparent that I could not do so and retain my intellectual
> property rights. Now, I had no illusions about actually winning; no
> tiny company is going to win such a contest. But the promise to hand
> over the property rights would have compromised my ownership until the
> contest was over, at some vague time in the future.
>
> In the end, I did not participate, so *my* development did not occur.
> Thus, I can personally testify that AES did in fact *discourage* my
> cipher development, since it was clear to me that there would be even
> less of a market for new ciphers in the future than there was at the
> start.
[...]
> I note that AES did not guarantee free encryption software so that all
> society could use encryption; it instead removed the economic basis
> for an industry of cipher *development*.
Did it? Since you were in the symmetric cipher licensing
business years before the AES effort began, can you tell us
how many licenses you sold in the year before the first AES
announcement versus how many in the year after?
> It also failed to provide an
> economic basis for cipher *evaluation*; the ad-hoc "please
> donate your time" approach is just sad.
Sad? As I understand things, you gained a major
contribution to your own large block cipher development
project, albeit in the form of a setback, when Bruce
Schneier showed your then-current design to Eli Biham. Their
service was, correct me if I'm wrong, uncompensated.
While I must respect you for leaving this part of the story
in your public account of your work's history, I believe
there is a broader lesson in it than you have taken. Both
Biham and Schneier are among the authors of AES finalists,
and both released their ciphers for free. Since you have
been the beneficiary of their unpaid efforts and obvious
abilities, I see no injustice to you when the rest of us
receive such gifts. Since you sell, or at least offer for
sale, ciphers that were improved by valuable unpaid
cryptanalysis (and apearently no paid "evaluation") I do not
see how you can lodge this complaint about AES.
Perhaps the effort that includes Biham and Schneier might
even warrant some respect.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Mon, 22 Jan 2001 07:07:48 GMT
On Mon, 22 Jan 2001 00:02:04 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Sun, 21 Jan 2001 22:43:08 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>No OTP can be secure if the keying sequence is predictable. Here,
>>"predictable" does not refer to whether or not *we* can predict the
>>sequence, or whether someone we know can predict the sequence, but
>>rather whether the opponent can predict the sequence. We cannot know
>>what the opponents can do.
>
>>[ Let me remind everyone that we are talking about *proven*, or
>>*guaranteed* unbreakability. In practice, it is quite likely that a
>>well-engineered random sequence will be sufficiently unpredictable to
>>be very secure. The issue is that we generally cannot *prove* that a
>>sequence is unpredictable, or measure how unpredictable it is -- we
>>have no such test, and there can be no such test. As a matter of
>>fact, new tests keep being developed as additional types of
>>predictability are found. ]
>
>>So unless the OTP keying sequence is *proven* unpredictable in
>>practice (something which is normally impossible), no practical OTP
>>can be *proven* secure.
>
>>Only the theoretical OTP can be proven secure, and that is only good
>>for protecting theoretical data (or, perhaps better: "theoretically
>>protecting data.")
>
>I fear that I'm not the only person puzzled by this.
No, I think you are the only one puzzled.
>In principle, what you are saying is sound: nothing physical is
>susceptible to mathematical proof.
>
>However, while we cannot know if our opponents have, say, an easy
>crack to Blum-Blum-Shub, to object that we cannot know if our
>opponents might have some way to predict things like *the flip of a
>coin* seems to be taking caution to a perverse level.
So, basically (as far as I can tell), you support my position that, in
practice, no OTP can be proven secure. Well, great.
But, as much as you would like to trivialize that insight, even here
on sci.crypt it is common to think otherwise. In fact, the only
reason it came up at this point was as a direct response to a
statement -- which you conveniently omitted -- "OTP can be provably
unbreakable, because there is as much key as message."
If by "OTP" we mean a cipher intended to provide practical security
and protect real data, the sentiment that such a system is proven
secure is both common and false.
The whole point of desiring a security proof which applies in practice
is to provide what is not now available: confidence in the strength of
a cipher when there are consequences for failure. Nobody cares about
the strength of a cipher which cannot and does not protect data.
Proofs which only apply in the abstract are "academic" is the worse
possible sense. When abstract results are not plainly qualified to
not be applicable to reality, they can only be considered deliberately
deceptive.
Somewhere there is a reference which continues to corrupt the minds of
people coming into cryptography. It deludes them into believing the
OTP is mathematically proven to be unbreakable in practice. I would
love to find exactly what that reference is. Then maybe we could stop
all this nonsense before it starts.
>>There is a ciphering technology which I created and named "Dynamic
>>Substitution." There is another, different, technology which I also
>>created and named "Dynamic Transposition." Here we discuss Dynamic
>>Transposition.
>
>Yes, the two are basically unrelated. Since you named them, though,
>you must take part of the responsibility for the resulting confusion.
I invented these technologies, so I named them.
The names are appropriate, since they make sense and emphasize the
distinguishing characteristics. I take no responsibility for the
misuse of the terms which are mine to define.
The original articles were published in ink-on-paper and are available
in some libraries. Approximations to the original articles are on my
web pages, as are various detailed technical discussions of these
technologies. Most of these terms are in my Glossary. There is not a
whole lot more I can do.
The real problem is that these fundamentally novel technologies have
been uniformly ignored by academics and crypto text authors. In
consequence, their readers have not been properly prepared to address
these new ideas. Readers who are disappointed by this should contact
the publisher of the disappointing reference.
>>The unexpected advantage of Dynamic Transposition is that a plethora
>>of different permutations produce exactly the same ciphering result.
>>This would seem to hide the exact permutation used, and thus also hide
>>any attempt to define the shuffling sequence by moving back from a
>>known permutation.
>
>But that's not an advantage that can't be obtained with substitution.
The advantage cannot be obtained by substitution.
I have seen you say that, but I have absolutely no idea what you could
possibly mean by it.
>Suppose we enciphered a message using DES, except that the subkeys are
>generated by some sort of stream cipher. Each 48-bit subkey could be
>replaced with any member (including itself) from a set of 2^16 subkeys
>that give the same result.
How is it that these different keys give the same result?
>Because there are more than two rounds,
>successive pairs of subkeys can produce the same result in many
>different ways, just like the two permutations in Dynamic
>Transposition.
There is only one permutation per block in Dynamic Transposition. I
do recommend shuffling twice, only to prevent someone who knows the
actual permutation from attacking the RNG sequence. But that idea is
really getting in the way of comprehension, because that is not the
main source of strength in the system. In the end, there is just some
permutation.
The main source of strength is that a vast number of fundamentally
different permutations produce the exact same ciphertext block from
the exact same plaintext block. Thus, known-plaintext does not expose
the transformation. So it is at least very, very difficult, and
perhaps impossible, to even know what the permutation was, since it
only occurs once and is only used once. And without the permutation,
we cannot even begin to think about finding the shuffling sequence
which is what the double-shuffling should prevent.
>To me, therefore, Dynamic Transposition doesn't look _all_ that
>different from using four round DES with subkeys that are generated
>anew for every block.
Then you need to look closer.
>It might have the advantage of being faster.
>
>It might have the advantage of being more 'idiot proof', in that it
>couldn't be 'streamlined' so as to get rid of the advantage of
>multiple equivalent permutations.
>
>It might have the advantage that successive permutations are harder to
>unravel than successive XORs, or even additions alternating with XORs.
"Might?"
>And there is the theoretical interest of showing that, fundamentally,
>a transposition can be, inherently, just as secure as a substitution.
Dynamic Transposition is vastly more secure than a substitution.
You will have to define what you mean by "substitution" though, since
you appear to be describing DES as "substitution."
Modern block ciphers do attempt to emulate large simple substitutions.
They are given "large enough" keyspaces to prevent brute-force attacks
on keys. But nobody should have any delusions about the extent to
which they actually produce all N! possible cipherings. Their keys
cover only an infinitesimal fraction of the potential substitution
keyspace, and we have no indication that any of these designs could be
expanded to do vastly better. As a consequence, each known-plaintext
block massively reduces the number of keys which could have produced
that transformation. Normally, only a few known-plaintext pairs are
necessary to reduce the set of keys which could have produced those
transformations to exactly one. That we do not currently know how to
accumulate that information or use it, is not particularly comforting
to me.
In contrast, the Dynamic Transposition cipher which I have proposed
fully covers a vast keyspace. Assuming we have sufficient state in
the RNG (and I have presented large-state examples), every possible
permutation can be key selected. So we don't have to guess whether
the construction can be expanded; its only limitations are the keys.
If and when 3,000-bit message keys become necessary, we can drop them
in with no problem at all. In fact, if that is all it takes to
achieve a more pleasant analytical result, we could do that now.
But the real advantage here -- which I keep mentioning but apparently
just goes: Swish! right over people's heads -- is that the particular
transformation which occurs in Dynamic Transposition is not revealed
by known-plaintext.
With substitution, when we have known-plaintext, exactly one
transformation which has occurred, and that is completely known.
When we have a Dynamic Transposition enciphered block, any one of a
vast number of different permutations could have produced that block.
So even if we have known-plaintext, the transformation is not
revealed. The opponent does not know which permutation occurred.
That is a massive difference.
>But because it seems to be stuck with a bandwidth problem
In my experience with actually running such a cipher, bit-balancing
adds 25 percent to 33 percent to simple ASCII text. The 1/3 value was
given both in the "Revisited" article, as well as the original
Cryptologia article on my pages. And if the text is compressed first,
there will be even less expansion. If you see even a 33 percent
expansion as a show-stopping amount, a "bandwidth problem," I think
you need to pause for re-calibration.
>when taken
>'straight', and because its advantages can mostly be matched within
>the substitution world,
Simply false.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
