Cryptography-Digest Digest #949, Volume #10 Fri, 21 Jan 00 16:13:02 EST
Contents:
Re: Transposition over ASCII-coded text (Mok-Kong Shen)
Re: SRP optimisation (John Myre)
Re: Combination of stream and block encryption techniques (Terry Ritter)
Re: NIST, AES at RSA conference (Hammer)
Re: NIST, AES at RSA conference (Mok-Kong Shen)
Re: McDonald's claims Nobel peace fries [off-topic] (Mike Rosing)
Re: NIST, AES at RSA conference (Mok-Kong Shen)
Re: LSFR (David Wagner)
Re: Combination of stream and block encryption techniques (Mok-Kong Shen)
Re: simplistic oneway hash (wtshaw)
Re: What's with transposition? (wtshaw)
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: Publication Reference for Vernam Cipher (Albert P. Belle Isle)
Re: New Crypto Regulations ("John E. Kuslich")
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: Wagner et Al. ("John E. Kuslich")
Re: Calculating A^-1 Mod P (Bob Silverman)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Fri, 21 Jan 2000 20:17:07 +0100
Markus Eiber wrote:
>
> Mok-Kong Shen wrote:
> >(1) Does one use in 'normal' transmission a 'scrambler' to improve
> > 'error correction'?
> Yes. First of all the data gets scrambled and then redundancy for error
> correction is added. During transmission there often occur burst errors
> (several neighbouring bits get falsified) which cannot be corrected (common
> codes can correct only up to two bits per codeword). So several codewords of
> information get lost. One can avoid this by scrambling the data, because
> with descrambling the falsified bits get distributed to a lot of codewords,
> that is the quantitity of false bits per codeword gets reduced.
I am a bit surprised to know this. The books on error-correcting
codes don't seem to mention that the data has first to be 'scrambled'
in some way and then the specific error-correcting code is applied.
Or do you mean that using an error-correcting code IS by itself doing
'scrambling'? (The redundancy needed for correction is contained in
the error-correcting code.) Could you please name a book and the
page number where one can find that this (i.e. first 'scrambling'
and then applying a code that has redundancy) is indeed the case?
> (Little note to Hill's method in this context: If one decodes the ciphered
> bit stream he gets a monoalphabetic polygraphic substitution of the
> plaintext, this is what Hill's method creates, too)
If I don't err, the essential feature of Hill's method is to use a
matrix to (economically) define a (huge) substitution table. Hence,
if your 'scrambling' doesn't use that feature, I don't yet clearly
see a context connection with Hill's method.
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: SRP optimisation
Date: Fri, 21 Jan 2000 12:09:38 -0700
Paul Crowley wrote:
<snip>
>
> I'll try venturing an observation again and see if I get shot down:
> you can't use the same trick for the client end only because the
> client doesn't have the password salt when the ephemeral public key A
> is generated. You could send it and save a pass at the end, but you
> introduce a pass at the beginning!
>
> Hmm. On the other hand, if you *could* pull such a trick with that
> caveat, it might be worth it anyway, since lots of clients could cache
> salts. Hmm.
Yeah, I like that idea.
What if the salt is the client name? Or plus the server name? The
logon process has to acquire these values anyway, and they would
surely provide enough variety.
If I understand salts correctly, they don't have any particular
entropy - they are public information. They do, however, need to
be (mostly) different for each client, so as to limit the chances
of two users having the same password+salt (knowing, as we do, that
people choose poor passwords and are likely to collide).
Or are there other required properties of salt that I'm not
getting? For example, do they need to change from time to time?
Comments?
John M.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 19:16:26 GMT
On Fri, 21 Jan 2000 18:45:35 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>Could we perhaps say that the fundamental component of a stream
>cipher is its key stream, which is commonly supplied by a pseudo-
>random number generator etc., while a block cipher doesn't have
>that (or at least doesn't have that explicitly).
No, sorry. There supposedly is a class of stream cipher which appears
to function somewhat like a digital filter (input plaintext, output
ciphertext), and thus does not need or use a key stream, nor do they
generate a keystream internally. Unfortunately, I have not seen a
real example, and cannot imagine how any such approach could hope to
be secure. Others who have seen actual designs have been convinced,
however.
We could of course subdivide stream ciphers into keystream and
filtering approaches. But in my view the reason for making categories
is to provide insight into consequences of design, and I don't know
the consequences here. So at this point the distinction seems rather
meaningless.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Hammer <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Fri, 21 Jan 2000 19:09:52 GMT
Hmmmm... I had not thought of this. It makes perfect sense though... I
wonder if NIST considered this paradox?
I wonder why NIST could not offer a financial award (let's say $500k)
for the chosen team? In the bigger scheme of things, that's not a lot
of money for the governement, but enough money to motivate the best
teams, no?
hammer
In article <[EMAIL PROTECTED]>,
Serge Vaudenay <[EMAIL PROTECTED]> wrote:
.
> Actually, if an expert do not have any personal interest about AES, he
> should better wait
> for the final standard before doing some substantial work. In the
> meanwhile he can work
> for other standards.
>
> --
>
=======================================================================
> Professor Serge Vaudenay Add: EPFL/DSC/LASEC
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Fri, 21 Jan 2000 20:31:17 +0100
Paul Koning wrote:
>
> Mok-Kong Shen wrote:
> >
> > Serge Vaudenay wrote:
> > >
> >
> > > Actually, if an expert do not have any personal interest about AES, he
> > > should better wait
> > > for the final standard before doing some substantial work. In the
> > > meanwhile he can work
> > > for other standards.
> >
> > Very probably I misunderstood. But my (superficial) interpretation
> > of your sentence means that the AES winner would not have got much
> > study by the majority of the experts at the time point the winner
> > is declared to be a standard by NIST for use by people of the
> > whole world. That's pretty bad, isn't it?
>
> Yes, but is it true? Admittedly I'm only an interested amateur,
> but it sure looks like a significant number of the big names
> of (non-classified) cryptography are involved.
My interpretation of Prof. Vaudenay's sentence was that only a few
of the 'significant number of the big names' would have motivations
to really do hard analysis work on the forthcoming AES. That is,
the issue is not how many are involved 'by name' but how many are
involved in actually doing the 'unrewarding' job of heavily
attempting to attack that algorithm 'voluntarily'.
M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: McDonald's claims Nobel peace fries [off-topic]
Date: Fri, 21 Jan 2000 13:28:12 -0600
Paul Schlyter wrote:
> Conclusons? Will spreading atomic bombs to all countries help
> prompting worldwide peace? <g>
Yes.
Either we all die, or we quit fighting :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Fri, 21 Jan 2000 20:35:29 +0100
Hammer wrote:
>
> Hmmmm... I had not thought of this. It makes perfect sense though... I
> wonder if NIST considered this paradox?
>
> I wonder why NIST could not offer a financial award (let's say $500k)
> for the chosen team? In the bigger scheme of things, that's not a lot
> of money for the governement, but enough money to motivate the best
> teams, no?
Much better in my view would be financial awards for those who
obtain essential results on analysis of the algorithm(s).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: LSFR
Date: 21 Jan 2000 11:37:31 -0800
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> > "David Wagner" <[EMAIL PROTECTED]> wrote ...
> > : If I initialize the register with values that are all even,
> > : it stays this way.
>
> There should be some primitive polynomial even mod 10 that
> would give (10^n-1) elements. You'd have to start with an odd number tho.
I already disproved this claim. Primitive or not, you never get a
cycle that long. See above.
Hint: Let S be the set of register states where all values are even.
If you start out in S, you stay in S; if you don't start out in S, you
never enter S. Thus, the maximum cycle length is at most max(|S|,10^n - |S|),
and this is strictly less than 10^n - 1.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 20:56:23 +0100
Terry Ritter wrote:
>
> <[EMAIL PROTECTED]> wrote:
>
> >Could we perhaps say that the fundamental component of a stream
> >cipher is its key stream, which is commonly supplied by a pseudo-
> >random number generator etc., while a block cipher doesn't have
> >that (or at least doesn't have that explicitly).
>
> No, sorry. There supposedly is a class of stream cipher which appears
> to function somewhat like a digital filter (input plaintext, output
> ciphertext), and thus does not need or use a key stream, nor do they
> generate a keystream internally. Unfortunately, I have not seen a
> real example, and cannot imagine how any such approach could hope to
> be secure. Others who have seen actual designs have been convinced,
> however.
Your information is rather vague for me. Could you please give
literature references so that one could find more concrete stuffs
about that? I suppose one has to look into that 'black box' to see
what it really is.
> We could of course subdivide stream ciphers into keystream and
> filtering approaches. But in my view the reason for making categories
> is to provide insight into consequences of design, and I don't know
> the consequences here. So at this point the distinction seems rather
> meaningless.
I don't yet fully understand your sentences. You said on the one
hand that making a distinction 'provides insight into consequences
of design ' and on the other hand that you don't know the
'consequences'. Was that simply a paraphrase of 'making a distinction
is nonsense' or did you mean something quite different? (Sorry for my
poor English comprehension capability.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: simplistic oneway hash
Date: Fri, 21 Jan 2000 14:19:22 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I have what is probably a rather unusual request. I need a very simple
> to code and understand one-way hash. I don't care a great deal as to
> whether it is truly secure at all, as long as it can be implemented
> in no more than a couple dozen lines of code in Fortran 90.
>
....
> I have had some difficulty finding such a simple one-way hash. It
> seems that cryptographers aren't very interested in making cruddy
> algorithms just because they are simple (imagine that ;). I need
> an algorithm that fulfills the following requirements:
>
> 1) It must be simple to code (no more than a couple dozen lines)
> 2) It must be collision free
> 3) It must be relatively one-way (such that they won't be tempted to
> take a short-cut. we'll still look to make sure they really wrote
> they code, which is the most important part).
>
The cruddy response is that 2) and being a good hash, or perhaps even a
bad one, are inconsistent.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What's with transposition?
Date: Fri, 21 Jan 2000 14:15:00 -0600
In article <[EMAIL PROTECTED]>,
KitKat <[EMAIL PROTECTED]> wrote:
> Some time last summer I came up with my own nifty lil'
> transposition scheme and I thought it was pretty cool (off course: it's
> mine). I actually spent quite some time coding it. Picking up on
> cryptography and the like I recently bought Schneier brick "Applied
> Cryptography".
>
> He affirms (twice) that transposition is "as a general rule"
> easily broken. My first reaction, in its purest form, was something in the
> vincinity of "Dang it!". My problem is that he doesn't seem to explain why
> anywhere close to that statement. I'd like to have the explanation as to
> why transposition (-only) cryptosystems are easily defeated (as in: "no
> matter how "complex" your transposition scheme may look to you").
> Actually, information as to where to find extended e-litterature on the
> subject would be greatly appreciated!
>
>
> KitKat
> --
> I'd rather be coding;
First comment of mine, last of yours: Agreed. There is nothing a bigger
waste of time than messing with bureaucrats that know almost nothing about
what they are doing, as they have furthered their incommunication skills
to say little or nothing for extended periods of time in increasing
volumes of text, which has some sort of analog in extremely poor crypto.
Note, also these statements tend to be full of tarbaby references to other
such stuff. Thankfully, reality is a helpful notion that can be used to
test such stuff to uncover any goodness that might be hidden amongst the
grime of misdirected passions and motives, etc, etc, and etc.
Congratulations on playing with transposition. It can be lots of fun,
even the simple stuff, which is usually letters alone. Gwyn mentions bits,
but transposition can involve information units is any particular base.
Transposition is often a part of a larger system, a very common part of
many. Alone, can be weak, very weak.
Simple transposition by itself is reduced to a permutation of N-elements.
Clues as to related elements are the downfall of most such scheme,
especially those that only allow a few of the permutation possibilities;
exclude the impossible linguistic allowed arrangements, and you only have
one or a very few choices for solution.
If you are dealing with text, ascii is a poor choice since you can filter
out so many likely possibilities based on likely characters to be used.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 19:52:55 +0000
Paul Crowley wrote:
> CLSV <[EMAIL PROTECTED]> writes:
> > So it does pay to use a strong password. If you are not able to
> > communicate a 52-card key one time I don't believe you have any
> > chance to communicate securely.
> When you say "one time", you mean "once per message". If you're in a
No, I mean just once before encrypted communication starts.
Just like the scenario in your previous posting where two persons
meet and exchange a password.
Why do you keep insisting that exchanging a 225 bit password
is the same as exchanging a one time pad?
> position to communicate big strings of random nonsense once per
> message, you can use the most successful secure hand cipher in the
> world, the one time pad.
> On the other hand, six randomly-chosen six digit words can be
> memorised readily, and searches will not reveal them. If you use
There are ways to communicate a 52 card password
that don't draw suspicion. For example you could agree
on using the last 52 unique reverse digrams from a specific
article of the popular political journal "The Great Dictator".
> Diceware to generate them, this will give you 77.5 bits of entropy in
> your keyphrase - enough to keep even the best funded attackers off
> your back for quite a while.
I believe nowadays 80 bits is thought to be the bare minimum for
secure communication.
Regards,
CLSV
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: Publication Reference for Vernam Cipher
Date: Fri, 21 Jan 2000 15:13:32 -0500
Reply-To: [EMAIL PROTECTED]
On Fri, 21 Jan 2000 00:32:11 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>I don't know this story but one of similar nature. In the early
>years of research on machine translation of natural languages
>there was a demonstration by a team showing results of translating
>Russian into English with (at that time surprising) superb quality.
>It turned out that the texts output were translated by humans and
>stored in the computer.
>
>M. K. Shen
One of the classic stories about one of the early machine translation
programs is its translation into Russian of
"The spirit is willing, but the flesh is weak,"
and its subsequent translation of the resulting Russian text back into
English as
"The vodka is fine, but the meat is rotten."
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Fri, 21 Jan 2000 13:21:30 -0700
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> "John E. Kuslich" <[EMAIL PROTECTED]> writes:
>
> >These crypto regulations seem to have their basis in an emergency
> >executive order and based on treaty arrangements made by State
> >Department officials who may have exceeded their authority in binding
> >the US government to a set of international "arrangements" with regard
> >to the control of the sale of munitions.
>
> It was primarily the US who pushed for those arrangements.
Yes, precisely. Why????????????????????????
What earthly good do they do? (The geanie being out of the bottle etc.)
The government of Iran, for example, obviously can get any crypto they
want.
JK
>
> >I suggest that the Congress should re-establish it's rightful authority
> >to set the law of the land by merely passing a law prohibiting the US
> >government from regulating encryption period (except as to protect
> >national secrets relating to encryption used by our government).
>
> Unfortunately for your argument, Congress has shown little will to pass
> such a law, even though it has been suggested by some Congressmen. The
> regulation of both national security and of foreign commerce are well
> within the purvue of the Federal Gov't. Whether or not crypto should be
> regulated is thus a matter for debate and there is nothing self evident
> about it.
>
> Note that there are no regulations regulating crypto, only the export of
> crypto. And these executive orders are being promulgated under the guise
> of laws passed by congress authorising the Executive to establish such
> regulations.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 20:35:28 +0000
"r.e.s." wrote:
> It's simple to use a 4x13 card layout to implement the *exact* ARC4
> logic with state-vector length 52 (and modular addition combiner.)
> The only card-movement is the swap, which takes about 1 second, and
> the pointer(coin)-movement takes about 10 seconds for both pointers
> total. I can easily run off 14-15 letters per minute this way, so
> I think this version of "52 card ARC4" is faster than any other
> secure card cipher.
Please try it out before you make such claims
(as Paul Crowley remarked it *is* fun to do).
I think it can be fast given enough practice but
14-15 characters a minute, no way. That is 4
seconds for one encryption! On my first try I
achieved a speed of about one char in 50 seconds.
Regards,
CLSV
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Fri, 21 Jan 2000 13:42:37 -0700
There is a subtile point that is being missed here, I think.
It is best illustrated if you read the security faq for the Access
database on the Microsoft web site. It has all kinds of talk about
rights and ownership and access denial etc. That is the way it is
*SUPPOSED* to work.
Just one thing though, our AXcrak program bypasses all this security by
making relatively small changes to the executable code in the Access
security dll after it is loaded in memory. Since the DLL is loaded under
the same privileges as the Access executable, if the user has the
capability to execute Access code, he *SHOULD* be able to bypass Access
security.
Now NT is *MORE* secure against this kind of attack, but if a hacker is
able to gain access to kernel code by any means, the system will do
anything the hacker can imagine.
I have not actually tested this with a really locked down NT system and
it may be possible to put a more fine grained control under NT user
accounts to stifle this process. I don't know for sure.
JK http://www.crak.com Password Recovery software
"Trevor Jackson, III" wrote:
>
> Shawn Willden wrote:
>
> > Guy Macon wrote:
> >
> > > A normal NT installation does not give
> > > ordinary users debugging rights. or access to certain portions of the
> > > disk (and you can add your crypto directory to the portions that
> > > ordinary users cannot access).
> >
> > Can an NT installation be set up such that some files are not accessible even to
>the
> > Administrator? For an system I'm building, I'm seriously considering locking out
>the
> > Administrator account.
> >
> > Shawn.
>
> It is not possible to prevent an administrator who wants to gain access from gaining
> access. You can require the administrator to perform an audit able action (take
> ownership) in order to gain access.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Calculating A^-1 Mod P
Date: Fri, 21 Jan 2000 20:47:56 GMT
In article <86a6rp$[EMAIL PROTECTED]>,
"HRook" <[EMAIL PROTECTED]> wrote:
> I'm trying to teach my self the rudiments of Elliptic Curves. I
noticed that
> when adding two points together, one of the calculations is x3=
> ((y2-y1)/(x2-x1))^2 - x1 - x2 MOD P
>
> This leads to the question, "How does one divide by (x2-x1) MOD P. I
assume
> the answer to that is "multiply by (x2-x1)^(-1) mod P.
Correct.
>
> So, how do you calculate A^-1 Mod P. I have a vague memory that the
Extended
> Euclidian algorithm can do this
Correct. Look up the "Extended Euclidean Algorithm" in Knuth Vol 2.
Chapter 4.
Note also that a^(p-1) = 1 mod p, so a^(p-2) = a^-1 mod p is an
alternate method.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
