Cryptography-Digest Digest #828
Cryptography-Digest Digest #828, Volume #10 Mon, 3 Jan 00 07:13:01 EST
Contents:
Re: On documentation of algorithms (wtshaw)
Re: Wagner et Al. (Tom St Denis)
Re: meet-in-the-middle attack for triple DES ("Rick Braddam")
Re: meet-in-the-middle attack for triple DES (Mok-Kong Shen)
Re: On documentation of algorithms (Mok-Kong Shen)
crypto and it's usage (Tom St Denis)
Re: news about KRYPTOS ("collomb")
Re: Wagner et Al. (Guy Macon)
Re: crypto and it's usage (David A Molnar)
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On documentation of algorithms
Date: Sun, 02 Jan 2000 22:47:44 -0600
In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:
In my humble understanding (apology if I erred) one of the major
issues in a recent thread initiated by John Savard has been the
question (not entirely new) of whether one should always be
satisfied/contented with certain 'standard' amount of security
(presumably determined adequate through the professional
judgement of well-known experts and sanctioned by the esteemed
authority of capable governmental institutions) or that one
should rather not lose sight of needs/opportunities to obtain
additional security through appropriately introducing 'added
complexity' into one's encryption system as a (conservative,
maybe 'over-anxious') means to further safeguard one's
individual/specific requirements of communication security.
In a similar vein I like to (re-)raise the (also not entirely new,
but perhaps heretic) question of whether the documentation of
'standard' encryption algorithms in the current practice has been
of such detail/openess and degree of comprehensibility as to
render these fully understandable and hence trusted beyond
question through reasonable efforts/expenditure of study without
demanding mathematical and other knowledges/expertises/expriences
that are at least way beyond the common repertoires that the
universities generally provide to their undergraduate students of
diverse natural science disciplines. (My personal answer has been
negative till the present.)
I mean a true (as against forced/misguided/negligent) acceptance
of and confidence in an encryption algorithm is to be praticularly
and well distinguished from the same for any other utility or
consumer goods that are available to the public. While barely
even a mechanical engineer (unless he has psychartric problems)
who purchases a car would ever dream of the idea of asking his
colleages at the manufacturer's to explain the design
details/rationales of the automobile and its production process
and provide the data from the safety and other evaluation tests,
it is my firm belief that a real and genuine trust in any
encryption algorithm by the public can only be arrived at though
a sufficiently wide-spread full (as against superficial/minimal)
understanding (or at least the possibility of such an
understanding) of the design and functioning of the same. This
very sigular situation pertaining to crypto is because, among
others, that crypto has been, is and will always be a science
covered with a veil of secrecy/mystery in my humble opinion.
In particular, a number of governments don't seem to desire that
there will be genuine privacy of informations of the common
people, as evidenced by their attitudes towards key-escrows,
Wassenar Agreements, etc. There will always be facts/knowledges
purposedly withheld from the public or the possibility of such
could hardly be satisfactorily eliminated/ascertained/convinced
in conventional ways. Hence it is indispensable for an encryption
algorithm to be really trusted and profitably used by the public
that the route to its thorough understanding be rendered as simply
accessible (to a sufficiently large proportion of the people) as is
technically/conceivably feasible. It is not sufficient/appropriate
that the designers of crypto algorithms take the standpoint that
those with enough intelligence and diligence/willing would
certainly be able to understand their works or that, conversely,
failure of understanding is unquestionably attributed to the
laziness or lack of intelligence on the part of the 'student'.
(A related phenomenon, albeit concerning 'newly invented'
algorithms, may be occasionally found in such challenges that
ask one to examine a piece of poorly documented C-code or simply
decipher a message encrypted with the masterpiece involved.)
Having said in essence my own admittedly controversial/problematic
humble opinions, I like to leave the platform to the dear readers
of the present article. I should appreciate seeing some fruitful
discussions, since I believe that an ever increasing number of
standard encryption algorithms/techniques will be put into use in
the explosive communication volumes of the new
Cryptography-Digest Digest #829
Cryptography-Digest Digest #829, Volume #10 Mon, 3 Jan 00 12:13:01 EST
Contents:
Re: meet-in-the-middle attack for triple DES (DJohn37050)
Re: Prime series instead (Re: Pi) (John Myre)
Re: crypto and it's usage (Keith Monahan)
Re: Attacks on a PKI (Shawn Willden)
Re: Attacks on a PKI (Shawn Willden)
Re: Attacks on a PKI (Shawn Willden)
Re: Wagner et Al. (Steve K)
Re: stupid question (No Spam)
Re: stupid question (No Spam)
Re: Bits 1 to 3 (Re: question about primes) ("Tony T. Warnock")
Re: Attacks on a PKI (Larry Kilgallen)
Re: Wagner et Al. (Tom St Denis)
Re: Prime series instead (Re: Pi) ([EMAIL PROTECTED])
Re: crypto and it's usage (Steve K)
Re: "Variable size" hash algorithm? ("Peter K. Boucher")
Re: Prime series instead (Re: Pi) ("Tony T. Warnock")
List of english words ("John Lupton")
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: meet-in-the-middle attack for triple DES
Date: 03 Jan 2000 14:24:54 GMT
There are unique keys per transaction for PIN protection keys. This idea has
been known. A problem with it is the set up time, changing the key all the
time means normal performance speed ups are not possible.
Don Johnson
--
From: John Myre [EMAIL PROTECTED]
Subject: Re: Prime series instead (Re: Pi)
Date: Mon, 03 Jan 2000 07:33:46 -0700
"John E. Gwyn" wrote:
"NFN NMI L." wrote:
The summation of the reciprocals of all the primes is infinite. Who
knows what happens when you have alternating subtraction and addition?
I think it still diverges, but I don't have a proof.
Any alternating sum (alternating addition and subtraction) where the
terms decrease (to zero) converges. Note that any two consecutive
values define boundaries on the sum; since the limit of the separation
of these values is zero then the sum is indeed defined.
(Picture the sums on the line; note that it goes back and forth,
each time moving a shorter distance; the sum converges because in
the limit the distance is zero).
John M.
--
From: Keith Monahan [EMAIL PROTECTED]
Subject: Re: crypto and it's usage
Date: Mon, 03 Jan 2000 14:58:21 GMT
Tom,
I use encryption on a daily basis to protect my privacy. With
the government invading our privacy frequently, I feel it
is important to protect ourselves. Who knows, what is legal
today might not be legal tommorow. It used to be legal to
listen to cellphones via a scanner -- now it's a big crime.
Incidentally, if the cellphone industry had taken steps to
protect people's privacy via encryption, they wouldn't have
had to lobby Congress so hard to ban the manufacturing of
cellphone receiving scanners.
This is why I like encryption. Laws don't stop criminals because
criminals don't obey laws. I don't want it *possible* to violate
my privacy by violating a simple law. Because even putting that
person in jail DOES NOT GIVE ME MY PRIVACY BACK.
So, instead of protecting privacy via LAWS, our privacy has to
be guaranteed by technology. And yes, I know we don't have
any provably secure USABLE algorithms for encryption. I feel
an argument can be made that says that it is easier to break
an unenforcable law than it is to break Blowfish. It all depends
on your threat model...
I run realtime on-the-fly harddrive encryption under Windows95.
Not the most secure platform, but I do things like disabling
virtual memory, clearing registry entries(like recent file entries),
wiping file slack space, wiping unused drive space, etc. I'm
really trying to avoid the side-channel attacks as that is probably
more likely than someone breaking 256-bit Blowfish. And plus,
I use good passphrases.
So, life threatening? No. Important? Yes.
I also use PGP occasionally to exchange email between friends
when discussing things of a delicate nature. And of course,
like the other gentleman mentioned, I use SSL to secure
private things like account balances at pitt.edu -- but never
my credit cards.
Sorry if this got a little OT,
Keith
Tom St Denis wrote:
I was just wondering how many people here actually use crypto. I mean
almost anyone here can pull apart ideas and have fun, but does anyone
use what's left?
I personally use it just for fun, and sometimes to keep things
private. Nothing life threatening... Anyone else?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
Date: Sun, 02 Jan 2000 17:54:56 -0700
From: Shawn Willden [EMAIL PROTECTED]
Subject: Re: Attacks on a PKI
Mickey McInnis wrote:
Do Netscape and IE require that the certificates be specific to the
domain name, or does it just require that a certificate be used?
They check the domain name. Of course, DNS is not a secure service and can be spoofed
easily by someone with appropriate access...
Shawn.
--
Date: Sun, 02 Jan 2000 18:05:53 -0700
From: Shawn
Cryptography-Digest Digest #830
Cryptography-Digest Digest #830, Volume #10 Mon, 3 Jan 00 13:13:01 EST
Contents:
Re: meet-in-the-middle attack for triple DES ("Trevor Jackson, III")
Re: stupid question ("Trevor Jackson, III")
Re: Wagner et Al. (Guy Macon)
Re: crypto and it's usage (Roger Carbol)
Re: meet-in-the-middle attack for triple DES (Bernie Cosell)
Re: news about KRYPTOS ("John E. Gwyn")
Re: On documentation of algorithms ("John E. Gwyn")
Re: how good is RC4? ([EMAIL PROTECTED])
Re: Wagner et Al. (Guy Macon)
Re: Cryptography in Tom Clancy (Eric Lee Green)
Re: crypto and it's usage (Eric Lee Green)
Re: Wagner et Al. (wtshaw)
Re: stupid question ("John E. Gwyn")
Re: news about KRYPTOS ("Ferdinando Stehle")
Re: Bits 1 to 3 (Re: question about primes) ("John E. Gwyn")
Date: Mon, 03 Jan 2000 12:16:29 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: meet-in-the-middle attack for triple DES
Rick Braddam wrote:
Bill Unruh [EMAIL PROTECTED] wrote in message
news:84ol8a$kik$[EMAIL PROTECTED]...
In [EMAIL PROTECTED] Mok-Kong Shen
[EMAIL PROTECTED] writes:
]If one could manage to have each block encrypted by a different key,
]then such attacks would in my humble opinion be pointless for any
]common block encryption algorithm that offers sufficient difficulty
]to determine the key from only one single pair of corresponding plain
]and cipher texts. On the the further assumption that the key stream
]is not (or barely) subjected to inference, this would seem to leave
]the adversary no other means in practice but to brute force the
]'key' that generates the said key stream. (Note that the key stream
Sure, but it will be slow. If your key stream is sufficintly strong,
then just xor will probably be fine. many block encryptions take a
long
time to set up the key schedule, and you have to go through this for
each and every block.
Suppose you use Wei Dai's Crypto++ library, and instantiate 2 or more
instances of Blowfish or TwoFish, each with a different key. Then pass
the first block to the first instance, the second block to the second
instance, the third block to the first instance, alternating
blocks/instances to the end of the message. That way key setup is only
done once at the beginning, and there is no relationship between the odd
and even blocks. It would be more difficult to do in C code, but still
possible.
Would that make analysis more difficult?
Would it make a difference if each instance "shared" the IV vs. each
having its own?
If more secure, what would be the equivilent single-instance key length
(assume each uses 128 bit key)?
Just curious,
Rick
It would be unreasonable to expect the Opponent is not aware of your
multiplexing mechanism. Given he knows which blocks go together he mounts
one attack on one thread of the multiplexer.
--
Date: Mon, 03 Jan 2000 12:20:51 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: stupid question
No Spam wrote:
Trevor Jackson, III wrote:
No Spam wrote:
Joseph Ashwood wrote:
I have a stupid question. But what is the difference between a key of a
stream cipher and a key of an one-time-pad ???
The basic difference is where in the process they are used.
The basic algorithm is:
data--|
|
RNG--Cipher-output
The difference is where the key is used. In the case of a one time pad the
key replaces the RNG (the RNG having been run prior, and being a true Random
Number Generator). In a stream cipher the key is used as a seed to a
_pseudo_ Random Number Generator (called a pseudo RNG because it does not
generate truly random numbers). That is the current typical usage, a while
back there was actually some discussion about what constitues a stream
cipher and what constitutes a block cipher, and I can extend it to include
OTP easily. My personal opinion is that a stream cipher function has as it's
inputs data, key, and the previous data (although the effect of the previous
data is often limited to the length), a block cipher inputs only data and
key, an OTP is simply a block cipher where the key is exactly as long as the
data (we have actually discussed some other issues here but that's the
basics).
Joseph
Joseph,
I too have a stupid question I hope you will answer for me.
It seems that most of the postings in this news group view the use of
PRNG in encryption as very poor.
If create a key pass phrase: "ABCDEGGH" and use the first three, two
byte pairs (AB, CD, and EF) as 16 bit seeds for a PRNG.
Taking the ouput streams fron the PRNG for each of the three seeds, and
XORing the output into a 10K buffer. So the PRNG's output was XORed
into the 10k buffer three times.. each with a different
Cryptography-Digest Digest #831
Cryptography-Digest Digest #831, Volume #10 Mon, 3 Jan 00 16:13:01 EST
Contents:
Re: List of english words ("John E. Gwyn")
Re: crypto and it's usage ("Kasper Pedersen")
Re: news about KRYPTOS (wtshaw)
Re: SIGABA/ECM Mark II (John Savard)
Re: news about KRYPTOS ("John E. Gwyn")
Re: Wagner et Al. ("John E. Kuslich")
Re: cracking Triple DES ([EMAIL PROTECTED])
Re: On documentation of algorithms (Medical Electronics Lab)
Re: news about KRYPTOS ("John E. Gwyn")
Re: Wagner et Al. ("John E. Kuslich")
Re: how good is RC4? (Johnny Bravo)
Re: List of english words (James Pate Williams, Jr.)
Re: List of english words ("John Lupton")
Re: List of english words ("John Lupton")
Re: List of english words (TohuVohu)
Re: Q: transcendental pad crypto (Paul Koning)
Re: "Variable size" hash algorithm? ([EMAIL PROTECTED])
Re: crypto and it's usage ([EMAIL PROTECTED])
Certficate Question ("Clint Eastwood")
Re: Bits 1 to 3 (Re: question about primes) ("denis.feldmann")
From: "John E. Gwyn" [EMAIL PROTECTED]
Subject: Re: List of english words
Date: Mon, 03 Jan 2000 12:07:26 -0600
John Lupton wrote:
Can someone tell me where on the web I can find a list of words in
english. I want to do some frequency analysis on n-graphs (i.e.
mono-, di-, tri-, tetra-) and words with certain n-graph patterns
too.
Ideally I'm looking for a text file with every word from aardvark
to zulu.
Nearly every UNIX system has /usr/dict/words.
I don't know how you could make a "frequency analysis" that means
anything on a word list, where frequency of usage is not reflected.
--
From: "Kasper Pedersen" [EMAIL PROTECTED]
Subject: Re: crypto and it's usage
Date: Mon, 3 Jan 2000 18:10:17 +0100
"Tom St Denis" [EMAIL PROTECTED] wrote in message
news:84ppj4$slo$[EMAIL PROTECTED]...
I was just wondering how many people here actually use crypto. I mean
almost anyone here can pull apart ideas and have fun, but does anyone
use what's left?
I have inoutgoing email that needs (=would get me in trouble if not)
encryption every 3.6 days. Plus I use an encrypted volume to keep adult
stuff away from others. All mail goes on that one, so that's every day.
SSL - about once a week.
/Kasper
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: news about KRYPTOS
Date: Mon, 03 Jan 2000 12:36:45 -0600
Here are some related thoughts I have not had a chance to follow up on:
The folded nature of the sculpture mign indicated that the two pages have
some result meaning when actually one on top of the other. That
characters are cut through suggests that somehow, again, that one page
affects another. Since what you see from the otherside is backwards, that
may suggest a relationship. Keep in mind that the extra letters in the key
make it have the same number of characters as the key.
I could be wrong again, as several other ideas have not panned out to
quickly useful.
--
Considering that the best guess is that Jesus was born in 4 BC,
for the purists, fate worshipers, and absolute prognosticators,
you all missed your boat fome time ago, as hype mongers rejoice.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SIGABA/ECM Mark II
Date: Mon, 03 Jan 2000 11:22:20 GMT
[EMAIL PROTECTED] (JTong1995) wrote, in part:
Does anyone know if the SECRET patent that Rowlett and Friedman received for
the cryptographic principles implemented into the SIGABA / ECM Mark 2 have been
released to the public?
The only patents on the IBM patent server for "William Friedman" are
those of a physician, Dr. William A. Friedman, at this time, it
appears.
John Savard (jsavardatecndotabdotca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: "John E. Gwyn" [EMAIL PROTECTED]
Subject: Re: news about KRYPTOS
Date: Mon, 03 Jan 2000 12:27:50 -0600
Ferdinando Stehle wrote:
why the Quagmire III table KRYPTOSABC... is surrounded by
ABCDEFGH... (the normal alphabet) on top, on bottom and on the right ?
Those indices are required in order to *use* the table.
...and why the KRYPTOSABCD... string is longer than 26 chars
(indeed it is 30 chars long) ??
I already explained that. Without the redundant 4 extra columns
to bring the width of the right-hand side up to that of the left-
hand side, the sculpture would be aesthetically unbalanced.
--
From: "John E. Kuslich" [EMAIL PROTECTED]
Subject: Re: Wagner et Al.
Date: Mon, 03 Jan 2000 11:12:20 -0700
Daniel Roethlisberger wrote:
Decent encryption software cares for its sensitive data. It locks memory in
which it allocates memory for keys and such, so it doesn't get paged on hard
disk. It wipes memory after usage. It also tries not to send it through
windows mechanisms like the windows messages.
No. Total myth. Software under Windows can do absolutely nothing
Cryptography-Digest Digest #832
Cryptography-Digest Digest #832, Volume #10 Mon, 3 Jan 00 16:13:01 EST
Contents:
Re: "Variable size" hash algorithm? (Boris Kazak)
Re: On documentation of algorithms (Mok-Kong Shen)
Re: meet-in-the-middle attack for triple DES (Mok-Kong Shen)
Re: Bits 1 to 3 (Re: question about primes) ("Tony T. Warnock")
From: Boris Kazak [EMAIL PROTECTED]
Subject: Re: "Variable size" hash algorithm?
Date: Mon, 03 Jan 2000 12:18:28 -0800
Reply-To: [EMAIL PROTECTED]
"Peter K. Boucher" wrote:
Why not have your program measure the entropy of the input, then use the
input as an RC4 key, then use the RC4 PRNG to output as many bytes as
can be justified by the entropy in the input?
=
This is the reply to original poster
[EMAIL PROTECTED] (Dan Day)
Organization:
Frontier GlobalCenter Inc.
***
Try this, it reads a file, writes a file...
The program takes the filename from the simple dialog
and writes the hash into a new file with the name of the
original file and extension "h32".
Original message is divided into segments of the size
twice that of the final hash, e.g. if the final hash will
be 160 bit, the segments will be 320 bit each. The size of
the hash and segments is #defined by the HASHBLOCKSIZE
constant and can be altered according to need.
This proposed function is based on multiplication
(mod 2^32+1) with two "twists". First, however, some
background information.
The function uses one single modular multiplier
which in the program is #defined as "SEED". This number is
0x6A09E667, which happens to be the first 8 hex digits of
SQRT(2), less initial 1. The use of this number should
dispel any suspicions about a "trap door" built into SEED.
Now about the "twists". The first twist regards the
progression along the block. After the multiplication,
when the bytes of the product are returned to their places
and it is time to proceed with the subsequent multiplication,
the two LS bytes of the previous product become the two
MS bytes of the new number to be multiplied, and two adjacent
bytes of the plaintext are appended to them in order to make
this new 32-bit number. When the end of the block is reached,
the index wraps cyclically over the 2*HASHBLOCKSIZE.
For each block, there are three repetitions of two rounds
each (for those paranoid among us, there is a #define, where
one can change the ROUNDS constant to whatever desired).
Graphically a round can be visualized in the
following sketch:
( the index is circular mod 2*HASHBLOCKSIZE )
___
1-st multiplication
( - 32-bit number to multiply)
___
2-nd multiplication
ppPPXXxx
(ppPP - product of the first multiplication,
PPXX - 32-bit number to multiply)
___
3-d multiplication
PPXX
( PPXX - 32-bit number to multiply)
...
Last multiplication
XXPP
( The index is cyclically wrapped over -
PPXX - 32-bit number to multiply)
___
This arrangement allows an ultra-rapid propagation
of all changes across the entire block - there is complete
avalanche after the 2-nd round and then after each
subsequent round.
The second twist was introduced later, after Paul Onions
pointed out that it is possible to easily produce collisions
if each subsequent text block is simply XOR-ed into the text
buffer without any further precautions.
In all the discussion below I shall assume the 320-bit
block and 160-bit hash, just for example.
Since modular multiplication is a one-to-one transformation,
there is no way to find a different single 320-bit block which
would be transformed to the same value. A single bit change in
the original 320-bit block will produce unpredictable avalanche
changes after 2 rounds.
However, after we process the second block, there is a
possibility to take this 320-bit value, reverse transform it
via our modular multiplication with the multiplicative inverse,
take an arbitrary 320-bit value, XOR it with the buffer, again
reverse transform the result with the multiplicative inverse,
and thus obtain two bogus blocks which will together hash to
the same value as two blocks of original message. This is
really a direct way to produce collisions.
This is why I introduced the "accumulator". The intermediate
results of the multiplicative
