Cryptography-Digest Digest #577, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: One Time Pads Redux (Dan Day)
Re: Fighting fire with fire: using encryption to bust encryption [0/2] (John Savard)
Re: $100 Code Challenge (Dan Day)
Inverse of Permutation polynomials ([EMAIL PROTECTED])
Re: Miami Herald article about ATM ripoffs (Dan Day)
Re: Proving that you are who you say you are (Dan Day)
Re: Why encrypt email... (Dan Day)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: Proving that you are who you say you are ("Joseph Ashwood")
Re: password generator ([EMAIL PROTECTED])
Re: Books on maths behind NFS ([EMAIL PROTECTED])
Re: Very Large S-Boxes VLSB's ([EMAIL PROTECTED])
Re: password generator ([EMAIL PROTECTED])
Re: updated paper on easy entropy (Francois Grieu)
Re: password generator ("Joseph Ashwood")
Re: BS on AES3 (from the latest Cryptogram) (Mark Wooding)
Re: Very Large S-Boxes VLSB's ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: One Time Pads Redux
Date: Wed, 19 Apr 2000 05:09:45 GMT
On 17 Apr 2000 04:58:57 GMT, Joaquim Southby <[EMAIL PROTECTED]> wrote:
>
>This scheme wasn't just broken, it was drawn and quartered. It was
>humiliated; it was pantsed in front of the school assembly. It was bent
>over the portside rail and rogered mercilessly by the one-legged third
>mate. If this were a prison movie, this scheme would be the villain's
>bitch. It eats bugs, and not the protein-rich kind, either. It rode the
>short bus to school, clad only in diapers and a dunce cap.
ROTFLMAO! I found this entire post to be hilarious, and enjoyed it
greatly. It's also a marvelous example of how to say "oops" in a
very gracious, and entertaining, manner.
>To give full credit to my muse of obtuseness (obtusity?), I actually
>pondered this atrocity for TWO DAYS before posting. I examined the most
>esoteric of attacks while missing the most obvious one. ("It's been
>enciphered by an OTP, so the message itself is safe...right?")
Ah, but you forgot what the "O" in "OTP" stands for... In your
scheme, Bob uses his pad twice, and thus violates the very thing
that makes a true OTP secure. (Not to mention the, um, unconventional
step of allowing the adversary to see both the pre-encryption, *and*
the post-encryption datastreams...)
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fighting fire with fire: using encryption to bust encryption [0/2]
Date: Wed, 19 Apr 2000 04:26:49 GMT
On Tue, 18 Apr 2000 15:40:40 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Gideon Samid wrote:
>> Similarly, given a set of ciphertexts C1, C2, C3... one could iteratively
>> look for a key K such that the corresponding plaintexts P1, P2, ... will
>> be increasingly non-random.
>How does one do that, pray tell?
In my post "The Relaxation Method", I hazard a guess. Although I'm
pretty sure the method I mention there won't work.
Essentially, one can always, just by manipulating 32 bits in each of
two consecutive subkeys, produce any plaintext from any ciphertext.
So, given a known plaintext and ciphertext, do this repeatedly (only
for odd-even subkey pairs), then copy the changed bits into the 56-bit
key, modifying the rest of the subkeys, and repeat for a different
pair.
One might hope it might somehow converge on the right key, or the bits
that don't need to be changed as often are more likely to be right, or
something like that. Perhaps the method can be improved and made into
some kind of usable attack.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: $100 Code Challenge
Date: Wed, 19 Apr 2000 05:26:09 GMT
On Fri, 14 Apr 2000 21:49:48 GMT, [EMAIL PROTECTED] wrote:
>The following is a message encoded using a new routine I have designed.
>The text is a written message in English. In order to test just how
>strong the encryption is, I have posted it here for anyone interested
>to try to crack it. The first person to successfully crack it will get
>$100. Seriously, $100, no kidding.
Okay, who besides me is reminded of Dr. Evil's line in Austin Powers,
where he threatens to blow up the world unless he is paid the
enormous sum of "one...million...dollars"?
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED]
Subject: Inverse of Permutation polynomials
Date: Wed, 19 Apr 2000 05:27:28 GMT
Reading all the messages from Tom about permutation polynomials mod
(2^w), I couldn't help but get interested in the subject. He seemed to
have so much fun with those polynomials. :-)
Anyway, he had a question about the inverse of these polynomials. I
suspect he doesn't need them anymore, but I've got a not-so-elegant
solution, and I want to commit them to the net-memory before I throw
away my notes. Who knows, someone may use them in the future.
The first logical question to ask when trying to invert these
polynomials is: is there an inverse permutation polynomial for all
possible permutation polynomials. The inverse of the permutation
polynomial is a permutation itself, so the quick (and lucky) answer is
yes. Lucky, because although there is not a polynomial for each
permutation, the inverse permutation of a permutation polynomial also
satisfies the only (meaning the only one I could find) requirement P
(x+m)=P(x)+m, for a permutation polynomial to exist.
Now, how do we go about constructing our p.poly. inverses? More
important, what do I mean by an inverse in the first place? The inverse
I am going to construct is for the substitution operation. i.e. if P(Q
(x)) == x for all 0<=x<2^w, for permutation polynomials P and Q, then P
is the inverse of Q. P and Q normally do not commute, so it is a bit
dangerous to say Q is also the inverse is P, but I suspect that it is,
so I'll say it anyway. :-)
In order to construct the inverses, I start with an inverse modulo 2,
modify it to make it also an inverse modulo 2^2, and keep it modifying
until I get the inverse modulo 2^w. So it is a w step process to
construct the inverse.
What we do is, given Qk(x) which is an inverse of P(x) mod 2^k, find a
zero polynomial Zk(x) mod 2^k, and add it to Qk(x) so that Qk+1(x)=Qk(x)
+Zk(x) is the inverse of P(x) mod 2^(k+1). Easy? Nope. It is usually a
tedious process to construct these Zero polynomials, and find the right
one. I will not go out and prove that this method will work (you can
use the Lemmas in the Permutation Polynomials paper of Rivest to do so).
Instead, I will explain the inversion with an example polynomial, P(x)
=2*x^2+x mod 2^w.
But before that, let me give a parametrized class of zero polynomials
mod 2^n, which have been quite handy in the process of generating
inverses.
Z(x, a, n, q(x)) = q(x)*[2^(n-a)]*x*(x-1)*(x-2)*...*(x-2*a+1) = 0 mod
(2^n).
Why? for 0<=x<=2*a-1, Z is zero because each multiplier becomes zero at
each x value. For 2*a-1<x, we have exactly a even terms, and a odd
terms. The multiplication of 2^(n-a) and 2^a (coming from the even
terms) gives us the much sought after 2^n, which is zero.
OK. Back to the example:
P(x) is our polynomial, and Qi(x) is the inverse of P(x) for modulo 2^i.
* Since P(x) mod 2 is x, Q0(x)=x. [the only possible alternative for
other polynomials is x+1]
* Then P(Q1(x)) == 2*x^2+x mod (2^2), and Zi(x)=2*x=0 mod 0, so I can
add that to Q1(x) to get Q2(x)=3*x, and
P(Q1(x))=2*x^2+2*x+x==2*x*(x+1)+x==2*x*(x-1)+x==Z(x, 1, 2, 1)+x==x mod
4.
* n=3: P(Q2(x))=2*9*x^2+3*x==2*x^2+3x=x+2*(x^2+x) mod 8. Add 2*x*(x+1)
as the zero poly. to get Q3(x)=2*x^2+5*x
As you gues, it gets harder, and harder to collect to terms as you
increase the powers of 2. I calculated 2 more terms in this series to
get:
mod=2^4 => Q(x)=6*x^2+9*x [with Z(x)=4*x^2+4*x]
mod=2^5 => Q(x)=14*x^2+17*x [with Z(x)=8*x^2+8*x]
Well, that's all folks. If you are interested, and I messed something
up above, just give me yell. I'll try to fix what I've got.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Miami Herald article about ATM ripoffs
Date: Wed, 19 Apr 2000 05:41:42 GMT
On Wed, 12 Apr 2000 02:59:57 GMT, [EMAIL PROTECTED] wrote:
>
>The practice of storing the PIN Offset on the card is a relic of the
>old days where PIN Verification is done at the ATM and not at the Host.
A more direct way to hack ATM machines, and one directly relevant to
"alternative decryption" techniques discussed in this newsgroup,
was one used by some high-tech thieves a number of years ago.
They rigged up a fake ATM machine, mounted it in a little
standalone plywood kiosk, and set it up in a plausible location.
Every time someone tried to use it, they'd put in their card,
get prompted for their PIN number, the machine would say "please
wait" for a few seconds, then say "unable to contact your bank,
please try again later". The "customer" did not find this
at all suspicious, and simply went elsewhere.
What it was really doing was recording the information off the
magnetic stripe on the card (via a PC hidden in the fake ATM) and
remembering the accompanying PIN number which the "customer" had
so helpfully entered. After a few days the thieves read out
the information from dozens of cards, used a card writer to
create their own cloned copies of the customers' ATM cards,
and then used them (along with the recorded PIN numbers) to
clean out those bank accounts.
Set up fake ATM in new location and repeat.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Proving that you are who you say you are
Date: Wed, 19 Apr 2000 05:56:21 GMT
On Wed, 19 Apr 2000 00:07:41 GMT, [EMAIL PROTECTED] wrote:
> However, I'm concerned about two things. First, if I
>distribute an application with a key, won't it be rather easy for a
>person with malicious intentions to get ahold of the key and then spoof
>being the real client? Should I encrypt the key?
First question: Is it possible that someone might grab a copy
of the client itself? If so, there's very little you can do to
prevent spoofing. Even if for some reason the spoofer can't
just use the pirated copy of the client, he'd still be able
(in theory anyway) to take it apart and see what makes it
tick, which then gives him everything he needs to write his
own "spoofer" client that does all the proper things to
tell your server, "it's okay, it's me, the One True Client..."
If a spoofer *can't* get a copy of the actual client for
some reason, then the job of making a "traffic analyzer only"
attack infeasible becomes much, much easier, because then
your problem reduces to a standard "encrypted traffic"
problem, for which there are many suitable solutions.
Is your problem really one of *client* authorization, or
*user* authorization? If the latter, it's (relatively)
trivial to thwart a spoofer by simply making sure that
you only give the encryption passwords to authorized users,
who have to enter them before they can use the client --
that way no one can succeed by stealing a copy of the client,
because the passwords aren't stored in the client, they're
stored only in the head(s) of the authorized user(s).
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Why encrypt email...
Date: Wed, 19 Apr 2000 06:21:34 GMT
On Sun, 16 Apr 2000 21:07:55 +0100, David Crick <[EMAIL PROTECTED]> wrote:
>
>> Much email is non-sensitive info so encryption is not used.
>
>There is no reason why you should not encrypt everything.
Sure there is -- the fact that most of my intended recipients
would not be able to read it!
In order to "encrypt everything", every recipient would
have to have a matching decryption program, *and* we would
have to exchange keys prior to exchanging any email messages.
Until that (unlikely) day, a desire to "encrypt everything"
smashes up against the annoying reality of having to poll every
new email contact with a "do you have the ability to decrypt
protocol X, and if so could you send me your public key?" message.
It's simpler to just throw up your hands and send all but the
most sensitive traffic (or traffic between you and your
regular encryption-fan buddies) as plaintext.
*That* is the biggest hurdle to "ubiquitous encryption".
What's really needed for ubiquitous encryption (and what
will probably never exist) is an email protocol that
will TRANSPARENTLY query an intended recipient's email
server for his public key, and then transparently either:
1. If a public key exists, encrypt the message and
send it, and cache the public key for future
use (tagged with a reasonable expiration date,
*and* a way for messages sent with a cached but
now expired public key to be auto-bounced back with
an appropriate message), or
2. If no public key exists, prompt the sender whether
he wants to send the message as plaintext, or
abandon the attempt (this could be set to
default to a desired yes/no action).
And in any case, the receiving email system should
decrypt "on-the-fly", with the recipient seeing nothing
out of the ordinary except for a "this message was sent
with encryption" flag on it so that he can know which
incoming messages were potentially secure or not (similar
to the little "lock" icon that a browser shows to indicate
a secure web connection for the current page).
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Tue, 18 Apr 2000 23:37:29 -0700
Bo Johnson wrote:
>
> A.S. Wrote:
> >I am glad to say that lots of people from the US and Canada have
> >gotten the OAP-L3 software, and now many people from all over the
> >world have gotten the OAR-L3 software, too.
> >
> >They just emailed me or pointed and clicked. Didn't bitch once
> >about the web site. Just made a decision and got the software.
> >It's all very simple and straight forward. It's easy when you
> >know what you want.
>
> "Nobody ever went broke by under-estimating the intelligence of the average
> American." - Eddy The Snake
>
> "Just because snake oil sells doesn't prove it cures cancer." - The Surgeon
> General
>
> Taneli issued you a challenge that he could prove a weakness in your
> generator if you would post the data he requested. The fact that you backed
> down from the challenge strongly suggests to this here novice that you're
> just plain yaller. (That means a coward for you yankees out there.)
>
> I don't know shit about crypto, but from reading your responses I'm pretty
> sure you don't have the balls to post your algorithms, properly document
> your theory, provide sample data or do any of the work that it would take to
> get the brilliant people on this forum to be impressed by your cipher.
>
> The number of hits on your website or the fact that Joe Schmoe buys your
> software without asking any questions and hasn't complained doesn't prove
> anything other than the fact that Joe Schmoe wants to buy some crypto and
> believes your claims because he is too lazy or uneducated (like me) to
> analyze the info on your help files.
>
> The funny thing about weak crypto is that you can use if for years without
> knowing it's weak. And your enemies could be intercepting and cracking it
> for years without you knowing it. So just because none of your buyers has
> complained yet doesn't prove it's strong. It only proves that they have
> been lulled into a false sense of security by purchasing a product that
> makes unsupported claims.
>
> Bring in the cavalry. If all these people are downloading and analyzing
> your software, ask one of them to post on this forum how great it is and
> invulnerable to attack and how they can possibly know so. If you can show
> uneducated me that somebody with a brain has analyzed your algorithms and
> proved that they are strong in theory and in practice, then I might buy it.
>
> As it is you are just bragging and insisting that we trust you that it's
> secure because you said so.
>
> The builders of the Titanic thought it was invulnerable to any known attack.
> Their theory was strong. History showed them wrong.
>
> If you are a good business man you will take the time to prove to your
> critics on this forum that your cipher is strong by providing them with the
> documentation they are asking for. If you don't, word will eventually get
> out and nobody who knows anything about crypto will buy your shit.
You don't need me for this.
The software is available at http://www.ciphile.com
A professor would give such a chore to one of his undergrad
students. Any of you can do it. Why don't you?
As I stated before, if I give you the output of the random digit
generator as currently implemented, tell you that the output begins
with no rotation, that the usage is zero, that the length of the
MixFiles is 3,628,800 arrays long, that the output begins with the
first possible output digit (no offset), etc., basically giving you
all but the the key itself, then you determine the array sequences,
big deal: IT IS IMMATERIAL to the cracking of any OAP-L3 encrypted
messages.
Mr. Husskonen has said as much.
Although for documentation and characterization of the OAP-L3
software, Mr. Huuskonen may be able to show something interesting
but inconsequential.
I don't have any more time. I am half way through the
implementation of Version 4.3
Then I am going to proceed directly to version 5.0
Version 5.0 will provide for secure encryption directly from the
random digit / triplet generator itself.
This will provide for encryption-on-the-fly: you will have no need
for OTPs if you so choose.
With only 2920 data bytes you will be able to generate 9.2E15 random
numbers from 0 - 255 with a security level equivalent to 2000 bits;
or with only 4600 data bytes you will be able to generate 2.3E17
random numbers from 0 - 255 with a security level equivalent to
10,000 bits;
or with only 1,271,000 data bytes (fits on one floppy) you will be
able to generate 1.3E36 random numbers from 0 - 255 with a security
level equivalent to 100,000 bits.
or more AND more.
I think this could be of much interest for those interested in
Secure Electronic Transfer.
I hope no one loses any sleep over what's coming.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Proving that you are who you say you are
Date: Wed, 19 Apr 2000 00:00:32 -0700
I know people have replied, but there may be more. What
kinds of threats are you trying to protect from? If your
client and server and benign or better (including the
media). However if either your client or server is hostile,
there is no possible way to protect it. A starting point for
your protocol is:
public_key_encrypted_to_server
{
userID
challenge1
Key1
}
server decrypts replies with
public_key_encrypted_to_client
{
challenge1
challenge2
Key2
}
Key1 is used to encrypt data from client to server
Key2 is used to encrypt data from server to client
If challenge1 is not echoed back correctly the server is not
authentic
Client encrypts challenge2 using Key1 and sends it to the
server
Both client and server are authenticated, and 2 session keys
have been established.
Inside of that use whatever you want.
Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: password generator
Date: Wed, 19 Apr 2000 07:55:00 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Tom St Denis wrote:
> Got bored this afternoon so I wrote a password generator using the
> windows timer rng idea.
>
> You can get the source at
>
> http://24.42.86.123/files/passwd.c
>
> The chars it outputs are a..z, A..Z, 0..9 and '{}'. So there are six
> bits per character. For a decent password their should be at the very
> least ten characters and more like 15 or so.
> Tom
you could put more characters(!@#%$...) in transtable[] and
convert to char using:
printf("%c", transtable[trng_byte() % sizeof(transtable)-1]);
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOP1KCDBaTVEuJQxkEQL2kACfWY3gQFRJDA6PQRRHrkn5zzYAnC4AoJqb
4g68qg8297+eT4xOJJXhH3OS
=F6Vh
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Books on maths behind NFS
Date: Wed, 19 Apr 2000 07:58:58 GMT
In article <8dhftu$87g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm trying to understand the Number Field Sieve, and to do this I need
> to learn the algebraic number theory behind it. Can anyone suggest
> any good books that cover this stuff?
Thanks to everyone for the very useful replies - a lot to check out
there. Has anyone had a look at
http://www.crcpress.com/index.htm?catalog/3989
which apparently covers NFS as an application?
Chris
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Very Large S-Boxes VLSB's
Date: Wed, 19 Apr 2000 08:13:34 GMT
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
> > I would like to konw, why are we still using small S-Boxes with 70's
> > memory limitations..
> >
> > Has anyone designed a Block Cipher with VLSB (Very Large
> > S-Box)...something like 128x128 -----> 1024x1024
> >
> > Memory is pretty cheap these days...Non Linear VLSB's would be very
> > strong against Differential and Linear Attack....
>
> That's pretty silly actually. A 8x8 sbox takes 256 bytes of ram, a
> 128x128 sbox would take 2^128 bytes of ram. Apparently your thinking
is
> quite flawed.
>
> You could built a 128x128 sbox out of some intermediate algebraic
steps,
> whoa, that's a block cipher... sorry.
I'm not an expert on cryptography, and right now I'm struggling through
the Schneier book, Applied Cryptography. I am however very familiar with
various kinds of bit mangling issues. Note in the calculations I'm
assuming a byte to be a bit octet.
>From what I understood about the S-boxes of DES (for example), there are
8 S-boxes with 64 entries each (6-bit input). Since the S-boxes have
4-bit output it means the values inside the S-box go from 0..15 so you
can represent this with a nibble. Thus an 8-bit number will hold two
entries, in the upper and lower halves of the bit octet, since 4+4=8.
Thus one S-box takes 64*4 bits of memory = 256 bits. Which is 64 bytes.
So all 8 S-boxes will take 8 * 256 bits = 256 bytes. This is indeed what
Schneier says on page 274.
So much for that.
What if we had an 128 x 128 S-box?
Let's use the same reasoning.
The number of entries in the said S-box: 128 * 128 = 16384 = 2^14. (What
is the number of output bits?) If you had 14 bits in each entry, you
could fill the S-box with 0, 1, 2, 3, ... , 16383 in some order each
number being in the table only once. I have a vague impression that this
would be a permutation, perhaps? So I'll make the assumption that for an
S-box you would want inputs to map into more than one output. So let's
say (for the sake of argument) that each entry in the table is 13 bits
(0..8191) instead of 14 bits.
In this case the total memory requirement for ONE S-box would be 16384 *
13 bits = 212992 bits = 208 kb. Assume you have 8 S-boxes it would be 8
* 212992 = 1703936 bits which is about 1.67 Mb. I think 8 S-boxes each
mapping 14-bit inputs into 13-bit outputs would mean an 8 * 16384 bit =
131072 bit input block (in DES) going into the substitution operation
(ie. into the S-boxes).
But no matter how you twist the issue, I can't see where you people got
2^128.
Like I said, I'm not an expert but I think the original poster expressed
a valid idea. Although it seems that Schneier mentions some extra issues
about that on p. 349.
PS. While I'm here... where could I find information about the finite
automaton cipher mentioned in Schneier? Web searches turned out nothing
useful. It's the "FAPKC1" and "FAPKC2" on page 482.
Thank you.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: password generator
Date: Wed, 19 Apr 2000 08:19:40 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[EMAIL PROTECTED] wrote:
> printf("%c", transtable[trng_byte() % sizeof(transtable)-1]);
err, it should be:
printf("%c", transtable[trng_byte() % (sizeof(transtable)-1)]);
== <EOF> ==
Disastry
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOP1P0DBaTVEuJQxkEQK0+wCfU5OIefRwwg/OmPJQ/u+sJpltQbQAnjET
E70LwNIvKi90KP32YawR3Xf3
=PIMn
=====END PGP SIGNATURE=====
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: updated paper on easy entropy
Date: Wed, 19 Apr 2000 10:45:56 +0200
Tom St Denis <[EMAIL PROTECTED]> wrote:
> The problem is when you get into higher models you need more input
> to train the model. Otherwise it will over estimate the entropy
> each time.
Self-corelation [where the model is trained with the text beeing
tested], as in Tom's order-0 model, leads to gross UNDER estimate
of the entropy when higher models are applied.
String 'wethepeopleoftheunitedstatesinordertoformamoreperfectunion'
gives, using self-corelation
order 0: 216.5 bits
1: 95.2 bits
2: 18.8 bits
3: 6 bits
above: 0 bits
Pre-training tends to INCREASE the reported entropy, compared
to self-corelation. Also, if training is performed, problem is:
using what ?
Asking the user to supply both the training material and the
seed is a waste, we shall use the entropy in everything entered.
Using fixed training material is bound to cause gross entropy
OVER estimate for input that deviates from the training material,
at least with the simple predictors envisionned so far.
entropy != easy
BTW, there are lots of ways the entropy estimator I proposed
yesterday might go wrong in pratice, even when the user does
not really work hard against us. Among others
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM
WeThePeopleOfTheUnitedStatesInOrderToFormAMorePerfect
ClintonBushReaganCarterFordNixonJohnsonKennedyEisenhower
MaitreCorbeauSurUnArbrePercheTenaitEnSonBecUnFromage
The fact one can learn a poem exactly shows that, if the user
is hostile (knows the algorithm and wants to deduce the seed,
or just wants to be able to regenerate the same seed), and we
have "just a keyboard and a hash", we gota time the keypress.
Francois Grieu
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 01:47:19 -0700
Either way the modular division will introduce biases unless
transtable has a size of 2^n. A worst case example is 3
symbols out of 2 bits. using simple mod gives:
0 = 0
1 = 1
2 = 2
3 = 0
If all RNG outputs are equally probable, this gives
probabilities of
0 = 1/2
1 = 1/4
2 = 1/4
As you can see there is a rather extreme bias in the final
output.
Joe
> [EMAIL PROTECTED] wrote:
> > printf("%c", transtable[trng_byte() %
sizeof(transtable)-1]);
> err, it should be:
> printf("%c", transtable[trng_byte() %
(sizeof(transtable)-1)]);
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: BS on AES3 (from the latest Cryptogram)
Date: 19 Apr 2000 08:53:09 GMT
Roger <[EMAIL PROTECTED]> wrote:
> Are you sure it wasn't written by Bob Silverman or Brian Snow? <g>
Bob Silverman's initials are surely RS, not BS. (I'm sure he can
correct me if I'm wrong). Besides, I read the article in Crypto-Gram
before seeing it here, so I knew its provenance already. Which probably
counts as cheating. Or at least as more of an `educated' guess than I
admitted to. ;-)
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Very Large S-Boxes VLSB's
Date: Wed, 19 Apr 2000 09:23:08 GMT
In article <8djpr5$rno$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > > I would like to konw, why are we still using small S-Boxes with
70's
> > > memory limitations..
> > >
> > That's pretty silly actually. A 8x8 sbox takes 256 bytes of ram, a
> > 128x128 sbox would take 2^128 bytes of ram. Apparently your
thinking
> is
> > quite flawed.
> >
> The number of entries in the said S-box: 128 * 128 = 16384 = 2^14.
(What
> is the number of output bits?) If you had 14 bits in each entry, you
> could fill the S-box with 0, 1, 2, 3, ... , 16383 in some order each
> number being in the table only once. I have a vague impression that
this
> would be a permutation, perhaps? So I'll make the assumption that for
an
> S-box you would want inputs to map into more than one output. So let's
> say (for the sake of argument) that each entry in the table is 13 bits
> (0..8191) instead of 14 bits.
Silly me. There was a bug in my comprehension of the terminology. If
it's an 128*128 S-box it of course maps 128 bit input into 128 bit
output. Ie. the memory requirement would be 128 * 128 bits = 16384 bits
for one S-box.
Thank you.
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
******************************
