Cryptography-Digest Digest #635, Volume #10 Fri, 26 Nov 99 22:13:01 EST
Contents:
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Ask about Certification-less Public Key (Anne & Lynn Wheeler)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: "Compressible Encryption" - Is it an oxymoron? (Paul Hsieh)
Re: Random Noise Encryption Buffs (Look Here) (Tom St Denis)
Authentication Techniques for registering with RAs ([EMAIL PROTECTED])
Re: Distribution of intelligence in the crypto field (Paul Hsieh)
Re: AES cyphers leak information like sieves ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) (Johnny Bravo)
Re: Stretching low-entropy keys (Johnny Bravo)
Re: Stretching low-entropy keys (Johnny Bravo)
Re: Why Aren't Virtual Dice Adequate? (John Savard)
Re: AES cyphers leak information like sieves (John Savard)
Enigma Plug Board (UBCHI2)
Re: The Code Book (UBCHI2)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Fri, 26 Nov 1999 23:03:55 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
[block size doubling ==> work required for a break doubling?]
: If the diffusion properties of your cipher stay the same for each
: block size (i.e. every bit in the plaintext block affects
: approximately half the ciphertext bits) then the usual attacks (like
: differential) will require the same number of blocks
Some attacks will require a /much/ larger numbers of blocks, however.
: The question is rather, how much blocks you need.
: If you have dictionary attacks in mind, then you DO need to store twice
: amount of data.
Shouldn't that figure read 2^N times as much - where N is the old block
size, in bits?
The frequency of each block virtually goes through the floor as the block
size increases.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
If the shoe fits, put it in your mouth.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 26 Nov 1999 18:22:37 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>
>On 26 Nov 1999 05:12:29 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John Savard)
>wrote:
>
>>>I'm not averse to a little post-processing. Encrypt the output of a
>>>roulette wheel, and the output of a 10-sided die, by different
>>>methods, and then add the two results. That should satisfy any
>>>reasonable concern about an exploitable imperfection.
>
>>I was under the impression that exclusive-ORing was preferred
>>to ANDing. Did I misunderstand?
Oops? Typo. I meant to write ADDing.
>I said "add" the two results: since they are in the form of decimal
>digits, addition of individual digits is the equivalent of an
>exclusive-OR.
Got it. I use AND/OR/XOR/ADD/DIV etc. so much in my job I tend to read
those definitions into what I am reading. What do you do when addition
increases the number of digits in a situation where a fixed number of
digits are required? Would you do modulo addition, truncation, or just
swith to using an exlusive-or insread of an add?
While on the subject, I have heard the claim that XORing a true
random set of bits with any ordered set of bits of the same size
will always produce a true random output, assuming that the ordered
bits were created with no knowledge of the random bits. I am just
an EE who dabbles in this kind of things, so please forgive me if
I am misundersanding. It seems that if I have some data that I
believe to be random, XORing it with the output of a pseudorandom
generator cannot reduce or increase the randomness.
------------------------------
Subject: Re: Ask about Certification-less Public Key
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 26 Nov 1999 23:23:39 GMT
also, at recent FSTC/FAST meeting where we were discussing a number of
AADS implementations (www.fstc.org) there was also reference to NPKI
project in michigan (i.e. no public key infrastructure, i.e. public
keys ... but not public key infrastructure as currently commonly
constituted).
there was also an AADS Radius demo'ed at PC/EXPO in NYC last spring
(i.e. radius is the dominant authentication mechanism thruout the
world).
AADS for all electronic retail financial transactions, aka X9.59
... to preserve the integrity of the financial infrastructure with
digital stignature, at least both debit & credit (while preserving
privacy). http://www.garlic.com/~lynn/
AADS for non-financial electronic commerce transactions (age, address,
location, eligibility). FSTC/FAST: http://www.fstc.org/
AADS Radius for majority of all internet authentication transactions.
http://www.garlic.com/~lynn/
there is also various activities involving AADS for all wholesale
financial transactions and various kinds of business-to-business
operations.
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 26 Nov 1999 18:30:20 EST
In sci.crypt John Savard <[EMAIL PROTECTED]> wrote:
> But I will admit that it is difficult to be sure that something using
> thermal resistor noise isn't being contaminated by electrical
> interference.
Ah! something I know about! I am an EE with a strong R&D/Science
backgound. such noise sources ARE contaminated by electrical
interference. It's small but it's real. BTW, we EEs use diode
noise instead of resistor noise. That reduces the interference
by a couple of orders of magnitude (but it is still there!).
------------------------------
From: [EMAIL PROTECTED] (Paul Hsieh)
Subject: Re: "Compressible Encryption" - Is it an oxymoron?
Date: Fri, 26 Nov 1999 16:21:14 -0800
[EMAIL PROTECTED] says...
> Paul Mullen <[EMAIL PROTECTED]> wrote, in part:
>
> >As you are probably aware, the default setting for Microsoft Outlook
> >personal folder files is "Compressible Encyption", with alternatives of
> >better encyption and no encryption. I can understand that a good
> >encryption system would leave a quasi random jumble of bits with no
> >discernable pattern and therefore no possibility of compression. I
> >would assume that "compressible encryption" would leave patterns much
> >like the original file and a brief glance at an Outlook file confirms
> >that there are such patterns.
>
> >The question therefore arises: just how weak is the default
> >encrpyption? Is it so poor (such as a simple transposition cipher, or
> >even just an XOR) as to not be worth having?
>
> Microsoft's "Compressible Encryption" isn't, apparently, but that
> doesn't mean that compressible encryption is *impossible*. One could
> first compress the input, encrypt it securely, then output it in a
> compressible form. Except for steganography or armor, I can't imagine
> why anyone would bother, but it exists as a _theoretical_ possibility.
Uhh ... well I thought that the entropy of the message was kind of what
you are trying to protect. In any event, doesn't it make more sense to
compress first, then encrypt?
--
Paul Hsieh
[EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 26 Nov 1999 23:30:01 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Thus random is only a subjective term.
>
> Far from it. In fact I've seen several reasonable technical
> definitions of "random" (varying according to context).
> There is a recent semipopular book on this, which I mentioned
> before as a prerequisite to any intelligent discussion of the
> topic.
Random is just a term we use to say if something is unpredictable. I
can say RC4 for example is predictable .... only if I know the current
state... It's depends on which side of the coin you are.
The yin and yang.
> I don't know what "universially randomness" is supposed to be,
> but there certainly are genuinely random processes in nature
> that can be tapped to produce truly random bit streams.
Universially random should mean something which is random, and by NO
MEANS at all predictable. However this cannot exist in nature. So we
rely on 'very difficult to predict' as random.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Authentication Techniques for registering with RAs
Date: Sat, 27 Nov 1999 00:06:17 GMT
I am looking for a document which will give the 'credits' attached to
various forms of ID a RA may require to register an individual.
E.g. A driver's license may be worth '20 points'
a Brith certificate '80 points' etc...
Much appreciated.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Hsieh)
Subject: Re: Distribution of intelligence in the crypto field
Date: Fri, 26 Nov 1999 17:27:34 -0800
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> With all the NSA discussions, I was thinking...
>
> There is very VERY little distribution of intelligence in the crypto
> field. Come on, we all know the names. Shoot, in this forum, we call
> them by first names. Eli, Bruce, Lars, Ross, Ron etc...
>
> The 80/20 rule seems more like the 95/5 rule when it comes to crypto.
> About 95% of the world's advances are done by 5% of the crypto
> community. Who breaks algorithms? The same names. This is true for
> almost every industry, and crypto is no exemption.
>
> So my point is, I have serious doubts that the NSA is THAT much ahead of
> the world. Why? Because unless they are harboring a few Bruces or
> Eli's in there, I don't see them gaining that much ground. A society
> grows as a function of how fast information takes to disciminate and the
> feedback to come back. In a government structure, that rate seems to
> be... well, be as fast as service at the DMV.
Actually they are harboring a bunch of Bruce's and Ian's.
Let me explain. Every year college students in the US are invited to
write a math contest called the William Lowell Putnam exam. Its just a
fun 6 hour math contest that most people consider brutally hard. Then
the exams are graded people are ranked, math geeks get recognition,
harvard gets to look at their fall line up, that sort of nonsense. But
something else happens -- the NSA offers all of the top scorers jobs as
soon as they graduate. I know one person who accepted, and one person
who declined due to having been born in Cananda.
Anyhow these guys are damn smart. I would be willing to bet that there
are as many "top 5%" cryptographers outside of the NSA as there are
inside of the NSA.
--
Paul Hsieh
[EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 26 Nov 1999 23:49:11 GMT
wtshaw wrote:
> Only those who are real cranks deserve to get the shaft. His self-styled
> poetic statements are meant to light the fuses of shallow thinkers while
> should be of not regard to those who are seeking truth. Being willing to
> hop on one foot at the formal request of someone demanding that antic does
> not speak well of either party.
Asking for civilized behavior during a technial discourse
is *not* asking anyone to (metaphorically) hop on one foot.
If the goal is to communicate and/or enlighten, offensive
behavior just gets in the way. If the barrier is too high,
most reasonable people won't bother to try to overcome it.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 26 Nov 1999 20:05:47 GMT
On Fri, 26 Nov 1999 14:28:25 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Tim Tyler wrote:
>> I feel it's far from easy. Generating "genuinely" secure random numbers
>> is not even known to be possible.
>
>It's not *trivial*, and may not be "known" to amateurs, but
>we do it all the time. There are commercial crypto chips that
>implement this function (among other, more important functions).
But you cannot prove that the output of those chips is random. That
is the point, we can generate numbers that "might" be random with
varying degrees of confidence. But proving it is not possible.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 20:42:33 GMT
On Fri, 26 Nov 1999 12:43:49 -0800, lordcow77
<[EMAIL PROTECTED]> wrote:
>A traditional hash function would probably not be ideal for the purpose
>of stretching keys, as these tend to be easily implementable in
>hardware. A better function should require very large ammounts of
>memory to run, using something akin to a shuffling array, as well as
>complex arithmetic operations, such as multiplication, division, or
>exponentiation. Large lookup tables (ie. based on pi, e, whatnot) are
>also good for eating chip space.
The hash function could be a valuable part, due to the existent
analysis of the functions for collisions. The paper suggested using a
reliable hash function, combined with operations that are expensive in
hardware, but not for a general purpose processor. It is easier to
make a hash more expensive to compute (as extensive analysis of the
hash is already complete), than to start from scratch trying to make
your own hash that is computationally expensive.
This is to raise the cost of a dedicated hardware machine to a
prohibitive level. The paper describes such a permutation that uses
32 bit math and requires a 256 element table of 32 bit unsigned
values. 32 bit math and 8192 bits of RAM are nothing for a PC, but
not so cheap for the thousands of chips you will need for a hardware
cracker. While this permutation hasn't been extensively analysed, it
doesn't need to be due to the secure hashes on each side of it. All
the permutation does in ensure that every bit of the input is changed
before it is hashed again.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 20:55:59 GMT
On Fri, 26 Nov 1999 22:38:01 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>>> I have not read there paper. But not reading has never stopped Mr BS or
>>>Wagner form commenting on my code.
>>
>> You admit you have no idea what they are talking about, then you go
> No asshole
Profanity, the first refuge of the incompetent.
> I did not admit to having no idea of what they are talking
>about. Can't you ever understand anything.
This is a direct quote from you. "I have not read there paper."
If you didn't read the paper, how can you know what was in it?
Is total cluelessness and ad-hominiem attacks the extent of your
logical ability? And I use the term logical very loosely when
describing your posts.
>>on to attack it. You are doing exactly what you accuse Bruce of
>>doing, how exactly does this make you any better than your admittedly
>>low opinion of them?
>
> It does not make me any better it just is my justifaction for commenting
>on this since I do know something about functions. Appartently more than they
>know about my style of crypto.
But this paper is not about your crypto, since you admit you have no
idea what is in the paper, you have no basis for even beginning an
attack against the contents.
>And though I have need read there paper I am
"have need read there"
Please translate that into English for me, or your native language.
Let me know what your native language is, I'll do my best to
accommodate you.
>familor with the concept and stated how one can avoid using some hash in
>an attempt to strech a key. It is not a good concept from the get go.
They are using a hash, not avoiding one. If you had read the paper
you would know this. How can you be familiar with the concept if you
don't even know which concept is being described? Your arrogance is
only matched by your lack of knowledge on the subject, and maybe your
rather limited communication skills.
Feel free to get a clue and return when you have something logical
to add to the argument.
Johnny Bravo
--
"I know, I shouldn't feed the troll, but it is so fun!"
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sat, 27 Nov 1999 02:01:33 GMT
On 26 Nov 1999 18:22:37 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>What do you do when addition
>increases the number of digits in a situation where a fixed number of
>digits are required? Would you do modulo addition, truncation, or just
>swith to using an exlusive-or insread of an add?
One always, when adding N digits to N digits, takes only the last N
digits of the sum. An extra digit would be 1 if it appeared, so it
wouldn't be random. So whether or not a fixed number of digits is
required doesn't affect that.
>While on the subject, I have heard the claim that XORing a true
>random set of bits with any ordered set of bits of the same size
>will always produce a true random output, assuming that the ordered
>bits were created with no knowledge of the random bits.
That is correct.
>It seems that if I have some data that I
>believe to be random, XORing it with the output of a pseudorandom
>generator cannot reduce or increase the randomness.
It can't increase the entropy.
If you have a truly random physical process - but which may possibly
be biased (flipping a coin that might come up heads 53% of the time) -
and a pseudo-random generator which may not be cryptosecure, but is
good statistically, the XOR of those two streams *will* be of better
quality than either one individually for cryptographic purposes. (Each
stream has strengths that complement the weaknesses of the other.)
But post-processing of a physical random stream usually involves
combining two physically random bits to get one; a more complicated
algorithm than XOR may be thrown in for good measure as well.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 27 Nov 1999 02:05:28 GMT
On Fri, 26 Nov 1999 22:45:52 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> I take it that this means you don't really have a basic understanding
>of the difference of the 2 modes. So does this mean your still not going
>to fix your web page about PGP or what.
I did remove that statement, as someone else has noted that PGP uses
CFB mode; I am going to see if it's a faulty memory on my part, or bad
documentation, or what.
But if you look at that page now, I think you'll find I do understand
what each of those modes is and does.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Enigma Plug Board
Date: 27 Nov 1999 03:06:29 GMT
I read Singh's account of how Turing broke the security of the enigma plug
board but don't quite get it. It sounded like he passed the encryptions
through two mechanisms which together reversed the effect of the plugboard.
Can anyone briefly fill in the details?
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: The Code Book
Date: 27 Nov 1999 03:07:22 GMT
I saw a typo on the name of the Enigma creator. He had Scherbus when it should
have been Scherbius.
------------------------------
** 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
******************************
