Cryptography-Digest Digest #12, Volume #11 Sun, 30 Jan 00 02:13:01 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Pencil & paper cipher question (Uri Blumenthal)
Re: Is there a practical guide to using crypto? ("JCardinal")
Re: Pencil & paper cipher question (Uri Blumenthal)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Pencil & paper cipher question (Uri Blumenthal)
Re: Why did SkipJack fail? (Uri Blumenthal)
Re: A question about odd grilles (wtshaw)
Re: A question about odd grilles (wtshaw)
Re: NEC claims New Strongest Crypto Algor (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: Is there a practical guide to using crypto? (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 23:25:11 EST
In article <8707mg$ege$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
Kagalenko) wrote:
>
> Well, your assertions clearly indicate that you do not understand the
> reason why the drift I am talking about exists. Too bad for Perkin-Elmer
> and the rest of them; may be, they should have hired someone better.
> And BTW, jitter has nothing to do with the phenomenon I am describing.
>
You are right. I don't understand the reason for the drift for the
same reason that I don't understand the reason for fairies, elves.
or Unicorns exist. I have never seen such a drift as you describe
and niether has anyone else (including you!). If it exists it
is not what you described. If it is what you described, it does
not exist.
It is VERY difficult to understand the reason why the drift you are
talking about exists when it doesn't. There is Jitter, there is
thermal drift, there is VCC drift, and there is crystal aging,
there is phase locking through E fields, and a few other effects.
Of those possibilities, only crystal aging behaves as you describe
(does not "reset" to zero when I turn the power off for 24 hours).
You have no data. You have no observations. You have never built
the circuit you describe. You have never fed the resault of the
circuit you describe into a test that looks for bias. This isn't
science - it's faith.
(Didn't I killfile him already? Grumble Grumble...)
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Sat, 29 Jan 2000 23:24:43 -0500
Reply-To: [EMAIL PROTECTED]
"r.e.s." wrote:
> : How it's possible? Maybe I didn't understand solitaire but seems
> : that there isn't any correlation between plaintext and the stream
> : used to xor it so anyway..........
> : Expecially in solitaire the sender should
> : care about MITM attack since the message will be probabily sent
> : using very insecure channel (via mail?) and since modifing some
> : character of cyphertext will not result in a desync. Do you agree?
>
> Yes, I see your point.
Well, encryption usually does not provide authentication. *Especially*
stream ciphers, because of the above.
However in some special cases (such as usibg block cipher in
error-propagating mode and having fairly structured plaintext)
ciphertext tampering is trivial to detect. E.g. if the text is
a spy report in Russian, then having even one character in the
decrypted message garbled would be a good cue that the message
has been damaged. (:-)
So if I were to exchange short messages in natural language
(such as English, German, Russian) - I might settle for a
good block cipher and one shared encryption key, assuming
that it is infeasible to tamper with the ciphertext in
such a way that the result will still be decrypted as
text in the proper language...
I suspect ciphers like VIC also have this property...
--
Regards,
Uri [EMAIL PROTECTED]
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: "JCardinal" <[EMAIL PROTECTED]>
Subject: Re: Is there a practical guide to using crypto?
Date: Sat, 29 Jan 2000 21:39:41 -0700
I'm sorry Douglas, I don't believe I've made myself very clear. I realize
what your saying about the brute force method and yes it's in the faq and
I'm quite familiar with the concept.
What I was after, and this may just be my overall ignorance on the subject
but here goes anyway:
Is it not likely that when a casual user of a hypothetical encryption
program sits down to encrypt a file, and it requires a 128bit key to encrypt
something what they are really going to do is enter a password using a 16
byte or shorter string of ascii or keyboard typeable characters to be used
as their key?
And if this is so then is it not fairly easy to try every possible key they
might have typed to generate a password?
Or, is it usual practice to somehow transform that password or act upon it
so that it's not as simple as what I described.
Now if you tell me that that particular encryption program is going to act
upon that key to make it somehow more complex than what can be typed on a
keyboard, does that really matter from a practical standpoint? That same
password has got to decrypt the ciphertext every time on the same encryption
program or it would be useless.
As it says in the faq and elsewhere a good encryption program should only
rely upon the secrecy of the key, not the algorithm itself, so if we assume
that the 'evesdropper' has the same encryption and decryption program as the
person who originally sends the message then it's a matter of recreating the
password they used and in terms of brute force there isn't much force
required to do that is there? I know hypothetically there are 2^128
possible keys but in practical terms does it ever come to that?
Forgive me in advance if this is the wrong place to be asking this kind of
question, I will happily go (nearly) anywhere else recommended <grin>.
- John
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> JCardinal wrote:
> > However I dont' really know anything about it in terms of:
> > how do you use it in a manner that ensures your not exposing
> > any weaknesses.
>
> That's the big question, to which there is no simple answer.
> Almost *all* implementations of cryptosystems have weaknesses,
> especially on non-secure systems like a typical PC.
>
> > One thing I really want to know is if I use a 128bit key and
> > encrypt a file > using twofish in ecb mode, whats to stop
> > someone from attempting every possible 128bit key until they
> > decrypt it?
>
> Surely that must be in the sci.crypt FAQ? What you describe
> is known as a "brute force" key search, and is not feasible
> for 128-bit keys simply due to the amount of time it would
> require for the fastest available computer to test each key.
> The calculation is simple: There are 2^128 possible keys;
> testing each might require, say, 2^-28 seconds on a super-fast
> computer, so testing all keys would take 2^100 seconds. If
> you consider the system secure enough if there is only a 2^-20
> chance (one in a million) of a message being read by the
> interceptor, then your system is "cracked" after 2^80 seconds
> on average. 2^80 seconds is about 4x10^16 years, which is
> *much* longer than the estimated age of the universe. The
> bottom line is that a 128-bit key is more than sufficiently
> secure against brute-force key search. Even if computers
> could become a billion times faster, we're still looking at
> more time than could ever be spent, not to mention the truly
> astronomical cost of recovering just one key.
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Sat, 29 Jan 2000 23:35:30 -0500
Reply-To: [EMAIL PROTECTED]
David Wagner wrote:
> ..........
> That may rule out exhaustive keysearch attacks, but how do you know there
> are aren't clever attacks that treat VIC as a LFSR with nonlinear output?
I don't (:-), but they aren't likely due to the amount of material
available to the analyst. See below.
> ...............
> Moreover, we may expect that the military is even better at cracking
> LFSR-based ciphers than the academic community is, because it is rumored
> that most military ciphers are (or were) shift-register based.
> Do these observations shake confidence in VIC?
Not really. While your arguments are certainly good and correct, the
very nature of VIC-like ciphers implies: (a) small amount of traffic,
and (b) no [or almost no] plaintext available. In such conditions, I
would think VIC is *reasonably* safe...Plus, one of the design goals
of VIC was making the "generator key" protected from the "encryption
key" exposure - i.e. even if you reconstruct the transpositions and
the checkerboard, you still don't have the original passphrase, and
[probably] have to start from scratch on the next message...This can
invalidate LFSR-based attack, can't it?
What's your opinion?
--
Regards,
Uri [EMAIL PROTECTED]
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 23:41:24 EST
In article <87088q$jah$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
Kagalenko) wrote:
> You did not measure it becasue you were not looking for it. You were
> measuring jitter, an entierly different thing.
Quick, name the company that makes the most popular jitter test set.
What? You can't do it? How do you know what it measures?
Now explain the proper procedure for graphing long term crystal
drift against an atomic clock. Can't do that either?
Explain the proper method for measuring short term variations
that lie between the above two measurement techniques. No?
Have you ever connected any piece of test equipment to a crystal
oscillator? Not even an oscilloscope?
Does anyone here want to hear the joke about the drunk on the freeway?
Maybe later in life, after you have learned to read, write, count,
and think, you will have more success. True, these are rudimentary
skills that many of us "normal" people take for granted that
everyone has an easy time of mastering. But we sometimes forget
that there are "challenged" persons in this world who find these
things more difficult. If I had known, that this was your case then
I would have never read your posts. It just wouldn't have been
"right". Sort of like parking in a handicap space. I wish you the
best of luck in the emotional, and social struggles that seem to be
placing such a demand on you. I hope this helps...
(Note to self: check that killfile - must be a typo or something)
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Sat, 29 Jan 2000 23:40:00 -0500
Reply-To: [EMAIL PROTECTED]
"r.e.s." wrote:
> It was quite secure before the algorithm became well-known, but
> if an opponent knows that VIC is the cipher you're using, then the
> effective keyspace entropy is no more than ~36 bits. (I'm referring
> to the VIC cipher as described on John Savard's website, mentioned
> above.)
(:-) Sure.
> The VIC cipher uses a "passphrase" of 6 digits and 20 letters, but
> processes it down to a critical string of 10 digits (i.e. 33 bits),
> and this string completely specifies both a straddling checkerboard
> and a double transposition, assuming the algorithm is known. Even
> if we add another 3.3 bits for the one digit used to hide the message
> key, that's still only ~36 bits.
Certainly. Which is why "modern VIC" must adopt a longer "igniter".
> So it seems to me that to be reasonably secure, the VIC cipher
> needs to be modified, say to lengthen its "critical digit string"
> to ~20 digits, for ~66 bits of entropy. (And correspondingly longer
> passphrases should then be incorporated.)
(:-) Yup!
> But as for the main crypto components (the straddling checkerboard
> & double transposition) -- they represent well over 100 bits of
> entropy to a brute-force attack.
An excellent observation, if I may say so.
> In fact, the checkerboard (even
> assuming it's built around a known permutation of the alphabet)
But why should it be known? "ASINTOER" is good, but not the
only one possible! And the same applies to "SNEGOPAD" (:-).
> ...............But to take advantage of
> that potential, these components would need to be "packaged" more
> securely than in the published version.
I've been writing it up, but got delayed by my "official" work. (:-)
Stay tuned.
> (I wish I had a better idea of the difficulty of "breaking" the
> sort of double transposition involved here -- it's esp. difficult
> because although the first stage transposition uses a simple keyed
> row-wise fill, the second one uses a keyed "serrated fill".
> Considering also that the column widths are random, and that the
> symbols are fractionated digits with a quite uniform frequency
> distribution, it's hard to believe that this could be anywhere
> close to breakable in practice, if properly "packaged" as
> described above.)
Double transpositions can be broken, but this is a fractionizing
cipher (and with straddling checkerboard) - that makes it harder
[and IMHO infeasible] to break.
--
Regards,
Uri [EMAIL PROTECTED]
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Sat, 29 Jan 2000 23:43:00 -0500
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> You missed the "bought more cheaply" part. I'm pretty sure
> that for less than $200,000,000.00 one could bribe enough bank
> officers to accomplish the same effect.
Sure, but would that be a one-time deal, or would those
officers require fresh "cash infusions" every time a
new message must be decoded?
Walker's net $1M for 1M of messages deal wasn't that common, was it?
--
Regards,
Uri [EMAIL PROTECTED]
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A question about odd grilles
Date: Sat, 29 Jan 2000 23:08:45 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> Isn't it that for a turning grille the holes cut can't be entirely
> arbitrary, for otherwise some of the holes at the four positions
> could possibly overlap? What are the general rules for cutting
> the holes?
>
Number or letter all possible positions in one quadrant, and do the same
with the same numbers in the other quadrants. Don't cut more than one
hole in the whole grille with the same number regardless of quadrant.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A question about odd grilles
Date: Sat, 29 Jan 2000 23:23:56 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>....An old book - sometime in the 1920s - published by
> Popular Science magazine showed all sorts of scientific wonders of the
> age. There was a page about a "cipher expert" using a captured German
> grille on an intercepted message. The hole in the center was open, but
> it had a black border around it, and the instruction was to use it
> only when the grille was in the first position.
>
> All this is on my site, in the section entitled "Methods of
> transposition" in the first chapter on paper-and-pencil methods.
>
I suppose then, that is a solution to be included.
I've been on a transposition kick for a while recently and have working
applications for 7 systems: Ansco, Cadenus, Columinar Transpositional,
Myszkowski, Nihilist Transposition, Railfence, and Redefence. Now, down
the hard ones: Square Grille and Swagman. I'll cutout doing the Route
Transposition. I have tried to stay within ACA standards as much a
possible in this Classic Series.
Unfortunately, my actual use of a pencil or pen is pretty much of a
problem at present, so that is the excuse for doing these applications.
The remaining two will take some thought.
A triangle grille looks interesting as well. I understand there was a
writeup about one in 1947. Maybe someone has the issue. The grilles will
be interesting to program, which is what I really like to take as a
challenge.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Sun, 30 Jan 2000 06:26:31 GMT
On Sun, 30 Jan 2000 01:23:17 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>The only way this can work is for the key to have size comparable to
>the message. Thus it suffers from the standard one-time pad key
>distribution problem. Most practical applications of cryptology
>require that the key be much smaller than the protected data.
As Mr. Scott has already noted, he is thinking of something that isn't
quite a one-time-pad; merely the use of a single key, which will
encrypt a number of messages, which happens to be longer than any
_single_ message.
This has some interesting properties, although it is still not
theoretically immune from attack once more than one message is
intercepted.
But it can only contribute to deniability if at least _part_ of that
key is applied to the message in a simple fashion. Otherwise,
constructing a fake method would be equivalent to cracking the cipher.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 06:30:19 GMT
On Sat, 29 Jan 2000 19:41:51 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>The effectiveness of the counterargument thus rests on whether we can
>be forced to accept the myth of a "cryptographer's stone" in rational
>argument.
That isn't really the effective rebuttal, since in a strictly
theoretical sense, a "cryptographer's stone" is just as hard to prove
nonexistent as it is hard to prove a single specific cipher is secure.
Which is why I felt it necessary to look at things from a practical
point of view - its nonexistence may be equally nonprovable, but its
existence is intuitively and heuristically much less likely.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 06:34:46 GMT
On Sat, 29 Jan 2000 22:10:37 +0000, CLSV <[EMAIL PROTECTED]> wrote, in
part:
>Well this thread has a certain philosophical vaguenes
>so there is no point in taking things to the limit but
>there are ciphers based on problems like the RSA-problem
>that are conjectured to be equivalent to hard problems.
>It is not unreasonable to think that in the future
>ciphers will be developped the breaking of which is
>proveable equivalent to solving a hard problem.
There are already such ciphers.
That isn't the problem.
The problem is proving that the "hard problems" actually _are_ hard.
*That's* what's equivalent to solving the halting problem.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is there a practical guide to using crypto?
Date: Sun, 30 Jan 2000 06:21:59 GMT
On Sat, 29 Jan 2000 21:39:41 -0700, "JCardinal"
<[EMAIL PROTECTED]> wrote, in part:
>And if this is so then is it not fairly easy to try every possible key they
>might have typed to generate a password?
>Or, is it usual practice to somehow transform that password or act upon it
>so that it's not as simple as what I described.
That is a very feasible attack against cipher systems.
This is why, for example, the manual for PGP advises users to use a
key *phrase* rather than a single password, and to choose even that
carefully, when encrypting files with conventional cryptography, or
when protecting their key rings.
But when encrypting an E-mail, passwords aren't used at all. Instead,
the public key of the recipient is used, combined with a session key.
And both of these keys resulted from random numbers, generated by
timing characters the user typed on the keyboard.
One very early version of Netscape which used a similar technique was
attacked successfully because the random information it obtained from
such things as the time of day and various operating system goings-on
did not have enough randomness in it - the number of different
possibilities was too small.
These are sufficiently well-known attacks, however, that effective
precautions are usually taken against them. Also, this is one reason
that the news that the Intel 810 chipset for its Pentium III computer
included hardware random number generation was greeted as exciting.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 06:32:05 GMT
On Sun, 30 Jan 2000 01:36:33 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>John Savard wrote:
>> However, if "we can't get proof" is also considered as a reason to,
>> failing some way to obtain proof, try to at least do everything we can
>> to make our ciphers stronger - without proof that we have done enough,
>> without the knowledge whether or not we may have done more than is
>> necessary - then things like Mr. Ritter's multi-ciphering are entirely
>> sensible responses to the situation.
>But then you need proof that such methods actually *do* "make
>our ciphers stronger". Adding complexity doesn't always help,
>as witness Knuth's super-random number generator example.
Proof that they don't make our ciphers weaker is sometimes attainable,
and if one can achieve that, it shows one is taking the proper
precautions. Such proof, coupled with the likelihood of increased
strength (since there is more key material, etc.) I am afraid will
have to be accepted as adequate.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 06:39:53 GMT
On Sun, 30 Jan 2000 01:47:21 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>John Savard wrote:
>> If there were a solution to the Halting Problem, then there would be
>> no unsolved problems in mathematics - as Fermat's Last Theorem (or
>> course, now solved) and the Goldbach Conjecture, for example, could be
>> phrased in the form of a program.
>How? You have really overstated the applications.
Will a program that generates successive primes by the Sieve of
Eratosthenes method, using the part of the tape that goes off to the
left, and writing down on the part of the tape to the right all the
twin primes it finds while doing that, go beyond any finite point on
the right side of the tape?
Such a program can be modified so that it halts once it moves past
cell 2^(2^(2^1000))) on the right side of the tape, so at least the
question "Are there more than N twin primes" for any finite N can be
phrased in the form of the question "will this program halt".
A program that halts after doing a brute-force-search for
counterexamples to Fermat's Last Theorem can be constructed directly,
without this little correction.
Now, think of a genetic algorithm that halts when it cooks up a
program to crack DES that is more efficient than a certain pre-set
goal...
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
** 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
******************************
