Cryptography-Digest Digest #13, Volume #11 Sun, 30 Jan 00 07:13:00 EST
Contents:
Re: NIST, AES at RSA conference ("Joseph Ashwood")
Re: Intel 810 chipset Random Number Generator (Jerry Coffin)
Re: Wireless PKI now or later ("Lyal Collins")
Re: How much does it cost to share knowledge? ("Rick Braddam")
A Stronger VIC Cipher (was Re: Pencil & paper cipher question) ("r.e.s.")
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Security of Kremlin (PC software): Insecure implementation? ("cedric frost")
Re: Mac encryption algorithm? ("Douglas A. Gwyn")
Re: Is there a practical guide to using crypto? ("Douglas A. Gwyn")
Re: Keyword Cipher Cracker program ("Douglas A. Gwyn")
Re: Mac encryption algorithm - joke :-) (Andy)
Re: Is there a practical guide to using crypto? (Steven Siew)
Re: Wireless PKI now or later (Drew Cutter)
Re: How to password protect files on distribution CD (Chris Adams)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 18:05:42 -0000
> Can you explain what you mean with "single problem
oriented"?
They will solve on problem at a time, I believe this to be
based on the (at least my ) current belief that there is no
inherent advantage to addressing a set of problems, instead
of dealing with each one individually (ie there is an
inherenet advantage to addressing 1 hamiltonian path instead
of addressing 2 simultaneously).
The point here is that since all cryptography functions can
be abstracted to function(key, in , out), where there may be
some additional work to accomodate IVs before creating the
key in the function, the P ?= NP problem does not
satisfactorally address the issue of having a set of known
in and out with an unknown key. I mistakenly attempted to
use a provably hard problem (reversing a sort, without
additional information) for a cipher, as it turns out, given
a number of outputs and a partial knowledge of the inputs
(e.g. English text) it becomes possible to find a suitable
solution (although it may not be possible to recover the
exact password, you recover a perfect equivalent). If I
didn't make myself clear enough I am as always willing to
explain it again.
Joe
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Sun, 30 Jan 2000 01:24:46 -0700
In article <870fdk$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> 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?
Most popular? I haven't a clue. The most accurate (at least that
I've worked with on CD-players) was from Miller Audio Research.
Now, quick, prove that you knew that before I told you, or that you
have a clue about what difference popularity of a piece of test
equipment makes to the fact that nearly every statement you've made in
this thread is provably and utterly false.
I guess if nothing else, if anybody admits that you're right about
anything in this thread, it WILL make a difference to cryptography: a
"zero-knowledge proof" used to have a well-defined meaning, and it did
NOT refer to somebody like you with zero knowledge of the subject
matter convincing people of something that was utterly wrong!
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Wireless PKI now or later
Date: Sun, 30 Jan 2000 19:40:50 +1100
Being wireless, can you afford the bandwidth hit from shipping certificates
around?
And is your device grunty enough to process them before Christmas?
lyal
Drew Cutter wrote in message <[EMAIL PROTECTED]>...
>I was wondering what this group thinks of Wireless PKI offer by
>Baltimore , Entrust , certicom ? Is wireless PKI something I could use
>today with assurance or should I wait ? Which encryption is better of
>the three I mention ?
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: Sun, 30 Jan 2000 03:18:26 -0600
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Schlyter wrote:
> > That actually makes sense, because if there hadn't been any hackers,
> > there would be no PC's either, because the personal computer
revolution
> > started among hackers.
>
> Not really. You may be thinking of the Apple/Apple II, or even
> IMSAI, but we had personal interactive computers as far back as
> ENIAC. The "PC" in the Intel x86 sense originated with IBM,
> hardly known as "hackers".
I don't know what Paul is thinking, but his post reminds me of two
construction projects that appeared in electronics hobbiest's magazines
in January, in (I think it was) 1975. One was in Radio-Electronics, the
other in Popular Electronics. Both used the Intel 8008 eight-bit
microprocessor. Seems like one was called Mike-8, and the other Elf-8,
but I'm not sure about the names.
Each project included a source for the printed circuit boards, boards
plus small parts, or boards plus all parts except the microprocessor.
The 8008 cost about $300.00 each, IIRC.
Those were true *personal* interactive computers, since the only way to
get one was to build it yourself. Then you had to test it yourself and
program it yourself. Using binary machine instructions.
I remember very little about ENIAC. Did anyone ever actually build one
for personal use? I seem to remember that it was constructed with vacuum
tubes, is that correct?
Well, enought wandering down memory lane. Still, memories are knowledge,
and it cost nothing to share these. Except a little time, freely given.
Rick
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: A Stronger VIC Cipher (was Re: Pencil & paper cipher question)
Date: Sun, 30 Jan 2000 02:07:31 -0800
"Uri Blumenthal" wrote ...
: "r.e.s." wrote:
[...]
: > (I'm referring to the VIC cipher as described on John Savard's website,
: > mentioned above.) [ http://www.ecn.ab.ca/~jsavard/crypto.htm ]
[...]
: > 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".
But there may be a better way to accomplish this than increasing the
"seed" of the LFSR. Please see below, and let me know what you think.
: > 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!
After mulling this over a bit more, I wonder if, instead of literally
making the seed longer (with all the adjustments that entails), it may
be better to simply use additional passphrase letters to define two
independent 10-digit substitution tables to add confusion to the
transposition keys extracted from the LSFR output. (Details below.)
This will add about 44 bits of entropy to the 10-digit seed's 33 bits,
and the method I suggest uses an additional 20 letters of passphrase,
for a total passphrase of 6 digits and 40 letters. The resulting cipher
thus has ~72 bits of password entropy invested in securing ~77 bits of
internal entropy. (6 digits & 40 letters ~ 6*3.3 + 40*1.3 ~ 72 bits for
the passphrase, whereas 10 digit seed & 2 permutations of 1234567890
~ 10*3.3 + 2*22 ~ 77 bits internally.)
As I showed earlier, variants of this cipher should be capable of
*much* higher internal entropy than this, but I think the corresponding
passphrase burden wouldn't be practical for "pencil & paper" use.
So here's the idea, which only slightly modifies the "keying stage"
of the VIC cipher:
===========Keying Stage==========
The "passphrase" consists of 2 parts: a 6-digit secret number, and 40
secret letters of text (increased from 20). The letters are blocked into
4 10-letter words, and the letters in each word are ranked using the same
method as before, now giving 4 permutations of 1234567890. Call these
permutations p1,p2,p3,p4. (E.g. LOTUSBLOSS -> 2490613578.)
The following paragraph summarizes the old method for reference:
As before, use the last digit of the secret number to locate the 5-digit
msg-id in the ciphertext, and calculate a 10-digit seed from the following
values: {the first 5 digits of the secret number, msg-id, p1, p2}. As
before, use "chain addition" (x(i)=x(i-10)+x(i-9), i=11,12,...60) to
generate a 5x10 table of digits from the seed (x(i),i=1..10). These 50
digits are to be read out columnwise in order of seed digit rank, but
before doing so, the last two unequal digits of the 5th row, say m and n,
in the order of their appearance, determine the number of columns for the
two columnar transpositions that come later. (0 is read as 10 for m or n.)
At this point we generate the three "keys" needed for the main encryption
components, as follows. (I propose that having found m,n, the values 10+m
and 10+n be used for the corresponding widths, based on entropy analyses
that I've already posted.)
(1) The first 10+m digits are read out of the 5x10 table. Then p3 is used
to key a substitution on these digits, and the result is saved as the key
to be used for the first columnar transposition. E.g. if p3=(3018296475),
then the substitution table is
1234567890
3018296475
ie. if the 10+m digits read out of the table were 61174...92, then the
resulting key would be 93368...70.
(2) The next 10+n digits are read out of the 5x10 table, and p4 is used
to key another digit-substitution of the same kind as in (1), with the
result saved as the key to be used for the second columnar transposition.
(3) The next 10 digits are read out of the 5x10 table, and their ranking
(i.e. a permutation of 1234567890) is used as the key for the straddling
checkerboard.
This completes the keying stage, and the encryption/decryption proceeds
as before.
=====================
NB: What I call above the transposition key is actually the header row
of the transposition table, and the "key" is really the ranking of these
digits, since that determines the order of columnar readout. Also note
that by choosing to use 10+m, 10+n as the widths, the maximum number of
digits ever actually required from the 5x10 table will be 49 (39 for
transposition keys plus 10 for the checkerboard key), while the minimum
number would be 33 (23 for transp keys plus 10 for the checkerboard).
: > 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" (:-).
True (I like NOTARISE, myself ;-) but I've played around a bit with the
various ways of placing the letters in this kind of straddled
checkerboard, to see how that drives the output digit-frequencies, etc.
It appears that for "good" statistical performance, letter arrangement
can't be so freely chosen as one might have thought, and I believe it's
a major design decision for this cipher.
Two competing demands are, on the one hand, a low "inflation factor"
say I.F. = #output digits / #input letters, and on the other hand,
a low "skewness factor", say S.F. = hi digit freq / low digit freq.
(Expectation values being loosely used in both numerators & denom's,
and based, necessarily roughly, on "standard letter-frequencies"
given for English in the literature. So the following are very
ballpark-ish numbers.)
With a carefully chosen arrangement, I find (I.F.< ~1.4, S.F.< ~1.5).
An untested arrangement of letters seems likely to play havoc with one
or the other of these factors, or both. (Just putting the most-frequent
letters in the first row will control I.F., but not S.F.) A careless
arrangement may easily have S.F >> 10. (!)
: > ...............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.
[...]
Staying tuned!
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 30 Jan 2000 05:35:21 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>
>In article <870fdk$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>says...
>
>[ ... ]
>
>> 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?
>
>Most popular? I haven't a clue. The most accurate (at least that
>I've worked with on CD-players) was from Miller Audio Research.
That pegs you with great accuracy. The Miller Audio Research unit
is a really nice system that is optimized for one thing that it does
very well - tests for quality differences between CD players. Let
me guess. You are an audiophile, subscribe to THE ABSOLUTE SOUND or
STEREOPHILE, think that STEREO REVIEW is a bit off base at times,
and spend a lot of time training your ears to hear subtle differences
in audio gear. (or maybe you are a tech who services that market).
If I am right about you, I would like to add that, in my opinion,
the state of the art in audio would be stuck in 1950 without folks
like you. That being said, the Miller unit is of very little use
outside of the specific job it was designed to do. We are
measuring jitter at a level where you can actually count the atoms
that make the edge of the pit. Orders of magnitude more accurate.
Now try for a moment to understand my world. I design Laser Beam
Recorders that make the metal masters that are used to make your CDs.
I make a point of understanding the concerns of audiophiles.
On one LBR, we incorporated a 700 pound flywheel floating on
an air bearing, on the theory that our golden ears customers
could hear speed variations that we couldn't measure. Try to
understand that a million dollars gets you a medium grade LBR.
In my world, we would use something from CD Associates
[ http://www.cdassociates.com ], Atomic Force Microscopes with
DiscTrak systems [ http://www.a1.com/asm/disctrak.htm ], etc.
We can do better measurements than Miller Audio Research can,
but we have to pay more for a tester than you would for a new
home.
>Now, quick, prove that you knew that before I told you,
Feel free to read my resume at [ http://users.deltanet.com/~guymacon ]
And call my employer asking for a reference.
>or that you have a clue about what difference popularity of a piece
>of test equipment makes
It makes a difference when talking to Michael Kagalenko, who
(unlike you) has never measured any parameter of any crystal
oscillator.
>to the fact that nearly every statement you've made in
>this thread is provably and utterly false.
You know, your previous posts always struck me as quite reasonable
and friendly. Why the Jeckel and Hyde bit? You have never bothered
to raise a single objection to what I was saying, yet now you
decide that I am never right. May I assume from this that you are
in agreement with Michael Kagalenko's opinions about how crystal
oscillators work? Could you describe for me what you saw when you
measured a "thermal drift" that is not crystal aging and that
diverges from the starting point in a brownian motion like manner?
May I assume from this that you are in agreement with Michael
Kagalenko's opinions that comparing a crystal oscillator against
an Internet time server is a good way of generating random numbers
suitable for cryptography? These would seem to be logical
conclusions if you really believe that nearly every statement I
have made in this thread is provably and utterly false.
>I guess if nothing else, if anybody admits that you're right about
>anything in this thread, it WILL make a difference to cryptography: a
>"zero-knowledge proof" used to have a well-defined meaning, and it did
>NOT refer to somebody like you with zero knowledge of the subject
>matter convincing people of something that was utterly wrong!
Do you have any specific areas where you think that I am wrong?
Generic attacks such as the above are of little use when trying
for technical accuracy. They are only good at making people
mad, and I am pretty much immune to that effect. I would be
most interested in any specific objections you might have.
------------------------------
From: "cedric frost" <[EMAIL PROTECTED]>
Subject: Security of Kremlin (PC software): Insecure implementation?
Date: Sun, 30 Jan 2000 05:55:54 -0500
I'm currently using a program called Kremlin (Mach5 software,
http://www.mach5.com/) to encrypt local files. It has a nice variety of
algorithms and an unobtrusive context-based interface.
But there is something about it that concerns me. When I double-click an
encrypted file (encrypted files are overwritten as *.kgb), I am prompted for
a passphrase (key). If I enter an incorrect key, instead of decrypting the
file to gibberish, it pops up a dialog that says "Incorrect Passphrase." I
am no security expert, but it seems to me that in order for this software to
know that my key is incorrect, it must be storing some information about my
key in this .kgb file. Anyone have any thoughts on this?
It might also be worth noting that Kremlin claims to apply SHA to the key
before using it for encryption/decryption. Would this allow the scenario I
described to be implemented in a way that would not put the key at risk? For
example, if the hash value was stored in this .kgb file, which I assume must
be the case.
Any thoughts on the pros and cons of this implementation, or any other
thoughts about this software would be appreciated. Any other recommendations
for local file-by-file encryption software would also be appreciated.
Thank you,
Cedric
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm?
Date: Sun, 30 Jan 2000 11:10:55 GMT
Vernon Schryver wrote:
> In article <[EMAIL PROTECTED]>,
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> >> >It's pretty evident to people who've dealt extensively with both,
> >> >that little-endian is "more natural" from the point of view of
> >> >arithmetic and addressing. ...
> Are you are saying ...
No, I said what I said.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is there a practical guide to using crypto?
Date: Sun, 30 Jan 2000 11:28:31 GMT
JCardinal wrote:
> 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?
Encrypting a file for a single user is a special case; in a more
general use of encryption, data is protected in transit to some
other person, and both communicants share the key (assuming a
symmetric encryption system, not public-key).
Normally, if a 128-bit key is needed, it will be generated one time
and a copy provided to both communicants to go onto their key ring.
The generation process will very likely use semi-random environmental
variables combined perhaps with the kind of user input you describe.
> And if this is so then is it not fairly easy to try every possible
> key they might have typed to generate a password?
16 printable ASCII characters means something like 92^16 possible
keys, less than 2^128 but not by enough to make brute-force search
feasible. If user input were used directly as the key, without
being combined with semi-random variables, then one could search
first the things users are more likely to type. That's known as a
"dictionary attack" and is used by common password crackers.
> 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.
Keys used in symmetric systems are usually stored somewhere.
There are ways to prevent "replay" of a stolen password; for example,
ACE SecurID cards have unique serial numbers which are combined with
a clock and a user-input PIN to create an authentication code, used
instead of a password to log into a secured system. Kerberos is
somewhat similar but uses public-key encryption to check one's
password and to grant a token used to encrypt a session. Something
along these lines could be done to communicate data securely, and
probably is being done.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Keyword Cipher Cracker program
Date: Sun, 30 Jan 2000 11:30:31 GMT
Glenn Larsson wrote:
> Question: Are there any other cryptological museums on this
> planet? (As in more near Sweden? :o)
I don't know about Sweden, but Bletchley Park has been turned into
a museum.
------------------------------
From: Andy <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm - joke :-)
Date: Sun, 30 Jan 2000 22:59:13 +1000
Reply-To: [EMAIL PROTECTED]
I went to a new restaurant for a curry the other day. I was
supprised that they served the desert first, then the vindaloo,
and finally the poppadams. When I paid the bill (check), I asked
why the meal was served backwards. The waiter said "Didn�t you
know sir? This is a little Indian restaurant". Tee hee.
------------------------------
From: [EMAIL PROTECTED] (Steven Siew)
Subject: Re: Is there a practical guide to using crypto?
Date: 30 Jan 2000 11:55:35 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
One thing I really want to know is if VISA card number consists of
16 digits with two digits for month and four digits for year, whats
to stop someone from attempting every possible 22 digits combination
until they find one which works?
It seems like it would be a trivial matter if the person knew how
many digits are involved in VISA CARDS. I know I'm missing something
fundamental because it's not supposed to be that easy, ant thats why I
dont want to use VISA CARD until I understand it a little better.
[Use your brain man! It's free. ]
[Steven Siew]
In article <[EMAIL PROTECTED]>, JCardinal wrote:
>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?
>
>It seems like it would be a trivial matter if the person knew what
>encryption algorithm was used. I know I'm missing something fundamental
>because it's not supposed to be that easy, and thats why I dont want to use
>it until I understand it a little better.
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4lCYCXZ8NVwemPIQRAkBbAJ96GyDVA/ItXuyN3u4Z9Ue0j5n8EQCgl5px
Bsb9DL2/Ipnxm/pVPmfxN0c=
=X8jD
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 31 Jan 2000 07:06:53 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Wireless PKI now or later
Supposedly bandwidth isn't going to be an issue , according to their web
pages . However , how many companies can afford PKI for wireless - palm
pilot ,window ce or smart phones. They seem to be all Java based.
Question : how good are the XML digital certificates ? If the cost is
reasonable and XML is good for non-pki encryption it looks like I will
be using it.
------------------------------
From: [EMAIL PROTECTED] (Chris Adams)
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sun, 30 Jan 2000 12:07:42 GMT
On Sun, 30 Jan 2000 02:07:24 GMT, Dave Mundt <[EMAIL PROTECTED]>
wrote:
>>can't be cracked. You'll find a long list of cracks for
>>"dongle-protected" programs in the crack groups. It's just a big scam
>>by the sleazy copy-protection companies who claim that their schemes
>>are "absolutely impervious" to cracking even though widely-known
>>cracks have been around for years.
>>
> This is true. The fact of the matter is that NO encryption scheme
>is totally impervious to attack. However, the point is, of course, to
>make it simpler for the average user to bite the bullet, whine and pay
>the cost of the dongle.
Dongles seem to be the easiest way to annoy your users and guarantee strong
demand for either cracks or a competing product. Frankly, I wish software
vendors would accept the fact that you cannot prevent the dishonest people from
being dishonest and the honest ones will pay you anyway. Copy-protection is
just a massive waste of resources, particularly as the time spent developing or
installing the snake-o^W^Wfoolproof copy-protection scheme is usually dwarfed
by the support time spent when it fails to work properly..
------------------------------
** 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
******************************
