Cryptography-Digest Digest #21, Volume #10 Tue, 10 Aug 99 03:13:03 EDT
Contents:
Re: Construction of permutation matrix (wtshaw)
Re: AES finalists to be announced (wtshaw)
Re: NIST AES FInalists are....
Re: Challenge: mental authentication ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... (Jim Gillogly)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Pretty Boy Mohandas)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Pretty Boy Mohandas)
Depth of Two, Part II
Re: Academic vs Industrial (David A Molnar)
Re: Academic vs Industrial
Re: Academic vs Industrial
Depth of Two
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Pete Becker)
Base 95->Base 26, number 22 of a series (wtshaw)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (David Goodenough)
Re: Academic vs Industrial (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Construction of permutation matrix
Date: Mon, 09 Aug 1999 20:01:44 -0600
In article <7ond2g$8kg$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
> In article <[EMAIL PROTECTED]>,
> wtshaw <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
> >
> >> wtshaw wrote:
> >> > > it is the amount
> >> > > of information in the simplest nontrivial discrete choice (Boolean,
> >> > > YES/NO).
> >> > Which is only a small part of what logic can be involved in choices.
> >> > Trying to make everything in to yes/no is left to the uneducated and the
> >> > legal profession.
> >>
> >> SIMPLEST. SIMPLEST. SIMPLEST.
> >
> >Wait just a dang fangle minute here pardner. If a choice is not simply
> >yes or no, it is not a simple bit choice.
>
> No, but it can be modelled as a collection of simple bit choices.
>
Not always in choice-complete manner, as when you need five choices, you
must allow for eight.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES finalists to be announced
Date: Mon, 09 Aug 1999 20:12:56 -0600
In article <7onj2h$1eg8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>, Helger Lipmaa <[EMAIL PROTECTED]>
wrote:
> >Bruce Schneier wrote:
> >
> >> The most interesting thing to notice is that the five finalists were
> >> designed by teams that have had strong cryptanalysts on them. Almost
> >> all of the other algorithms (E2 being the only exception) were
> >> designed by teams that did not have strong cryptanalysts on them. As
> >> I have said again and again, good ciphers are designed by good
> >> cryptanalysts.
> >
> >I can imagine the face of Serge Vaudenay when reading this posting.
> >
>
> All it really shows is that it is a phony "mutual admiration society" that
> is busy patting itself on the back and actually closed to any real
progressive
> original thought. If you don't think the way they do you are not allowed in.
> Unless you use methods so poor that it makes them look good.
> David A. Scott
Take comfort in the fact that correlation does not prove causation,
although, having an algorithm able to withstand publically known attacks
seems to be a plus. It is the other attacks that we don't know about, if
and whatever they might be.
So, David, you might be right, but, who is to say? The premise for the
process was supposed to be honesty.....hope it is....time will
tell.....then, maybe it won't.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: NIST AES FInalists are....
Date: 10 Aug 99 02:51:59 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: At what point are competent NSA cryptanalysts going to be brought
: into the process, so we can get a soundly based estimate of security?
Presumably, they *are* participating even now (without their help, after
all, perhaps the only secure AES candidate could already have been
eliminated). However, the nature and extent of their input is doubtless
classified.
While the public will know that the final AES is believed to be secure by
the NSA, presumably they are not to know *why* it is secure, or which of
the other candidates are secure or not.
To whatever extent the NSA knows things which are not generally known
about how to make good block ciphers, it makes perfect sense for the NSA
to assist NIST in ensuring the final AES is secure without giving away any
of what it knows.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Challenge: mental authentication
Date: Tue, 10 Aug 1999 03:01:23 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> Lincoln Yeoh wrote:
> >
> > Given most of the public don't like thinking or remembering I'd
suggest
> > using iris scanning instead. www.iriscan.com
> >
> > Already being used for ATMs by a bank in britain.
>
> Didn't you see "the trap"...
>
> A top businessman is attacked by a weirdo who sprays him in the
> eyes with something. Somebody calls an "ambulance" and they take
> him for an eye-check, and photograph his retina with a modified
> eye-check machine.
Iris, not retina. The iris is the coloured thingy around the pupil.
Not much point going to all that trouble just to rob an ATM user right?
Not like you're going to be able to do that many times, and over here
you'd only get about USD500 worth each time. Subtract the potential
costs of being caught and it's prohibitive.
For more important stuff you can use a combination of
passphrase(something you know) and iris scanning (something you have and
can't easily change), so you can change the passphrase if nasty things
happen.
You can also use iris scanning machines which check that your pupils
open and close as they would for a real eye. There's the small movement
all the time, and there's the big movement due to changes in lighting.
For retinas the cameras will have to be closer, which usually means more
intrusive.
It can get very costly to defeat such systems directly. You might as
well do Mission Impossible stuff and break into places undetected (since
we're mentioning movies). It's not easy to secure a large physical
installation which has significant numbers of things/people going in and
out.
Cheerio,
Link.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Tue, 10 Aug 1999 03:44:41 +0000
"Douglas A. Gwyn" wrote:
> At what point are competent NSA cryptanalysts going to be brought
> into the process, so we can get a soundly based estimate of security?
So far as I know that's not officially on the unclassified schedule.
NSA is on the hook to provide hardware benchmarks on the ciphers, but
I haven't heard that they've been tasked to comment publically on
AES security.
If that had been in the cards we might have seen another member of
the Skipjack family with a longer key size as a first round candidate.
If you know anybody of that description, you might want to encourage
them to comment during this round -- I would think the stakes of an
AES are high enough that anyone could see that it has national (and,
of course, international) security implications.
But which hat would they be wearing? Given NSA's two conflicting
responsibilities -- protecting US communications and reading foreign
communications -- it's not obvious that they could justify becoming
midwife to a good unclassified 128-bit cipher. If they report that
a previously unknown attack would reduce the strength of three of
the ciphers to 107 bits and we can verify this, how much confidence
should we have that they don't know another clever attack that would
reduce one of the survivors to 38 bits?
--
Jim Gillogly
Highday, 18 Wedmath S.R. 1999, 03:30
12.19.6.7.16, 8 Cib 4 Yaxkin, Third Lord of Night
------------------------------
From: Pretty Boy Mohandas <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Mon, 09 Aug 1999 23:43:19 +0600
Rosimildo DaSilva wrote:
> >Unless you need to use the debugger...
> Well, debugger is for programmers that writes buggy code !!! < g >.
And I'm not even saying that plopping printfs here and there would give
a real man all debugging he needs <G>.
------------------------------
From: Pretty Boy Mohandas <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Mon, 09 Aug 1999 23:53:28 +0600
Jerry Coffin wrote:
> True, but 1) they actually display the help in a complete application
Perhaps I misunderstood, but they embed the reader in the Visual Studio
thing. You _can_ also install an MSDN reader (a separate app that,
apparently, uses the same control) and read help w/o VC. Finally, when I
installed my VC5 (probably 5?) I remember it asked for so much damn
space for IE that I can't believe it's all the control and nothing else.
It is _huge_. Being a conspiracy theorist par excellence, and due to my
long exposure to MS stuff, I do suspect they use the new HTML help as
another pretext to shove IE down more people's throat. I have an
HTML-reader control that came with Qt--it's small. I mean, it eats up
pretty much any kind of "normal" html, and it's not hudreds of megabytes
<g>.
> Oh, you'll get no argument from me on this point -- I thoroughly loath
> the current help system.
Oh, great. Good to hear this. I thought I'm the only one bigoted against
innovation <G>.
>...authoring for their previous systems
> certainly was a pain compared to writing HTML.
Not if you had an editor. I used something from I forget what company
(<G>) and it was a breeze. Otoh, writing in HTML is no easy task unless
you have an HTML-capable editor. Anyway, we're not arguing it seems.
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Depth of Two, Part II
Date: 10 Aug 99 03:29:55 GMT
In the previous post, I noted that Kerchoffs superimposition could lead to
solving messages, even with only two aligned messages, *if* the possible
alphabets came from a small set with a simple relationship known to the
cryptanalyst, such as in the case of a Vigenere with some sort of
aperiodic key.
What if the alphabets are unknown? Well, if they are known to be related,
for example by being produced by a St. Cyr slide - even a Type IV one,
with two different mixed alphabets, both unknown, I realized that the
cryptanalyst still has some hope.
However, more than two short messages are needed for the simple approach I
am about to outline.
For each letter in one message, one can compile a frequency table of what
messages are found corresponding to it in the other message.
If there happen to be a pair of high-frequency letters 10 places apart on
the plaintext slide, then letters which are 10 places apart on the
ciphertext slide will often be found at corresponding positions in paired
messages.
If one has a distinctive enough frequency count for even _one_ interval on
the ciphertext slide, and that interval happens to be relatively prime to
26, the ciphertext alphabet - or at least a decimation of it - can be
reconstructed. Hence, the complete frequency chart, even though it will
have many letter pairs too close to distinguish, should contain enough
information to recover the ciphertext alphabet.
Actually reading the messages and reconstructing the plaintext alphabet
will be much harder work, as the clues available will still be very
fragmentary, but probably not beyond the ability of an able
and experienced cryptanalyst. One will have other common intervals as
clues in addition to the places where both messages have the same letter,
and one can work on the plaintext alphabet and the messages at the same
time.
John Savard
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Academic vs Industrial
Date: 10 Aug 1999 04:19:21 GMT
[EMAIL PROTECTED] wrote:
> less with block ciphers, but if they included things like data-dependent
> transpositions, large key-dependent S-boxes, and so on, I'd be hard put to
> begin to imagine attacks.
Naive question : do data-dependent operations make a cipher more amenable
to chosen-plaintext attacks?
Other naive question : I was under the impression that random S-boxes were
likely to be weak against differential cryptanalysis. Do key-dependent
S-boxes escape this problem b/c they're secret, or are there ways to
infer their structure from some attack?
Is there a good summary/introduction of work on S-box design which is more
recent than "Cryptanalysis of the DES" ?
I know I should probably figure this out by looking at analyses of RC5 and
checking web pages...but pointers are still appreciated.
Thanks much,
-David
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Academic vs Industrial
Date: 10 Aug 99 03:39:25 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: The quantity of unsuccessful analysis is no measure of anything.
: Kryptos might have undergone a lot of "intense public scrutiny",
: but it turned out not to be an especially strong encryption.
Yes, but that is scrutiny of a different nature and kind from that to
which algorithms, such as DES or SAFER, are subjected to.
I'd like to see "messier" algorithms, though, to feel more reassured that
with a block cipher there seems to be very little danger of what I worry
about with public-key algorithms like RSA: a significant mathematical
discovery that will change the playing field. The worry is already much
less with block ciphers, but if they included things like data-dependent
transpositions, large key-dependent S-boxes, and so on, I'd be hard put to
begin to imagine attacks.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Academic vs Industrial
Date: 10 Aug 99 03:35:06 GMT
Bo D�mstedt ([EMAIL PROTECTED]) wrote, in part:
quotes also partial
: "Markku J. Saarelainen" wrote:
: > There seems to be building up a consensus that many academic algorithms
: > and standardization results are quite ineffective for any serious data
: > protection purposes
: and then Paul Koning wrote:
: >Or are you trying to say that none of these are any good because
: >they are all controlled by the NSA? Are you a David Scott clone?
He could be saying the absolute opposite: that none of them are any good
because they are all designed by ignorant outsiders, instead of the dark
geniuses of the NSA who actually know what it takes to make a secure
cipher.
In that case, since SKIPJACK has been declassified, he still has an
alternative.
: Assuming that Markku J. Saarelainen is not a David Scott clone,
: we can still not exclude that his argument could be correct in the
: respect that beforementioned cipher algorithms could be weak.
We can't exclude it, but I'm not aware of the consensus he is referring
to. I would think that it is easy to make the usual designs much stronger
without making them slower (on a computer): use a block cipher in ECB
mode, but for each block, use different subkeys picked from a large pool,
for example.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Depth of Two
Date: 10 Aug 99 03:05:53 GMT
In "Between Silk and Cyanide", Leo Marks notes that he had been able to
solve Vigenere messages enciphered with a two-time pad, and later learned
that he had accomplished something that would have been of interest to
Bletchley Park at the time.
For a cipher like that produced by a rotor machine, where every alphabet
is different, it seems as if the only information available is whether the
two letters in the two messages are alike - or different. And that just
isn't enough. Of course, if the rotor machine is not too complicated in
its gearing, and the rotor wirings are known from previous experience to
the cryptanalyst, perhaps something can be done. After all, the ABM Treaty
is supposed to have resulted from the NSA's having read a rotor machine
encrypted message with a depth of two, according to some accounts.
But for a Hagelin machine, or a twice-used one-time pad with known
alphabets, the cryptanalyst *does* have enough information to read the
message, as I realized after some thought.
Let us suppose we are dealing with some sort of displacement generator
applied to the alphabets of the Vigenere table.
With a depth of two, for every pair of letters in the two messages, we
have the distance in the alphabet between the corresponding letters in the
two plaintexts.
Thus, when the two letters are the same, we look for a high-frequency
letter. When they are one place apart, we look for two high-frequency
letters which are adjacent in the alphabet. And so on; thus, for each
letter in each message, we have a set of candidates which can be ranked in
order. Suitable tables can be prepared in advance to allow one to put
under each letter the three most likely possibilities, in order.
>From that, the messages (which, of course, won't consist entirely of those
likely candidates) will probably come forwards to the eye in short order.
However, where the alphabets are not so limited - as in the ABM Treaty
case - or where one is dealing with code messages, or messages in an
unknown alphabet that also reduces redundancy, superenciphered by a
twice-used pad, as in VENONA - then one is no longer dealing with the
simplest case of a depth of two, and the cryptanalysts at the NSA deserve
all their credit for dealing in such a stratospheric realm.
John Savard
------------------------------
From: Pete Becker <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Mon, 09 Aug 1999 12:28:37 -0400
Paul Lutus wrote:
>
> Non sequitur.
Not at all. See below.
> Only MSIE can reside within MSDev as a component. I discovered
> the same thing in my program Arachnophilia, to my dismay. :)
>
That's a completely different statement from "They are in HTML. This
requires MSIE." The latter is false: many other tools can handle HTML.
By adding a requirement that such tools also must run as components
within MSDev you've changed the foundation of the argument. Don't claim
that anyone else's logic is faulty when you've omitted important
details.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Base 95->Base 26, number 22 of a series
Date: Tue, 10 Aug 1999 00:52:12 -0600
The previous base translation algorithm, Mafra, converted the keyboard of
47 characters, plus shift and space for 49 to letters. Mafra uses base 7
as an intermediary.
This new one, NagaHills, uses no intermediate base, but is a sister
alternative to Mafra as it produces a full alphabet of letters in its
ciphertext from keyboard plaintext as well. Considering the upper and
lower cases of the 47 keys, for 94, add in a space character, and you have
95.
95 characters is a bit much to shuffle to make a key, but 26 is not bad to
handle for a substitution key.
There being no other base involved in NagaHills than 95 and 26, what to do
about some transposition seems a problem. But, it does feature plaintext
groups of 5 and 10 characters, and ciphertext groups of 7 and 14; you can
shuffle them, a total of 12 or 24 characters.
The transposition key is really two separate keys, but I generate and
display them together. Note in the example of the keys from NagaHills
that the transposition key is in two parts, a left and a right, and that
the mixed letters in each do not overlap. Some discussion was made of
combining keys, and I could have made it look better by fully shuffling
all 12 or 24 letters in the keys, but that would have been deceptive,
since you could have no truthful result than the method I chose.
Even as the transposition keys are very small, keylengths do accumulate.
But, NagaHills is not on the strong end of the base translation totem
pole, be it another useful way to cram a keyboard into the restrict form
of a normal alphabet.
I'll use this sentence to generate keys for NagaHills 24, then actually
encrypt these same words:
nximh urgkx yzcnr ozwst iyefq qlqyz bddie sxryi vbfbw llcoa rhhdy tibgg
wyuba kfgwx ikdmu jogro kkwni ourcp fqwaf ruzky jcnqa ivygj lerbu cxlhg
nzfau zhujt nnqjz dqbbr
Subs(NH): kmnztcwjluvdoxepbfyrigqhsa
Trans(NH): iadbjhcfge knloqrsuwxvpmt
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (David Goodenough)
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Tue, 10 Aug 1999 05:47:08 GMT
On Mon, 09 Aug 1999 17:38:20 -0400, Pete Becker <[EMAIL PROTECTED]>
wrote:
>Paul Lutus wrote:
>>
>> I *think* it gets us back to the same complaint, that MSIE is required. Not
>> the original question, "Why is this true?"
>>
>> Oh, BTW. In *principle* VC++'s compiler can be made to work from the command
>> line, thus eliminating all of that. You "simply:"
>>
>> 1. Extract the needed files from the distribution CD,
>> 2. Create your own directory tree,
>> 3. Write your own launching batch files.
>>
>> No MSIE, no need for a GUI at all, in fact.
>>
>
>Unless you need to use the debugger...
Use Windbg, as shipped with the latest and greatest platform SDK.
Blows Dev Stew clean off the map for a debugger. Two huge advantages
come right to mind just as I type this in:
1. It has a command line window where you can type in useful commands
to do useful things.
2. It can open more than one memory dump window. I can only describe
Dev Stew as *LAME* in the extreme for its insistance that it will only
have one memory dump window open at a time.
There are probably others .....
As for the help files, I wonder if the help tool as provided with the
DDK could be coaxed into showing them. Hafta check this out.
FWIW, Windbg has replaced Dev Stew as my debugger of choice
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Academic vs Industrial
Date: 9 Aug 1999 23:31:35 -0700
In article <7oo989$515$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Other naive question : I was under the impression that random S-boxes were
> likely to be weak against differential cryptanalysis. Do key-dependent
> S-boxes escape this problem b/c they're secret, or are there ways to
> infer their structure from some attack?
If you're not careful, random S-boxes can be problematic, even if they're
secret.
This is especially true if the S-boxes are very small. For example, random
S-boxes are very bad for DES.
Remember that not all key-dependent S-boxes are what you call "random"
("random" = generated uniformly from the set of all S-boxes). You can
try to generate key-dependent S-boxes that avoid the weak choices.
See, e.g., Twofish for a technique for generating key-dependent S-boxes
that seems to work.
(Actually, another way of viewing Twofish's S-boxes is as a mini 8-bit
keyed cipher whose structure is unkeyed. Thus, you can think of Twofish
as using either key-dependent or key-independent S-boxes, whichever you
prefer -- both views are equally valid.)
------------------------------
** 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
******************************
