Cryptography-Digest Digest #24, Volume #14 Tue, 27 Mar 01 16:13:00 EST
Contents:
Re: Idea - (LONG) (Bertrand)
Re: Malicious Javascript in Brent Kohler post (Povl H. Pedersen)
Re: Large numbers in C (512 bits or more) ("Joseph Ashwood")
Re: DH/DSS ("Joseph Ashwood")
Re: compression ratio as a predicter of cipher strength ("Joseph Ashwood")
Re: Deny Anon Remailers access to this newsgroup (Jim D)
Re: Deny Anon Remailers access to this newsgroup (Jim D)
Re: Newbie wants to shuffle... ("Joseph Ashwood")
Crypto" by Steven Levy E-Book Posting ("Scheidsrechter")
Re: DH/DSS (DJohn37050)
Re: Idea - (LONG) (Mok-Kong Shen)
Re: Crypto" by Steven Levy E-Book Posting (Mok-Kong Shen)
Re: Newbie wants to shuffle... ("Henrick Hellström")
Re: RC4 test vectors after gigabyte output?. (Luis Yanes)
----------------------------------------------------------------------------
From: Bertrand <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Tue, 27 Mar 2001 13:30:40 -0400
Il faudrait d'abord lire ce que j'ai propose.
J'ai signe mes posts sous trois noms differents "br", "amateur" et
"bertrand".
Lis d'abord ce que j'y exprime comme idees avant de repondre
brutalement.
Merci.
Erwann ABALEA wrote:
>
> Right now, you still haven't proved that you could be trusted as a good
> cryptographer. Therefore, your criticism about my ignorance in
> cryptography is of no value...
>
> But that doesn't matter. After all, it's just talk, isn't it? Please read
> on.
>
> I was not talking about your talents as a cryptographer.
>
> I was only talking about your attitude against advices given by people
> that are known to be knowledgeable at cryptography. Your only answer is a
> proposed challenge to break your poor algorithm. You still don't seem to
> understand that even breaking something weak requires some effort, which
> at a simple human level can be too much, considered the price paid to do
> the work (a free challenge is not very interesting).
>
> If your cryptosystem should only prevent your sister from getting your
> love letters, then it's OK, your algorithm might be good enough. But
> designing a cryptosystem that could be able to resist to attacks from
> motivated attackers (that means with a lot of money, and a lot of
> motivated people) needs some real hard work, counted in months or years of
> work. But the design of such a cryptosystem can only be engaged after some
> years of cryptanalysis and working with already known cryptosystems.
>
> So try to break some known-to-be-breakable cryptosystems, publish your
> work so your reputation could be established, and then your *assumptions*
> about the strength of a cryptosystem could be considered of value.
>
> But right now, you're designing your system, you only have a vague idea of
> what it's strength is (what is the order of operations or memory needed to
> break your system with a 12 bits key (you said it's "hard"... a 12 bits
> keyspace covers only 4096 different elements, the brute force attack is
> trivial to deal with) or more?), so *YOU* have to prove your system is
> strong. And such a *proof* can only come from heavy math work...
>
> You've been given some advices to help you build such a proof (either a
> proof that it's really strong or not), and your only answer is "hey, just
> crack it!". That's a kid behaviour.
>
> If you don't understand the answers given to you, say so.
> If you think people didn't understand your system, and the advices are not
> relevant enough, then enhance your communication level, and try to post
> either:
> - a clear and precise formal description of your algorithm (in english,
> since that's the language of choice to reach the most people on the
> Internet).
> - a C source code that could be easily compiled on any Unix workstation,
> and a set of test vectors to compare the results obtained by the guys
> cool enough to try your code with the reference ones (yours). Please
> provide useful comments in your source code, that may prevent some
> future questions.
>
> I'm no cryptanalyst but I'm interested in cryptography since several
> years, I often read books and practice at home, I use cryptography in my
> everyday work (I work for a VeriSign affiliate in Europe, in the R&D lab),
> I often talk with very good cryptographers (some of them are very kind
> people, and well known).
> Therefore I can't say I'll break your cryptosystem. But I'd like to try,
> even with my really short free time. I'm a software developer at first, so
> my preferred approach would be to compile a C code, run it to get some
> results, and work on them... The result (or non-result) of my work is of
> no value for the few very talented people, but we both are still not
> playing in the same playfield as them.
>
> I repeat, be humble.
>
> Thanks for having read so far.
>
> On Tue, 27 Mar 2001, Bertrand wrote:
>
> > Who has spoken about "perfect cipher"????????????????
> > I talked about ideal substitution cipher.
> > You seems to ignore your ignorance.
> >
> > Erwann ABALEA wrote:
> > >
> > > Do you also think that someone needs to prove you that the Earth is round
> > > as an orange before you might consider that's true?
> > >
> > > Read some maths, then read the work of other cryptanalysts, and maybe
> > > you'll be able to talk about "perfect cipher" and other bullshit of your
> > > own...
> > >
> > > Be humble, your time might come. Right now, you're deserving yourself
> > > because you're not acting as a professional. You're acting as a kid.
> > >
> > > On Mon, 26 Mar 2001, Bertrand wrote:
> > >
> > > > No more than speech again.
> > > > Crack it! that's what I'm waiting for to be convinced.
>
> --
> Erwann ABALEA
> [EMAIL PROTECTED]
> - RSA PGP Key ID: 0x2D0EABD5 -
------------------------------
From: [EMAIL PROTECTED] (Povl H. Pedersen)
Crossposted-To: alt.drugs.pot,rec.radio.swap,rec.running,rec.sport.skating.ice.figure
Subject: Re: Malicious Javascript in Brent Kohler post
Date: Tue, 27 Mar 2001 18:35:55 +0000 (UTC)
Reply-To: [EMAIL PROTECTED]
On Tue, 27 Mar 2001 05:08:30 GMT,
John Savard <[EMAIL PROTECTED]> wrote:
>On Mon, 26 Mar 2001 22:41:52 -0600, "Rick"
><[EMAIL PROTECTED]> wrote, in part:
>
>>DO NOT OPEN THE POST FROM BRENT KOHLER. (yes, I know I am shouting)
>
>>If you are using a newsreader that runs javascript, it may lock up your
>>machine. This has been all over many newsgroups.
>
>DO NOT USE A NEWSREADER THAT RUNS JAVASCRIPT.
And don't run a mailreader that does it either.
HTML 2.0 / 3.2 is plenty for e-mail markup.
Support for javascript / ActiveX etc in text mesages (mail / news)
is an idea of a sick mind.
--
Povl H. Pedersen - Please send unsolicited advertising to [EMAIL PROTECTED]
Position: N 56 09 37 - E 010 12 29
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Large numbers in C (512 bits or more)
Date: Tue, 27 Mar 2001 10:41:33 -0800
You also need to link to libeay. After you've compiled the OpenSSL library
there should (assuming Windows) be a file somewhere in the directory tree
called libeay32.lib and a second called libeay32.dll. You need to link
against libeay32.lib and place libeay32.dll somewhere in your dll search
path (system32 is a great location).
Joe
"Dobs" <[EMAIL PROTECTED]> wrote in message news:99q0g7$69$[EMAIL PROTECTED]...
> Thank U all for help, however can U tell me how to attache BIGNUM library
to
> my program, how to make them work in my program. Is it enough to
> #include"bn.h" or I need more? I have never been useing additional
libraries
> and here I have so many files so I do not know which to use ??
> Thanks
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: DH/DSS
Date: Tue, 27 Mar 2001 10:43:35 -0800
Well how about right here (or you can go to the source I used, the NIST
paper describing them):
q = 160 bit prime.
p = larger prime of the form q*k+1 (512+ bits)
1 < h < p-1 such that g > 1
g = h^(k) mod p
private_key = 160 bits or greater, random number, general usage is SHA-1 of
something
public_key = g^private_key mod p
For the signing part I'll refer you to the standard.
Joe
"George" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've been doing some research on public key algorithms, and I can find a
> mass of information for key generation of every algorithm except
> Diffie-Hellman/Digital Signature Standard (DH/DSS). Where can I find
> more about key generation for this algorithm? Any help is appreciated.
> Thanks.
>
> -George
> [EMAIL PROTECTED]
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Tue, 27 Mar 2001 11:04:11 -0800
I can prove it based on a proof of OTP based on entropy. This proof goes
something like this:
Given a pad P that is wholly entropic
Given a text T that has some amount of entropy greater than 0
Given a combining function whose output entropy is at least the maximum of
the input entropies (XOR is a perfect example)
By applying the combining function to the pad P and the text T, the output
will be wholly entropic, and all entropy can be considered to be from P,
eliminated all usage of the entropy of T. This leads to a situation where
any value of T had equal probability of producing the result, so it cannot
be attacked (yes I'm skipping large amounts).
Moving to the 2 text
Given a pad P that is wholly entropic
Given a text T1 that has some amount of entropy greater than 0
Given a text T2 that has some amount of entropy greater than 0
Given a combining function whose output entropy is at least the maximum of
the input entropies (XOR is a perfect example)
By applying the combining function to the pad P and the text T1 and T2, the
output will have entropy no higher than that of the pad P, the result is
that at most half of the possible values of (T1, T2) could have reached the
resultant values. That can be attacked. You can go into more detail on it,
but at this point it is evident that reuse of the pad is flawed.
Joe
"Curtis Williams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've always taken the "twice used" rule about OTP's as a fact, without
> understaning exactly why. Can you explain in more detail?
------------------------------
From: sideband@ btinternet.com (Jim D)
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: Tue, 27 Mar 2001 19:11:49 GMT
Reply-To: Jim D
On Mon, 26 Mar 2001 18:10:32 GMT, Darren New <[EMAIL PROTECTED]> wrote:
>David A Molnar wrote:
>> There are at least two reasons why cryptography discussion groups, sci.crypt
>> in particular, might be a good place for the use of anon remailers.
>
>You forgot number three: Your ex-blood relatives might be trying to deport
>you to Finland.
Oh no! Not Finland. Dunno though. Could be worse, could
be the USA!
--
______________________________________________
George Dubya Bushisms No 17:
I have made good judgements in the past; I have
made good judgements in the future.
Posted by Jim Dunnett
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________
------------------------------
From: sideband@ btinternet.com (Jim D)
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: Tue, 27 Mar 2001 19:11:50 GMT
Reply-To: Jim D
On 26 Mar 2001 09:07:05 -0800, Paul Rubin <[EMAIL PROTECTED]> wrote:
>Frank Gerlach <[EMAIL PROTECTED]> writes:
>
>> I cannot find a good reason why anon remailers should be allowed to
>> post to sci.crypt. If someone needs pseudo-anonymity, just change your
>> name in the news client.
>> That should btw help against stalkers, although it does not help against
>> an evil government...
>
>Since a lot of the regular contributors to sci.crypt are opponents of
>evil governments.....
Are there any other kind?
--
______________________________________________
George Dubya Bushisms No 17:
I have made good judgements in the past; I have
made good judgements in the future.
Posted by Jim Dunnett
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Newbie wants to shuffle...
Date: Tue, 27 Mar 2001 11:28:35 -0800
There's a lot of ways to buld permutations, and which one you should use
depends on what you're doing. One algorithm (stolen from the ARCFOUR key
setup) is:
place the elements sequentially in an array A
place the key in the array K, repeat it until it is as large as A
for each element E in A
swap(A(E), K(E))
end for
a second is to build a key, generator pair for the the correct size, this is
only useful if there's a prime (or appropriate composite) close to the
correct value, for a 52 card deck it would look like:
Assign a number 1...52 to each card
g = 16
p = 53
for each card number N
place = g^N mod p
end for
This one has ordering flaws.
Or you can build a cipher of the correct size, it can even be sparse. For
example:
Array of card and 64-bit value A
identify each card with an initial 64-bit counter output
choose a key K
for each card C in A
A(C).64-bit value = DES_encrypt(A(C).64-bit value, K)
end for
sort based on A(...).64-bit value
extract cards from A
If you have a dense set up to the size of cipher you can manage better:
identify each possible output in a 1-1 onto fashion with an output of the
cipher, or a subset of the outputs
counter = 0 //this can be used for excessively large sets so you may want to
actually store this value on disk
Key value K //also stored long term
to generate a value
while(output not in output set)
output = Encrypt(counter, K)
end while
end generate
This one can be performed on enormous sets, for example I posted a cipher
that would work on a set of size 2^512 last week, Mercy will work on a set
up to size 2^4096.
Those are just a few of the miriad possibilities.
Joe
"Peter Engehausen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> This may be a bit off-topic but it's related to transposition
> encryption, I think.
>
> I'm looking for function or method which creates a permutation of a
> given set S.
>
> Let S be a pack 52 playing cards.
>
> This was my first idea:
> To get a permutation of S I would say S is isomorph to ( Z / 52 Z )^* .
> Since p=53 is prim and r=2 is a generating element, that means S' = {
> 2^k | 0 <= k <= 52 } is a permutation of S. Every generating element r
> (we have \phi(\phi(53)=24 of them) gives us a good permutation.
> "Good" because I only swap each card once.
>
> 24 is quite lousy compared with 52! > 8*10^67 possible permutations! So
> either there is a better way to create permutations or I shouldn't be so
> restrictive.
>
> Let's say my function f: S --> S is allowed to swap some cards more
> often.. Any idea how a shuffling device can be constructed?
>
> Thanks,
> Peter
>
>
------------------------------
From: "Scheidsrechter" <[EMAIL PROTECTED]>
Subject: Crypto" by Steven Levy E-Book Posting
Date: Tue, 27 Mar 2001 19:41:14 GMT
If anyone is interested, today a posting was made of this book on
alt.binaries.e-book and alt.binaries.e-books.
Newsgroups: alt.binaries.e-book,alt.binaries.e-books
Subject: "Crypto" by Steven Levy - 1 attachments
Date: Tue, 27 Mar 2001 04:46:52 -0000
Xref: alt.binaries.e-book:92853 alt.binaries.e-books:52177
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 27 Mar 2001 20:15:26 GMT
Subject: Re: DH/DSS
Do not use 512 bit p, use 1024 bit. Also, ensure the private key has no
bias/skew.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Tue, 27 Mar 2001 22:40:18 +0200
Bertrand wrote:
>
> Il faudrait d'abord lire ce que j'ai propose.
> J'ai signe mes posts sous trois noms differents "br", "amateur" et
> "bertrand".
> Lis d'abord ce que j'y exprime comme idees avant de repondre
> brutalement.
Internet discussion groups and mailing lists do not
always talk with the same atmosphere as e.g. in academic
circles. If you have experience elsewhere on the internet,
you would realize that this group is on the average rather
gentle. But, as is everywhere in life, other people's
behaviour may be dependent to some extent on your own. As
someone has pointed out, you keep on challenging others to
crack your scheme with the obvious intention to claim that,
if you don't get results from others, then your cipher
must be absolutely secure. In an earlier post I have
tried to explain why your logic of deciding the security
of your scheme cannot hold. Others have subsequently also
tried the same, though with different words and perhaps
in tongues a bit less soft for you. But I suppose this is
due to your persistent keeping to your questionable
attitude without providing convincing concrete arguments
and the repeated posting of virtually the same stuff. I
guess that the sheer number of posts could have displeased
some. As I have explained in several other follow-ups,
your scheme is a very special case of what I discussed in
an article posted on 10th Oct 2000. So your idea is
certainly not new. Even if your scheme should turn out to
be very very excellent, then it would have been I,
not you, that deserve the credit (of having invented
a presumably 'uncrackable' cipher). Thus I don't understand
at all why you continue to challenge others to analyse
the cipher, thus with time so to say getting onto the
nerves of others. Let me recall that a disadvantage of bit
homophones is the substantial expansion of the volume of
the ciphertext relative to plaintext. If this expansion
ratio is made fairly large, then the encryption could be
rendered sufficiently difficult to attack. However, the
cost of the users also correspondingly increases with
that ratio. In view of all the above, I suggest that you
would, as already recommended by others, invest your time
to read some good literatures in crypto instead of
continuing what you have done up till now in this thread.
If you are really interested in encryption with bit
homophones, you could later, i.e. after you have enriched
your knowledge in crypto, make an in-depth investigation
of its strength and post your well-founded results to the
group or publish them in a famous journal. I am sure that
all of us would appreciate to read your work.
Cheers,
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto" by Steven Levy E-Book Posting
Date: Tue, 27 Mar 2001 22:51:25 +0200
Scheidsrechter wrote:
>
> If anyone is interested, today a posting was made of this book on
> alt.binaries.e-book and alt.binaries.e-books.
E-books have to be loaded into corresponding hardware,
isn't it?
M. K. Shen
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Newbie wants to shuffle...
Date: Tue, 27 Mar 2001 22:59:54 +0200
If you start with a random (large) integer N in the range [0..n!), you could
use the following algorithm that will bijectively assign a distinct
permutation to each possible value of N:
for i := 1 to n do S[i] := i;
for i := n downto 2 do begin
j := (N mod i) + 1; (* Large integer arithmetics *)
N := N div i; (* Large integer arithmetics *)
x := S[i];
S[i] := S[j];
S[j] := x;
end;
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Peter Engehausen" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> This may be a bit off-topic but it's related to transposition
> encryption, I think.
>
> I'm looking for function or method which creates a permutation of a
> given set S.
>
> Let S be a pack 52 playing cards.
>
> This was my first idea:
> To get a permutation of S I would say S is isomorph to ( Z / 52 Z )^* .
> Since p=53 is prim and r=2 is a generating element, that means S' = {
> 2^k | 0 <= k <= 52 } is a permutation of S. Every generating element r
> (we have \phi(\phi(53)=24 of them) gives us a good permutation.
> "Good" because I only swap each card once.
>
> 24 is quite lousy compared with 52! > 8*10^67 possible permutations! So
> either there is a better way to create permutations or I shouldn't be so
> restrictive.
>
> Let's say my function f: S --> S is allowed to swap some cards more
> often.. Any idea how a shuffling device can be constructed?
>
> Thanks,
> Peter
>
>
------------------------------
From: Luis Yanes <[EMAIL PROTECTED]>
Subject: Re: RC4 test vectors after gigabyte output?.
Date: Tue, 27 Mar 2001 23:09:39 +0200
On Mon, 26 Mar 2001 13:05:10 -0800 "Joseph Ashwood" <[EMAIL PROTECTED]>
wrote:
>"Luis Yanes" <[EMAIL PROTECTED]> wrote in message
>news:Gmm=OprxeTRMB6aiCoo1ryPJG7bV@wingate...
>> I readed that good implementations discards 2**(8+1), although 2**8 seems
>> enought to avoid the key mix problem. Where these numbers came from?.
>
>Well there's more theories than proof on this. We know for a fact that there
>is a notable correlation in the first byte, so that needs to be thrown away.
>Because ARCFOUR (RC4) is so fast it is fairly normal to add a bit of
>paranoia, and throw away the first 256, 512, or more bytes. It's easily
>accomodated paranoia so it's become a convention.
Readed some about the k[0]+k[1] mod 256 == 0 problem and the key not being
enough mixed, and thought that will be due to this. If it is just a
"paranoid" number, is why didn't found any detailed explanation, supouse.
>> The gigabyte test would last a couple of days!.
>
>Then your implementation is massively slow, you should be able to manage
><<<<<< 50 clocks a byte, which would put 1GB at under a minute (assuming a
>1GHz machine). Even assuming a 100 MHz maching it should take less than an
>hour.
Well, the ARC4 test would run on a 68HC11 500ns/instruction microcontroller
board. The system is slow, and the software also!. For sure that could be
implemented to be much faster coding it in assembler instead of the awfully
unoptimized compiled C code that is right now. That is one of the original
reasons to ask for the after gigabyte test vectors.
In a P200 with the same C source code gives the GByte in less than 10min.
73's de Luis
mail: melus0(@)teleline(.)es
Ampr: eb7gwl.ampr.org
http://www.terra.es/personal2/melus0/ <- PCBs for Homebrewed Hardware
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
