Cryptography-Digest Digest #778, Volume #9 Fri, 25 Jun 99 23:13:03 EDT
Contents:
Re: one time pad (John Savard)
Re: Hasty Pudding Cipher -- update (William Tanksley)
Re: How does 3DES work? (John Savard)
Re: TeraPi (William Tanksley)
BAN Logic considered useful? (Jim Flanagan)
Re: one time pad (William Tanksley)
Re: IDEA-128 (John Savard)
Re: DES-NULL attack (John Savard)
Re: DES-NULL attack ([EMAIL PROTECTED])
Re: DES-NULL attack (JPeschel)
New idea for block cipher (please comment) ([EMAIL PROTECTED])
Re: sha-1 C/C++ source code ("Richard Parker")
Re: Converting arbitrary bit sequences into plain English texts
([EMAIL PROTECTED])
Re: one time pad (S.T.L.)
Re: TeraPi (Greg Ofiesh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 22:56:22 GMT
AllanW <[EMAIL PROTECTED]> wrote, in part:
>Note that the CPU's clock drift is not connected to the
>counter's clock drift in any way.
As another poster has noted, free-running oscillators tend to lock up
to any RFI in the vicinity, such as another oscillator might produce.
Also, the major source of frequency drift in an oscillator is
temperature, and so two oscillators in the same apparatus are likely
to be subjected to common influences in that area as well. (Both would
have been turned on at the same time, besides being in the same
room...)
But there are plenty of other relatively inexpensive ways to make
passable physical RNGs, such as thermal noise from a resistor. Really
good ones, though, are harder to make.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: Hasty Pudding Cipher -- update
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 22:57:59 GMT
On 23 Jun 1999 19:53:43 GMT, [EMAIL PROTECTED] wrote:
>What the %@$^ is 1/3 of a bit?
Would you actually like to know, or are you merely enthusiastic?
>Regards, Noah Paul <[EMAIL PROTECTED]>
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How does 3DES work?
Date: Fri, 25 Jun 1999 23:05:11 GMT
[EMAIL PROTECTED] wrote, in part:
>Does 3DES work because not all outputs are possible? Because the key
>is smaller then the input it's not a perfect permutation (it's
>complete ... but ?).
>For example 2^64 possible inputs but only 2^56 possible outputs for
>that one input.
>If this argument is true then ciphers with larger keys will most likely
>not work because there would be a shortcut (i.e mitm).
Actually, you're describing single-DES. It has a 56-bit key, and so
there are only 2^56 possible encipherments of a 64-bit input block.
Triple-DES uses a key of two or three times that length, and
meet-in-the-middle IS a shortcut that can be used in attacking it.
Which is why it is sometimes used with a 112-bit key, as that is its
maximum effective security.
However, if one is enciphering 64-bit blocks, there are (2^64)!
possible ways to describe what each block becomes. That enormous key
space is the limit, not 2^64, to the key for a block cipher with a
64-bit block, since it is useful that even if an opponent knows that
block A is enciphered to B, he still doesn't know what block C
becomes.
Actually, though, although meet-in-the-middle only applies to *some*
large-key block ciphers, there is another shortcut attack that
requires only 2^64 operations to break any block cipher with a 64-bit
block. Terry Ritter outlined it: the "codebook attack". If one has
2^64 different known plaintexts, one has a table for the entire
operation of the block cipher, however long its key.
So you're right - there is a shortcut when the key is bigger than the
block - even if it isn't related to meet-in-the-middle. Opinion is
divided, though, on whether that shortcut is worth worrying about.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: TeraPi
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 23:05:04 GMT
On Thu, 24 Jun 1999 20:36:39 GMT, Greg Ofiesh wrote:
>I had such good feedback on one time pad that I think I will venture to
>propose a new encryption strategy for your amusement and critique. I
>call it TeraPi.
[algorithm snipped]
>What say all of you?
It has some interesting characteristics -- it's got a gaping possibilty of
a hole because it's using such a predictable sequence over and over again.
But that might not be a problem.
The real problem is that nobody qualified is going to review it, so we'll
always suspect (correctly or not) that it's got holes in it. If you want
to design an encryption alg, you have to first crack lots of algorithms
invented by skilled people and publish papers about the cracks which are
widely read and recognized.
Then publish your algorithm; all of the people who designed the algorithms
you demolished will desperately search for a weakness. Onlookers will
know how motivated they are, so will have every reason to trust your
algorithm if they can't find a problem.
After about five or ten years, if your algorithms stands out from the
others, it might get used. Odds are that it'll be used in a product which
has a massive security hole, and your algorithm will be discredited, and
your enemies will rejoice.
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: Jim Flanagan <[EMAIL PROTECTED]>
Subject: BAN Logic considered useful?
Date: Fri, 25 Jun 1999 16:06:09 -0700
Reply-To: [EMAIL PROTECTED]
I am wondering if BAN Logic is still considered a acceptable method
for the analysis of authentication protocols, or if there are more
recent developments in this area.
Please respond via email. I will post a summary to the group.
Thanks,
--
Jim Flanagan Collective Technologies
[EMAIL PROTECTED] http://www.colltech.com
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 22:37:37 GMT
On Fri, 25 Jun 1999 21:57:23 GMT, AllanW wrote:
> [EMAIL PROTECTED] wrote:
>In any case, my device was for exposition only. My real
>question is, would it be possible to create a hardware
>high-speed true-random-number generator without spending
>a fortune?
Certainly, so long as you didn't demand proof of the "true random"ness.
One example of a good way is to take a 3-gate NOT cycle (that is, hook a
NOT up to a NOT up to a NOT, then attach the output of the last one to the
input of the first). Put that on a chip, and put a few others like it at
other places on the chip. Any wire in the NOT gate cycle will flip
between 0 and one at a rapid rate; call one of those wires the output. XOR
all of the outputs together, and you have a very noisy signal. Use it to
feed into a SHA or DES algorithm, and the result should be a decent random
number with good characteristics.
You could build a prototype for this on a breadboard.
>By high-speed I mean that the CPU coul read
>(at least one bit of) a new random number from the device
>as often as it wished, without having to do any
>synchronization, and without distorting the random factor
>(i.e. because of synchronized clocks). And by true-random-
>number, I mean the usual: regardless of previous values
>received (or the timing when they were received), every
>possible outcome is equally likely for the next value.
You'd want a FIFO for the random numbers, together with an 'overflow'
indicator and interrupt. There's no way to be sure the processor can't
draw out numbers too fast.
>Sent via Deja.com http://www.deja.com/
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: IDEA-128
Date: Fri, 25 Jun 1999 22:40:55 GMT
Casey Sybrandy <[EMAIL PROTECTED]> wrote, in part:
>That's it. Decryption is done similarly to normal IDEA, you just have
>to take into account the different operations. The reasoning behind
>this is simple: the reversible multiplications of IDEA, where all
>multiplication was done mod 2^16 + 1, had to be replaced with something
>more reversible. I selected the keyed rotate function because it has
>been proven to work well with multiplications and it is simple.
I just came across something similar: the cipher Akelarre. But
apparently it had some problems.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES-NULL attack
Date: Fri, 25 Jun 1999 22:44:38 GMT
[EMAIL PROTECTED] wrote, in part:
>Let a plain text block contains only bits with NULL value.
>Then correspondent cipher block is well-defined function
>of the encryption key, which can be recovered.
Yes, it is a well defined function. Unfortunately, it is still a
difficult function to evaluate: this is why DES is considered to be
resistant to known-plaintext attacks.
It's easy, given a key, to calculate the DES encryption of any block.
Given the plaintext and cipher values, finding the key is intractable.
(Except, of course, that a brute force search of 2^56 possibilities
isn't _impossible_ any longer.)
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES-NULL attack
Date: Sat, 26 Jun 1999 00:32:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Given the plaintext and cipher values, finding the key is intractable.
> (Except, of course, that a brute force search of 2^56 possibilities
> isn't _impossible_ any longer.)
I always thought that any brute force attack was possible just really
difficult to maintain after say all energy in the universe converts to
matter and the computer detoriates... etc...
Just poking around. Of course for keys > 64 bits it's quite infeasible
to search the key space. Even at 64-bits there are problems (note
distributed has been going for about 2 years now, after one message!)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: DES-NULL attack
Date: 26 Jun 1999 01:06:35 GMT
> [EMAIL PROTECTED] writes:
> Of course for keys > 64 bits it's quite infeasible
>to search the key space. Even at 64-bits there are problems (note
>distributed has been going for about 2 years now, after one message!)
I wouldn't bet that a 64-bit key is safe, either, depending on the attacker's
resources. Consider an intelligence agency with plenty of money to
spend on ASICs.*
Joe
*A Report by an Ad Hoc Group of
Cryptographers and Computer Scientists
Bruce Schneier
Eric Thompson (et.al.)
January 1996
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: New idea for block cipher (please comment)
Date: Sat, 26 Jun 1999 00:29:33 GMT
I have began research into a new type of block cipher. It is pretty
much a multipermutation type however it has some interesting properties.
I wanted to try using a keyed bit permutation as a new primitive. What
this means is that if you have a block of say n-bits you will have an
array of n bits. Then you shuffle the bits (kinda like the IP and FP
of DES) based on a round dependant permutation. Obviously one must
store the permutation orders in an array (as you cannot base it on the
contents of the block).
Hmm sounds complex. Heres the jist of it
perm[n] is an array of n integers which are unique. They are shuffled
to form a permutation of the input. Basically like the RC4 shuffle.
for i = 0 to n-1 do
out[i] = in[perm[i]]
(out[] and in[] are arrays of bits)
Will shuffle the bits in the block.
Each round has it's own perm[] array. Now to promote diffusion I used
the IDEA style 16x16 sbox. The goal was to promote rapid diffusion. I
would have used smaller sboxes but I was kinda skeptic of the avalanche.
I would really really appreciate any feedback. The goal of the bit
permutation is to hopefully destroy any attempt to model the cipher
using statistical attacks. Of course I don't think this is always
possible...
Anyways if anyone wants to see compact code that actually performs the
above give a shout. It's quite easy to follow as I did zero
optimizations, basically to help promote discussion.
(Note I didn't jump the gun into releasing source code.)
Thanks,
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: sha-1 C/C++ source code
Date: Sat, 26 Jun 1999 01:14:47 GMT
> Is there a site to get sha-1 C/C++ source code?
Vasav,
A good public domain implementation of both SHA and SHA-1 in C is
included with the source to the Perl SHA extension.
Readme is available at the following URL:
<http://theory.uwinnipeg.ca/CPAN/data/SHA/README.html>
Source is at the following URL:
<http://theory.uwinnipeg.ca/scripts/CPAN/authors/id/UWEH/SHA-1.2.tar.gz>
-Richard
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: Converting arbitrary bit sequences into plain English texts
Date: 26 Jun 1999 01:48:18 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
As Matthew Montchalin was reciting adverbs and prepositions:
>> > 1000 - off
>> > 1001 - on
>> > 1010 - under
>> > 1011 - over
>> > 1100 - around
>> > 1101 - true
>> > 1110 - false
>> > 1111 - maybe
Mok-Kong Shen wrote:
>> The problem is that the encoded text has to be a collection of
>> meaningful sentences in order to pass the criterion of being
>> a natural language text. Simply a bunch of words wouldn't do,
>> I am afraid.
and then wrote:
>Apology. I believe I have misunderstood you. But I don't know whether
>'around' and 'under' could be a sentence by itself.
Well, it could be a response to a question. For instance:
Where? Under! There? Around! Yes? Maybe? No? Here! Yes! Over!
But I thought that what was really clever was the idea that Boris Kazak
wrote, namely, where any given passage of ordinary text will ordinarily
be given in lowercase, but uppercase characters will represent bytes that
are 'on.' The state of Bits 4 and 6 of each such lowercase character
could be examined in this way:
(Pseudo BASIC code follows)
100 rem This subroutine examines the state of an alphabetic character
110 rem and culls out the signal from the noise.
120 rem On entering this subroutine, A=character of interest, 7 bits wide
130 rem On exiting this subroutine, S=Signal (1 Bit of Information)
140 rem and N=Insignificant Noise.
150 rem Uses and does not preserve B.
160 :
170 if A<64 then S=0 : N=0 : return : rem numeric Crud can be skipped
180 :
190 if A<96 then S=0 : N=(95-A)or64 : return
200 if A<128 then S=1 : N=(127-A)or64 : return
201 :
210 print "Hey, what the heck are you doing, using PETASCII?"
211 print " :) Don't you know there is an easier way of doing this"
212 print "simply check bit 7 for signal, because bits 0-6 can be"
213 print "stripped off as noise."
222 stop
--
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: one time pad
Date: 26 Jun 1999 02:21:08 GMT
<<Correlations or predictabilities
can exist which the usual statistical tests will not detect.>>
I didn't mention the usual. Use statistical tests that are powerful enough to
detect flaws you would be afraid of. If you are afraid of flaws that will let
an Adversary break your system after you've encrypted one hundred and thirty
seven exabytes of data, then look for them. Or don't. That's a "real-world"
problem, you know.
By the way, if a perfect, correctly working random number generator plops out a
string of zeros, GO AHEAD and XOR them with the plaintext. Why? Because if you
never do, and the Adversary later sees "Attack At Three O'Clock", then he will
KNOW something about your plaintext! Namely, that that portion did NOT say
"Attack at Three O'Clock".
Say you do XOR in the "string of zeros", and "plaintext is revealed!" I ask
you, then, how would the Adversary know that you weren't actually using a
different run of random numbers and the plaintext said instead "Moo moo
kabubu"? The Adversary doesn't, and is still completely in the dark. When
implemented correctly (that's the big part), in the "orthodox" manner, OTPs are
invulnerable to attack. Period.
-*---*-------
S.T.L. ===> [EMAIL PROTECTED] <=== BLOCK RELEASED! 2^3021377 - 1 is PRIME!
Quotations: http://quote.cjb.net Main website: http://137.tsx.org MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 F00FC7C8
E-mail block is gone. It will return if I'm bombed again. I don't care, it's
an easy fix. Address is correct as is. The courtesy of giving correct E-mail
addresses makes up for having to delete junk which gets through anyway. Join
the Great Internet Mersenne Prime Search at http://entropia.com/ips/ Now my
.sig is shorter and contains 3379 bits of entropy up to the next line's end:
-*---*-------
Card-holding member of the Dark Legion of Cantorians, the Great SRian
Conspiracy, the Triple-Sigma Club, and the Union of Quantum Mechanics
Avid watcher of "World's Most Terrifying Causality Violations", "World's
Scariest Warp Accidents", and "When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #1: Thou Shalt Not Exceed The Speed of Light.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: TeraPi
Date: Sat, 26 Jun 1999 02:11:34 GMT
> Odds are that it'll be used in a product which
> has a massive security hole, and your algorithm
> will be discredited, and your enemies will rejoice.
I hear that! My intentions was to put the strength into the sheer size
that an attack would require rather than into a complex algorithm that
would take forever to debug (and for which I would never be certain was
bug free).
But thinking about your response, I can now see how if two cipher
streams resulted from the same key then the key could be ignored and
the two cipher streams compared to each other to calculate a common
base encryption (as though only one key were used).
So I can see how if persons A and B were to use this, A would need to
start at key Axxx and B would have to start with Byyy and no key could
be used again. So A and B would each have their own transmit key, used
by the other to decipher, and those keys would simply continue
progressing through the key space with each transmission.
I guess it might be possible that layering could produce weaknesses,
but in a situation where there are so many possibilities and possibly
many layers to cover any weaknesses, I am not sure this is a problem.
With the ability to add as much redundancy as desired, the level of
security could be raised so high that it simply would not matter how
diluted a key's security could become.
Thanks for your input.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
