Cryptography-Digest Digest #260, Volume #13 Sat, 2 Dec 00 19:13:01 EST
Contents:
Re: Self Shrinking Additive Generators? (Tom St Denis)
Re: "targeted-ciphertext" encryption? ("Jakob Jonsson")
Re: File Deleter/Nuker ? (Tom St Denis)
Re: Newbie (cracking DES in months on an Athlon) (Marc)
Re: Working area of SSL ? ("Arnold Shore")
Re: Secrets ? (Jim)
Re: Newbie (cracking DES in months on an Athlon) (Tom St Denis)
Re: Newbie ("Michael")
Re: Newbie ("Michael")
Re: Newbie ("Michael")
Re: Entropy paradox ("r.e.s.")
Re: Newbie (cracking DES in months on an Athlon) ("Michael")
Re: File Deleter/Nuker ? ("Michael")
Re: Newbie (Tom St Denis)
Re: Newbie (Tom St Denis)
Re: Newbie (Scott Craver)
Re: Newbie (Scott Craver)
Re: keysize for equivalent security for symmetric and asymmetric keys (David
Schwartz)
Re: Newbie (David Schwartz)
Re: Newbie (Steve Portly)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Self Shrinking Additive Generators?
Date: Sat, 02 Dec 2000 20:11:43 GMT
In article <90b3jb$9b6$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> We know the LFSR's that are ran in the self shrinking configuration
> are secure provided a dense polynomial is used.
>
> My question is, could a Self Shrinking Additve Generator be created
and
> would the security remain the same.
>
> Lets say for the sake of argument we had a 8-bit word length.
>
> We could define a mechnism where we clock the generator twice, to
> produce two 8-bit words A and B. If A>128 then the output is B. If not
> reclock twice more.
>
> Does this work identically to the LFSR?
I used to have a paper on this sort of thing I wrote.... anyways the
jist of it is this.
Take two 8-bit fibonacii generators call them A and B.
1. Clock A once and store result in 'N'
2. Clock B 'N' times
3. Output next clocking of B and goto 1
It's simple and relatively fast. You can simplify it down to one LFG
but i would makre sure it's long enough to be statistically random.
Another idea is to use 32-bit words and use the top 8-bits to get
the "skip amount". 32-bit words allows you to encrypt more at the same
time and increases the length of the period.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: "targeted-ciphertext" encryption?
Date: Sat, 2 Dec 2000 21:27:47 +0100
Hi,
Maybe I am misinterpreting the meaning of M and r below, but if M is
supposed to be the "message" and r the "random seed" (as in OAEP), then M is
uniquely determined by C. Namely, Decrypt(Encrypt(M, r)) = M. With OAEP,
where r is also uniquely determined by C, there is no way for A to cheat.
Or am I missing something?
Jakob
"David A Molnar" <[EMAIL PROTECTED]> skrev i meddelandet
news:909ivm$bof$[EMAIL PROTECTED]...
>
> Suppose I have a message M and a "target" ciphertext C = E_PK(M,r) for
> some randomized public key encryption and padding scheme E_PK with
> padding value r. How difficult is it to find a different M',r' such that
> E_PK(M',r') = C ?
>
> It's not clear to me right now whether this is implied by some other
> property (such as semantic security) or not. It seems that for
> deterministic cryptosystems, however, this is exactly the inverting
> problem for E_PK().
>
> The motivation is that I am thinking about a protocol which needs a
> public key scheme to do double duty as a commitment scheme. To commit,
> Alice sends C := E_PK(M,r) to Bob. To decommit, Alice sends Bob M and r
> and then Bob can run E_PK(M,r) himself and verify that it produces the
> same string which Alice sent. Neither Alice nor Bob have access to the
> decryption key D_PK. Alice can cheat if she can find an M' and r' whch
> result in the same C.
>
> In general we can investigate variants like "does an encryption scheme
> allow targeted ciphertexts with the private key but not without it?"
>
> In any case, I think that the particular case of OAEP padding makes
> targeting a ciphertext impossible because of the random oracle. Finding
> an M' and r' would require finding a relation over the H and G oracles
> in OAEP which you wouldn't expect from a random function. (I haven't
> made this formal yet).
>
> Anyone seen this before? maybe in stego?
>
> Thanks much,
> -David Molnar
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: File Deleter/Nuker ?
Date: Sat, 02 Dec 2000 20:15:19 GMT
In article <[EMAIL PROTECTED]>,
Neil Sluman <[EMAIL PROTECTED]> wrote:
> Mark Harrop <[EMAIL PROTECTED]> wrote:
> > Hi all...
>
> > Could some kind soul pls point me in the direction of a
Freeware/Shareware
> > File Nuker ? Or if there are no free types, post the name of your
favorite
> > package. please.
>
> > I am after the kind that write over the disk sector (?) many times
to stop
> > retrieval.
>
> > PS. I _AM_ a Newbie, so pls no flames on this tender soul ;-)
>
> A related question for others - How do these things work. Is it
simply a
> matter of generating random numbers and writing them to the same place
> repeatedly or is it more complicated than that? Do most filesystems
> move data around, and risk leaving traces in the old locations or
> anything awkward like that. Is a predictable random pattern a bad
> thing in this case?
Most of the time hard disks are so dense that writing over the data
once is often enough. "Multi-pass" file wipers are just plain paranoia
food. On floppy disks your best bet is to burn them since they are
cheap. But because hard disks store information so densely the
probability of left over data is next to nill.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Newbie (cracking DES in months on an Athlon)
Date: 2 Dec 2000 20:38:35 GMT
>Often brute forcing is done on a cluster of computers (a DES key would
>takes months on a Atlhon 500) to linearly increase the search rate.
My last info was that it takes hundreds of years on a single CPU,
doesn't it?
What programs perform the attack in just months?
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Re: Working area of SSL ?
Date: Sat, 2 Dec 2000 15:39:45 -0500
SSL fits between the transport and application layers (tcp/ip and http),
without disturbing either very much. Which made for a quite painless
implementation.
Arnold Shore
Annapolis, MD USA
SSL takes place between the transport layer and the
"Darren New" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Scott Fluhrer wrote:
> > I believe it's called the transport layer. In fact, SSL has been
recently
> > redubbed TLS -- Transport Layer Security
>
> That's because the internet doesn't have a presentation layer.
>
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> There is no "P" on the end of "Winnie the Pooh."
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Secrets ?
Reply-To: Jim
Date: Sat, 02 Dec 2000 20:44:03 GMT
On Sun, 03 Dec 2000 01:44:34 +1100, Mark Harrop <[EMAIL PROTECTED]> wrote:
>Hi all...
>
>On p237, APPLIED CRYPTOGRAPHY (Complexity Theory), it states
>"Unfortunately, most literature on applying information theory to
>cryptanalysis remains classified...."
>
>I thought that the UK, and the USA Classified Info becomes declassified
>after a certain time ? ie, after 30 or 50 years ?
Nooooo. In the UK at least they only declassify the documents
they want to declassify. Very, very little is ever declassified
in GCHQ.
--
______________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie (cracking DES in months on an Athlon)
Date: Sat, 02 Dec 2000 22:29:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Marc) wrote:
> >Often brute forcing is done on a cluster of computers (a DES key
would
> >takes months on a Atlhon 500) to linearly increase the search rate.
>
> My last info was that it takes hundreds of years on a single CPU,
> doesn't it?
>
> What programs perform the attack in just months?
Well assuming you could test a key in say 1000 cycles (using bitslice
DES with MMX I spose) then you could test 500,000 keys per second. To
exhaust a 56-bit key would take more then a month. Ooops...
Well a good cluster of 10,000 computers could perform the search in a
month...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 23:04:24 GMT
What do you mean by "describe the algorithm?"
"Scott Craver" <[EMAIL PROTECTED]> wrote in message
news:90a3qt$cnn$[EMAIL PROTECTED]...
> Michael <[EMAIL PROTECTED]> wrote:
> >OK, I will not post it here.
> >
> >However, I find your example a little silly. I think that would be
pushing
> >the term algorithm. I think you assumed (correctly) that it is an
algorithm
> >that can convert any ASCII into a 'secret message.'
> >
> >What, in your opinion, would be the proper protocol for challenging
people
> >to break it.
>
> All you really need to do is describe the algorithm. People
> can simply analyze that to see if the cipher has any flaws.
>
> Or, for a more traditional challenge, you can describe the
> algorithm, provide ciphertext encrypted with a secret key,
> and see if anyone can determine the plaintext and possibly
> the key. But providing the algorithm is a basic necessity
> for a cryptographic challenge.
>
> Just put it on a web page and post the URL here.
>
> >Thanks again,
> >Michael
> -S
>
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 23:05:50 GMT
I am confused. Isn't it paramount to keep the algorithm secret?
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Michael wrote:
> >
> > OK, I will not post it here.
> >
> > However, I find your example a little silly. I think that would be
pushing
> > the term algorithm. I think you assumed (correctly) that it is an
algorithm
> > that can convert any ASCII into a 'secret message.'
>
> Well we won't know what your algorithm is unless you tell us.
>
> > What, in your opinion, would be the proper protocol for challenging
people
> > to break it.
>
> Present the algorithm. If you wish confirmation, also present encrypted
> text of suitable length. However, there are many ways to compromise a
> cipher other than decrypting text. You can't find defects in the
> structure of the cipher without knowing what that cipher is.
>
> I'd recommend using a web page to explain the cipher in as much detail
> as possible and then announcing it in this newsfroup.
>
> DS
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 23:08:32 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90au05$5ic$[EMAIL PROTECTED]...
> In article <9L%V5.84224$[EMAIL PROTECTED]>,
> "Michael" <[EMAIL PROTECTED]> wrote:
> > I would think a (fast) computer would be perfect for brute forceing
> it.
> > But, I have no concept of just how fast the computers 'they' have are.
> > Mine is not up to the task!
> >
> > I once (when I had a P200) wrote a program to attempt a brut force
> decode of
> > a simple message.
> > It was going so slow I added code to estimate (based on progress) how
> long
> > it would take to finish.
> > It was MANY YEARS! I gave up.
> > Not exactly practical.
> >
> > Thanks for the reply,
>
> Your concept of "fast computers" completely baffles me. A 500mhz
> Athlon computer (I think that is what you said you have) is capable of
> about 1.5 billion instructions per second (maximum) and would average
> about 500 million (assuming well written code, etc). Compare that to a
> 286 from 15 years ago... (286's ran at about 16mhz tops).
>
> Normally brute force is NOT the way to attack an algorithm. DES for
> example can be broken in theory by an attack faster then brute force.
> It just happens for short key algorithms such as DES it is more
> practical today to brute force the key.
>
> Often brute forcing is done on a cluster of computers (a DES key would
> takes months on a Atlhon 500) to linearly increase the search rate.
> distributed.net is a good example of such.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
1.5 Billion IPS. OK. What would you estimate the BEST the NSA can do on a
priority 1 job?
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Sat, 2 Dec 2000 15:20:31 -0800
"John A. Malley" <[EMAIL PROTECTED]> wrote ...
[...]
|
| The Shannon entropy of X is the expected (average) value
| of the summation of the -log( Probability[ X = x] ) over
| the range of x.
[...]
| The Shannon entropy of Y is the expected (average) value
| of the summation of the -log( Probability[ Y = y] ) over
| the range of y.
[...]
Those are slips, of course.
The Shannon entropy of a discrete r.v. X is not the
expected value of the summation mentioned above. It
is, rather, the expected value of -log(p(X)), i.e.,
sum( p(x) * -log(p(x)) ), where p(x) = Pr[X=x].
(And similarly for Y.)
--r.e.s.
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Newbie (cracking DES in months on an Athlon)
Date: Sat, 02 Dec 2000 23:21:50 GMT
I have 1-K7-500, 1-P3-750, 1P1-200, and 1-K6 something.
It will be a while until I have 10,000 computers at my house!
(unless YOU are buying <G>)
Michael
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90bt50$rtr$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Marc) wrote:
> > >Often brute forcing is done on a cluster of computers (a DES key
> would
> > >takes months on a Atlhon 500) to linearly increase the search rate.
> >
> > My last info was that it takes hundreds of years on a single CPU,
> > doesn't it?
> >
> > What programs perform the attack in just months?
>
> Well assuming you could test a key in say 1000 cycles (using bitslice
> DES with MMX I spose) then you could test 500,000 keys per second. To
> exhaust a 56-bit key would take more then a month. Ooops...
>
> Well a good cluster of 10,000 computers could perform the search in a
> month...
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: File Deleter/Nuker ?
Date: Sat, 02 Dec 2000 23:26:44 GMT
A company in Clearwater Florida claims they can recover data on a hard drive
that has been written over FOUR times. I called bullshit when my friend
signed up for the class. When my friend came back from the class I gave him
a disk that was ACCIDENTALLY overwritten by a friend of mine (once) and he
didn't recover ANYTHING.
Michael
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90bl8k$m6t$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Neil Sluman <[EMAIL PROTECTED]> wrote:
> > Mark Harrop <[EMAIL PROTECTED]> wrote:
> > > Hi all...
> >
> > > Could some kind soul pls point me in the direction of a
> Freeware/Shareware
> > > File Nuker ? Or if there are no free types, post the name of your
> favorite
> > > package. please.
> >
> > > I am after the kind that write over the disk sector (?) many times
> to stop
> > > retrieval.
> >
> > > PS. I _AM_ a Newbie, so pls no flames on this tender soul ;-)
> >
> > A related question for others - How do these things work. Is it
> simply a
> > matter of generating random numbers and writing them to the same place
> > repeatedly or is it more complicated than that? Do most filesystems
> > move data around, and risk leaving traces in the old locations or
> > anything awkward like that. Is a predictable random pattern a bad
> > thing in this case?
>
> Most of the time hard disks are so dense that writing over the data
> once is often enough. "Multi-pass" file wipers are just plain paranoia
> food. On floppy disks your best bet is to burn them since they are
> cheap. But because hard disks store information so densely the
> probability of left over data is next to nill.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 23:24:10 GMT
In article <iffW5.84970$[EMAIL PROTECTED]>,
"Michael" <[EMAIL PROTECTED]> wrote:
> I am confused. Isn't it paramount to keep the algorithm secret?
Absolutely not.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 23:23:43 GMT
In article <YdfW5.84969$[EMAIL PROTECTED]>,
"Michael" <[EMAIL PROTECTED]> wrote:
> What do you mean by "describe the algorithm?"
Just that. Describe the algorithm you used to encrypt the data.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Newbie
Date: 2 Dec 2000 23:21:32 GMT
Michael <[EMAIL PROTECTED]> wrote:
>What do you mean by "describe the algorithm?"
Permit me to explain. The algorithm is the actual
encryption method, minus the specific key used.
Consider keyword alphabets, for instance. Take any word or
phrase without duplicate letters, and follow it with the
remaining letters of the alphabet in order:
PRECAUTIONbdfghjklmqsvwxyz
abcdefghijklmnopqrstuvwxyz
Now you have a simple substitution cipher, in which
"`Hurrah me soul' says I, shillelagh I let fly" encrypts to
"`Isllpi fa mhsd' mpym O, mioddadpti O daq udy," for instance.
The algorithm represents the whole process of turning
the keyword PRECAUTION into a cipher alphabet, and encrypting
with that alphabet. The actual word PRECAUTION is the secret
key. Note that the key can change while the algorithm
remains the same. This allows you to use a good cipher over
and over, by changing the secret parameter.
This particular example is very simple, and easy to crack.
In a challenge, you'd provide (a) the encrypted message
and (b) a description of the cipher like I did above, but
not (c) the secret key word. A cryptanalyst would have to
determine the original message without being given the key.
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Newbie
Date: 2 Dec 2000 23:27:59 GMT
Michael <[EMAIL PROTECTED]> wrote:
>I am confused. Isn't it paramount to keep the algorithm secret?
It is the secret key that must be kept secret. The
algorithm itself is not something you can change often,
and it is very, very realistic to assume that an
adversary will learn which algorithm is being used.
-S
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Sat, 02 Dec 2000 15:32:25 -0800
John Savard wrote:
> On Thu, 30 Nov 2000 15:21:28 -0800, David Schwartz
> <[EMAIL PROTECTED]> wrote, in part:
> > Moore's Law does not need to continue to hold for your argument to be
> >correct. The rate of growth of computing power just has to stay the
> >same.
> Moore's law is a statement of the rate of growth of computing power.
Yes, Moore's law is one such statement.
> Or maybe you're just saying that he is being imprecise, because
> computing power might grow in other ways than by putting more
> transistors on chips...
Precisely. Moore's law is not required. Computing power (or its
effective equivalent) could increase in any manner.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 15:33:58 -0800
Michael wrote:
> I am confused. Isn't it paramount to keep the algorithm secret?
I had damn well better not be! Otherwise, anyone who knows the
algorithm can compromise the security of anyone who uses the algorithm.
DS
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Sat, 02 Dec 2000 18:31:25 -0500
Michael wrote:
> What do you mean by "describe the algorithm?"
>
Well so far you told us that it is based on complimentary numbers. Could
be a classic one time pad system? If so I don't need to see the algorithm
I can say it could be unbreakable (one time pad systems are covered in the
FAQ).
------------------------------
** 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
******************************
