Cryptography-Digest Digest #535, Volume #9 Wed, 12 May 99 14:13:03 EDT
Contents:
Re: Books ("Douglas A. Gwyn")
Re: Lemming and Lemur: New Block and Stream Cipher ([EMAIL PROTECTED])
Re: Hello I am paper, please read me. (SCOTT19U.ZIP_GUY)
Re: Newbie: Encrypting short strings (David A. Scott)
Re: Hello I am paper, please read me. (Paul Rubin)
Re: Newbie: Encrypting short strings
Re: Hello I am paper, please read me. (Jim Felling)
Re: Newbie: Encrypting short strings (Jim Felling)
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Re: Crypto export limits ruled unconstitutional ([EMAIL PROTECTED])
Re: Hello I am paper, please read me. (wtshaw)
Re: Searching for algorithm overview (Medical Electronics Lab)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Books
Date: Fri, 07 May 1999 06:41:42 GMT
John Savard wrote:
> Thus, I found it was worth another look, but I wouldn't expect any
> "earth-shattering revelations" from a book that, by its nature, went
> through a careful official approval process.
The real reason it doesn't have "earth-shattering revelations" is
that basically it's just an intranet, which is pretty ho-hum.
The only really interesting thing about Intelink is the "content".
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Lemming and Lemur: New Block and Stream Cipher
Date: Wed, 12 May 1999 15:04:15 GMT
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> How do you decrypt?
Decryption is just like encryption, except you build the key
using the inverse of the permutation, and do all the operations
in the reverse order:
TO DECRYPT A BLOCK ENCRYPTED WITH LEMMING:
for (i=0; i<32; i++) {
block = backwardsRotate(block)
block = block ^ inverseKey[block[0]]);
}
where backwardsRotate moves block[1] to block[0], and inverseKey
is the same as key, except the inverse permutation is used.
The key was defined as:
TO GENERATE A NEW KEY:
perm[0..255] = random permutation of the bytes 0 to 255
key[i][0] = i XOR perm[i]
key[i][1..15] = 15 random bytes
so the inverse key can be generated as:
TO GENERATE THE INVERSE KEY:
inversePerm[0...255] = the inverse of perm[0...255],
so for all x: x==perm[inverseperm[x]]
inverseKey[i][0] = i XOR inversePerm[i]
inverseKey[i][1...15] = key[i][1...15]
Note that key[i][0] does *not* hold a permutation. It holds a
permutation XORed with the index "i". That means that the XOR
step in Lemming just replaces block[0] with perm[block[0]]. This
operation is invertable because perm[0..255] is a permutation of
the bytes 0...255. Also notice that when the identity
permutation is used, you get key[i][0]=0 for all i. This
simplifies key generation and may weaken the cipher, though I
don't see an attack that could exploit it.
As I said before, in practice the 4KB "key" would be created from
a shorter key or passphrase. Think of it as being like a
key-dependent S-box. That would be important in practice, since
the current algorithm looks susceptible to related-key attacks if
the keys don't come from a TRNG. For simplicity, it may be
useful to first analayze this simpler algorithm before worrying
about the best way to generate "key".
LCB
[EMAIL PROTECTED]
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Hello I am paper, please read me.
Date: Wed, 12 May 1999 15:12:25 GMT
In article <7hbolo$s32$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> <snip>
> Reply to the thread.
>
> Ok well here is the URL, I don't have a website for it yet...
>
> http://members.tripod.com/~tomstdenis/TwoDeck.ps
>
> I also have the sketches for effort/solutions in a sieving attack.
>
> http://members.tripod.com/~tomstdenis/solution.ps
>
> I will build a website where this can be found later.
>
> to Jon: Well I will read your papers tonight (have to goto school...)
> and I will see what I can find. However you have 5 ciphers (1 to 5
> right?) and I have only the TwoDeck :)
>
> Thanks for your time,
> Tom
>
Tom the big boys like "*.ps" however I can't read or
write *.ps files. The AES thing wanted things in ps
but I think they should have also accept ascii files.
But then again the contest is mostly likely a rigged
contest anyway. If you ever want me to look at it.
Make it ascii or HTML. I don't bother with anything
else. I also don't have buggy things like micoshaft
word on my machine either.
Thank You
David A. Scott
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
>
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (David A. Scott)
Subject: Re: Newbie: Encrypting short strings
Date: Wed, 12 May 1999 16:58:23 GMT
In article <7hc50m$k2f$[EMAIL PROTECTED]>, "Steve K" <[EMAIL PROTECTED]>
wrote:
>Hey all,
>
>I am looking for an algorithm that will be suitable for encrypting (and
>decrypting) short strings around 3 to 10 characters in length. I would like
>the encryption function to produce a string of alphanumerics of maybe 20
>characters, and have the requirement of similar inputs producing wildly
>different outputs (for example, an input of 34532 would produce a cyphertext
>that is very different than the input of 34533).
>
>The application here is to obfuscate database ID numbers that will be
>exposed on a web page. I am trying to prevent users from trying to tweak
>these ID numbers by changing a single digit in order to try to get access to
>records that shouldn't.
>
>Any help would be appreciated. I have the "Applied Cryptography" book, so
>if there are any relevant chapters in the book, please let me know.
>
>Thanks!
>-steve
>
>
>
Steve if you pad to a fix length with blanks
and then use SCOTT16U.ZIP with option that adds random padding
you can get fixed message length that even for the same message
will be totally different. If 20 charactes out is not what you want you
can make it 21. I think you need my software it comes with source
code and is in C so you can change it as you see fit. The readme
file is not very good. But the source code ans a PC executable is
all there.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Hello I am paper, please read me.
Date: Wed, 12 May 1999 16:30:33 GMT
In article <7haf8g$rs7$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Sorry if the title is mean, but what's up?
It's been explained to you many times already. yawn.
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Newbie: Encrypting short strings
Date: Wed, 12 May 1999 18:33:33 +0200
On Wed, 12 May 1999, Steve K wrote:
> Hey all,
>
> I am looking for an algorithm that will be suitable for encrypting (and
> decrypting) short strings around 3 to 10 characters in length. I would like
> the encryption function to produce a string of alphanumerics of maybe 20
> characters, and have the requirement of similar inputs producing wildly
> different outputs (for example, an input of 34532 would produce a cyphertext
> that is very different than the input of 34533).
>
> The application here is to obfuscate database ID numbers that will be
> exposed on a web page. I am trying to prevent users from trying to tweak
> these ID numbers by changing a single digit in order to try to get access to
> records that shouldn't.
So you'll have to encrypt a huge number of short strings?
Is it a problem to enlarge the strings to get a multiple of 8 byte?
If not: Use a blockcipher in ECB mode.
Else: Are the IDs in a constant order that won't ever change?
If yes: Encrypt them with a blockcipher in OFB- or CFB-mode.
Else: Is it possible to associate the ID with another number?
If yes: Encrypt them in counter mode.
Else: You'll have to enlarge the ciphertext to a multiple
of 32 bit and encrypt it using WAKE or a similar
cipher.
>
> Any help would be appreciated. I have the "Applied Cryptography" book, so
> if there are any relevant chapters in the book, please let me know.
Blockciphers: blowfish (very slow key shedule!) or CAST128. Both are vewry
fast on 32bit processors. I don't know any ciphers that were
developed for 64bit processors, so you'll have to use these
ones even if your database works on 64 bit computers.
There is a description of WAKE in AC2. You shouldn't use this cipher
except there is really no other way.
>
> Thanks!
> -steve
>
>
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hello I am paper, please read me.
Date: Wed, 12 May 1999 12:13:30 -0500
Your algorithm is vulnerable to a fairly trivial attack unfortunately.
Given Deck A and Deck B this is exactly equivalent to a completely ordered
deck A' , and B' being the result of taking card B(A(1)) and so on.
So then the algorithm evolves as follows given a key set (A,B)
Encode message M= N 0's.
M will encrypt to give you an exact list of the makeup of B'.
Once this is known all messages from this key are compromised.
Given a cyphertext --.the first N digits decrypt exactly by X or with B',
next N digits may be either brute forced by trying all N possible shuffles
-- this should yield recognizable plaintext only with a very few tries(and
thus R), or by guessing the next likely character and identifying which
element of B' must have been used to generate it( thus allowing the trivial
determination of R).
Similarly the revealing that characters k*n+1 to (k+1)*n decrypt to M will
allow the whole string from start to finish to be decrypted with little
effort.
Reshuffling B as well will improve security, but will also fall to a
similar but more time consuming attack. Reshuffling after R<N turns will
help, but will still compromise the algorithm's first R characters.( at
best) and probably allow an analyst to maker progress against the code.
[EMAIL PROTECTED] wrote:
> Sorry if the title is mean, but what's up?
>
> I wrote the paper on TwoDeck, and nobody even comments on it... That's
> because I am a newbie right? Well what if I showed some initiative and
> *wanted* to improve? Will anybody help? Not likely. Why because I am
> a newbie. That's not really fair.
>
> Well for you professed geniouses share in your basking knowledge. I
> just want a little help (perhaps guidance) in writing this paper. I
> think it can be solved (maybe faster then brute force), I even have
> ideas for the attack. But I need help, suggestions, etc...
>
> My paper is not that long, it's only 11 pages. I want to add more
> analysis, and as stated earlier make it more professional. I can't do
> this alone. So I am asking, once again for any help.
>
> I mean common, who is 'Dave Scott' or 'Jim Felling' anyways? Just
> people in the group. They post, and others post back. I am the same.
> Ok, I started off roughly, but I have learnt quite a bit, and I am
> trying to put something together.
>
> Anyways, can somebody please read the paper, or why else do people post
> here? I mean every member could write a paper, but if nobody read
> them, what's the point?
>
> Thanks,
> Tom
>
> --
> PGP public keys. SPARE key is for daily work, WORK key is for
> published work. The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Newbie: Encrypting short strings
Date: Wed, 12 May 1999 12:20:02 -0500
A secure hash will have the properties you look for --just pad with nulls out
to the block length and hash -- this will generate (assuming a 128 bit hash) a
map to 16 characters (not precisely what you are looking for, but should be
close -- esp if you uuencode or otherwise force the data to 7-bit chars.
Steve K wrote:
> Hey all,
>
> I am looking for an algorithm that will be suitable for encrypting (and
> decrypting) short strings around 3 to 10 characters in length. I would like
> the encryption function to produce a string of alphanumerics of maybe 20
> characters, and have the requirement of similar inputs producing wildly
> different outputs (for example, an input of 34532 would produce a cyphertext
> that is very different than the input of 34533).
>
> The application here is to obfuscate database ID numbers that will be
> exposed on a web page. I am trying to prevent users from trying to tweak
> these ID numbers by changing a single digit in order to try to get access to
> records that shouldn't.
>
> Any help would be appreciated. I have the "Applied Cryptography" book, so
> if there are any relevant chapters in the book, please let me know.
>
> Thanks!
> -steve
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Wed, 12 May 1999 17:20:40 GMT
"R. Knauer" wrote:
> On Wed, 12 May 1999 06:07:42 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >Who cares why he says that, it's not relevant.
> Are you saying that Feller does not know what he is talking about?
No, I'm saying that you don't. You keep harping on this one point
even though it has nothing to do with the test you were criticizing.
> >The Monobit Test checks the first moment of the distribution,
> I think you need to demonstrate that formally.
I don't think so; it's obvious.
> I would not assume he is a bad salesman until he turned in several
> poor performances. One bad year does not make a poor salesman.
To continue the analogy, your company could be out of business by the
time you demonstrated to your satisfaction that Jones really was not
performing adequately.
> >> ... How can Jone's poor earnings be a reflection on the typical
> >> earnings of the vast majority of salesmen?
> >Of course, it isn't -- it reflects only on Jones.
> Then one "abnormal" sequence cannot reflect on the TRNG's
> performance either.
That's a nonsequitur. The analogy is
salesman in general ~ RNG in general
Jones ~ specific instance of a RNG
So the abnormal sequence *does* reflect on the specific instance of
a RNG. (It says that the specific instance might be malfunctioning.)
> Nonsense. You can buffer and test - memory and disk space is cheap.
Not when, as is usually the case, the specific key is not known until
the time of encryption.
> >The *reason* the methodology works is because the computed statistic
> >is essentially an indicator of membership in a *class* of samples,
> >and those classes have different relative sizes, thus differing
> >likelihoods.
> That is an expression of the central fallacy here. You believe that
> one sample such as 20,000 bits taken by itself can be representative
> of a complete distribution of samples. That is fallacious, as Feller
> and others have pointed out.
What I said is not fallacious; it is central to statistics.
Your incorrect statement of what I believe is what is fallacious.
> I have used the term "reasonable certainty". Likelihood is a fiction
> from probability theory.
Oh, so now probability theory is fictitious, too?
It is amazing how much smarter than everyone else you are.
> The alarms have to be based on something in the real world and not
> some fallacious notion about what should be happening.
Of course *nothing* should be based on "some fallacious notion".
But since there is nothing fallacious about statistical testing,
this too isn't relevant.
> Just because a TRNG *should* output sequences with small bias does not
> mean that any given sequence must be of low bias.
But it does mean that a very high degree of bias is a sample is
evidence for the hypothesis that the generator is broken. If you
have substantially higher evidence from other sources *at the same
time* that the generator is *not* broken, then that would offset
the evidence from sampling. But that is not the case for the
FIPS-140 tests.
> My objection is that you cannot infer the properties of the TRNG from
> one sequence, which is what the Monobit Test is attempting to do.
To repeat yet again a point that you continue to ignore, the FIPS-140
Monobit Test exists only to raise a flag when there is a substantial
likelihood that the generator has broken down and is not outputting
a sufficiently secure key stream. It must raise that flag immediately
upon detection of the possible fault, with a latency of not more than
20,000 bits, that being deemed the maximum amount of broken key stream
that could be tolerated. It must not give false alarms more than once
per 20,000,000,000 key bits, on average.
If you dispute that the test accomplishes the above, you should
explain where it fails. Otherwise, it doesn't much matter whether
you personally like the test, if it accomplishes what it is meant to.
------------------------------
Date: Wed, 12 May 1999 13:34:03 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: Crypto export limits ruled unconstitutional
R H Braddam wrote:
>
> Is _any_ piece of text "runnable" on a computer? I
> haven't heard of any processor that has an instruction
> set based on text, but my experience is limited in that
> area. The only interpreter I'm familiar with does some
> pre-processing of the input before running it, then
> translates the preprocessed input as it progresses
> through it.
While there is no interpreter for the language "text" that I know of, we
can approximate it as closely as is desrired.
Start with a source code for a runnable program in a classical,
procedural language, say Algol or C. Write an expander that translates
the computer language to English in the same way there are expanders for
numbers that produce the "name" of the number. Then write the inverse
program that translates the English version back into the source code.
The English versions may be exportable.
Step two is to enhance the expander/interpreter pair to include
non-procedural languages ( e.g., prolog, lisp/scheme, parallel equation
languages, etc.) At some point in this enhancement process you'll get
to text indistinguishable from English (except that it can be
interpreted/compiled back into "runnable" source code).
Certainly such text is exportable.
In a sense this is a form of automated steganography applied to source
code.
Since some of modern steganography uses the low order bits in imagery to
hide text, let's invert that. In order to avoid obecenity charges ("I
know it when I see it"), we could provide a detailed text description of
an image. If the anatomical terms were translated in to medical Latin
it would probably pass as non-obscene.
Of course at the receiving end an automated picture parser could
reconstruct the images with more or less lossy results according to how
much expansion was tolerable from the binary image to the text
description hiding it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Hello I am paper, please read me.
Date: Wed, 12 May 1999 12:02:26 -0600
In article <7hc5oj$87q$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
<[EMAIL PROTECTED]> wrote:
> In article <7hbolo$s32$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > <snip>
> > Reply to the thread.
> >
> > Ok well here is the URL, I don't have a website for it yet...
> >
> > http://members.tripod.com/~tomstdenis/TwoDeck.ps
> >
> > I also have the sketches for effort/solutions in a sieving attack.
> >
> > http://members.tripod.com/~tomstdenis/solution.ps
> >
> > I will build a website where this can be found later.
> >
> > to Jon: Well I will read your papers tonight (have to goto school...)
> > and I will see what I can find. However you have 5 ciphers (1 to 5
> > right?) and I have only the TwoDeck :)
> >
> > Thanks for your time,
> > Tom
> >
>
> Tom the big boys like "*.ps" however I can't read or
> write *.ps files. The AES thing wanted things in ps
> but I think they should have also accept ascii files.
> But then again the contest is mostly likely a rigged
> contest anyway. If you ever want me to look at it.
> Make it ascii or HTML. I don't bother with anything
> else. I also don't have buggy things like micoshaft
> word on my machine either.
>
Text is a nice format, pretty old and almost universally understood if you
know how to read. If you have something long, break it into parts for easy
consumption.
It is not impressive to pick a format that some cannot handle. To get the
most to see something, you should pick something basic. If you are trying
to impress people, being utilitarian should be a good start.
Have you seen various html pages in different browsers, some look horrible
in one and good in another. If fundamental communication is your goal,
cut the geegaws and frills, and stick to vanilla.
--
What's HOT: Honesty, Openness, Truth
What's Not: FUD--fear, uncertainty, doubt
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Searching for algorithm overview
Date: Wed, 12 May 1999 12:44:40 -0500
Jonas Krantz wrote:
> I am a student at the Royal Institute of Technology in Stockholm, and I am
> examining possible ways to secure a wireless network with internet access
> from an ISP point of view. I have been looking at some IPsec solutions which
> use different kinds of algorithms for encryption and authentication.
> I have looked at many different algorithms, but I find it hard to evaluate
> them. What are their strength and what are their weaknesses. Which ones are
> better, and which ones are cracked.
> Does any one know if there are an overview over the different algorithms on
> the net, where they are compared with each other?
Not online. "Applied Cryptography" is encyclopedic and will give
you the overview you want. There are over 1000 references so you
can get all the details by chasing them down in your university
library. What you find online is mostly advertising. That won't
help you much.
But once you have an overview, you then have a harder problem.
Some protocols and algorithms work in specific situations and not
others. It's hard to compare them if you don't know what situation
you'll be applying things to. You'll have to break up your problem
into several sections and then make comparisons between things
that make sense in each section.
Your task is not simple. Good luck!!
Patience, persistence, truth,
Dr. mike
------------------------------
** 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
******************************
