Cryptography-Digest Digest #670
Cryptography-Digest Digest #670, Volume #13 Sat, 10 Feb 01 15:13:01 EST
Contents:
Mono cipher, genetic algorithm .. appropriate "Crossover?" (Sundial Services)
The Kingdom of God (Markku J. Saarelainen)
Re: The Kingdom of God ("drumstik")
Re: Mono cipher, genetic algorithm .. appropriate "Crossover?" ("Robert Reynard")
I encourage people to boycott and ban all Russian goods and services, if the Russian
Federation is banning Jehovah's Witnesses ... (Markku J. Saarelainen)
Purenoise defeats Man In The Middle attack? (Rich W.)
Re: The Kingdom of God needs Comsec and HA Public Key Management (Crypto Key
Management Associates)
Re: I encourage people to boycott and ban all Russian goods and (David Schwartz)
Re: Purenoise defeats Man In The Middle attack? (Sundial Services)
Re: Mono cipher, genetic algorithm .. appropriate "Crossover?" ("John A. Malley")
RSA is not secure in many instances... ([EMAIL PROTECTED])
Re: Some basic questions (Paul Crowley)
Re: CipherText patent still pending (Mok-Kong Shen)
Re: Purenoise defeats Man In The Middle attack? (Bill Unruh)
Re: DSA PRG Flaw (David A Molnar)
Re: I encourage people to boycott and ban all Russian goods and services, if the
Russian Federation is banning Jehovah's Witnesses ... ("drumstik")
Date: Sat, 10 Feb 2001 08:51:22 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Mono cipher, genetic algorithm .. appropriate "Crossover?"
My brother and I occasionally exchange short monoalphabetic ciphers for
entertainment. Recently I decided to try to create a computer program
based on genetic algorithms that could break them. The program itself
was fairly simple to write but it (and a few other examples out there
like GA-SOLVE) does not converge upon an acceptable result.
{Ciphertexts are short, about 100 chars long.}
I believe that the issue is in the "Crossover" step, which doesn't
produce offspring that are "better than, but different from," the
parents. Let me explain.
The genetic algorithm, as I have built it, generates 100 random "genes"
and then begins to iterate through generations as follows.
(1) The fitness of each possibility is measured against a table of
monograph and digraph probabilities in English, as the absolute "error"
of the observed frequencies against the standard. The gene-pool is then
sorted for convenience.
(2) The top Random(n) genes are then mated (Crossover) at random to
produce -- currently -- one offspring which replaces a randomly chosen
inferior (i.e. non-Top(n)) gene.
(3) The current selection of the genes to be paired is currently random;
it does not currently use a weighted probability. If it's a Top(n) gene
then each one has equal probability of being selected, even more than
once.
The crossover algorithm is the stickler because, once you assign a
letter to the result {once you say "P(x) = y") then no other letter in
the future may be assigned to "y." This is a fancy way of saying that a
given letter may occur once and only once in a monoalphabetic key, and
once a letter is "taken" it may not be used again.
The mating (crossover) algorithm is thus presented with two 26-character
strings, each of which contains every letter once and only once, and it
must produce a result string that also contains every letter once and
only once, which is supposed to be "superior to" the parents if possible
so that the algorithm's results will gradually improve by natural
selection. Furthermore, the output should not be simply "the same as"
either one of the parents -- except by random choice.
Any of the selections for (x,y) that are made when building the
offspring key could be mutually exclusive with any other future
selection - any of which could turn out to be superior.
The algorithm obviously needs to be one that "tends to produce better
offspring" without simply "determining what the answer ought to be." If
it did that, obviously, it would become the "only true intelligence" of
the program, and the genetic algorithm part would become spurious,
adding no more "real" problem solving ability to the task. In order to
be effective, a genetic algorithm =must= have a meaningful (and
appropriate to the task) crossover function.
I know that this particular problem is toughened somewhat by the short
length of the ciphertext. However, human beings solve these problems
all the time.
Suggestions anyone?
==
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks
Cryptography-Digest Digest #670
Cryptography-Digest Digest #670, Volume #12 Wed, 13 Sep 00 09:13:00 EDT Contents: Re: MIRACL (Soeren Gammelmark) From: Soeren Gammelmark <[EMAIL PROTECTED]> Subject: Re: MIRACL Date: Wed, 13 Sep 2000 14:29:41 +0200 This is a multi-part message in MIME format. ==D8D3AC60E94608980F1314D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit First I tried to run BC32DOIT.BAT directly from the /lib directory but the compiler couldn't find the source code (MRCORE.C etc...), so I copied the batch-file to the /source directory. When I run the batchfile there the compiler compiles the majority of the files, however, when it compiles mrmuldv.c (I've chosen the standard one, because I belive it fits my compiler and computer) Here is some of the error/warningmessages I get: Warning MRCORE.C 335: Condition is always false in function brand Warning MRCORE.C 337: Unreachable code in function brand Error: Unable to execute command 'tasm32.exe' Warning mrmuldv.c 19: Function should return a value in function muldiv Warning: '*.OBJ' file not found, where * is multiple files (e.g. mrmonty.obj) Error: Unresolved external '*' referenced from module file.CPP, where * is quite a bit of functions, and file.CPP is BRENT.CPP, BIG.CPP,MRIO2.C,MRPRIME.C, MRXGCD.X, MRPOWER.C and so on... It is clear to me that the final bundle of errormessages (unresolved external...) is the result of the previous warnings and errors. SG "Douglas A. Gwyn" wrote: > Soeren Gammelmark wrote: > > When I try to run the BC32DOIT.BAT to create the > > library I get tons of error messages. > > The content of the error messages, especially the first few, > should provide a clue as to what is wrong. ==D8D3AC60E94608980F1314D5 Content-Type: text/plain; charset=us-ascii; name="out1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="out1.txt" Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRCORE.C: Warning MRCORE.C 335: Condition is always false in function brand Warning MRCORE.C 337: Unreachable code in function brand Warning MRCORE.C 361: Condition is always false in function brand Warning MRCORE.C 363: Unreachable code in function brand Warning MRCORE.C 830: 'mr_mip' is assigned a value that is never used in function mirexit Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRARTH0.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRARTH1.C: Error: Unable to execute command 'tasm32.exe' Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRARTH2.C: Error: Unable to execute command 'tasm32.exe' Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRALLOC.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRSMALL.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRIO1.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRIO2.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRGCD.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRJACK.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRXGCD.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRARTH3.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRRAND.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRPRIME.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRCRT.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRSCRT.C: Warning MRSCRT.C 79: Restarting compile using assembly in function scrt Error: Unable to execute command 'tasm32.exe' Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRMONTY.C: Error: Unable to execute command 'tasm32.exe' Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRPOWER.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRCURVE.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRFAST.C: Warning MRFAST.C 179: Restarting compile using assembly in function mr_dif_fft Error: Unable to execute command 'tasm32.exe' Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRSHS.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRAES.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRSTRONG.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRLUCAS.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International MRBRICK.C: Borland C++ 5.2 for Win32 Copyright (c) 1993, 19
Cryptography-Digest Digest #670
Cryptography-Digest Digest #670, Volume #11 Sun, 30 Apr 00 11:13:01 EDT
Contents:
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Tom St Denis)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
Re: - Bestcrypt and ATA-66 enabled m/b - Anyone get these working without
conflicts/BSOD? ("ronnie bonnie")
Re: How would a 15 year old start? (Andy Dingley)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails onthe net"
(Dave J)
Re: Mathmatical concepts (John Bailey)
Re: base #- digit # ([EMAIL PROTECTED])
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (David Blackman)
40 Cryptography books reviewed (David Youd)
Re: new Echelon article ("Trevor L. Jackson, III")
Re: How would a 15 year old start? (David A Molnar)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) ("Trevor L.
Jackson, III")
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sun, 30 Apr 2000 13:13:26 GMT
Anthony Stephen Szopa wrote:
> You say writing encryption software is easy. You've done it? Just
> do this and just do that?
>
> Who wants just "adequate" or "okay" encryption software? We've got
> plenty of that already.
>
> The gold medal goes to creating unbreakable encryption... And
> creating it first.
>
> I claim to have created unbreakable encryption software. And I
> can provide anyone with the software to see for themselves. The
> Help Files describe OAP-L3, and the Theory and Processes Help Files
> prove my claim.
You have yet to prove it's totally secure, just saying "it's
unbreakable" isn't enough.
Tom
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sun, 30 Apr 2000 13:14:58 GMT
Mark Wooding wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > I am talking about using MD2 to hash the password+salt so you don't
> > actually see the output ever.
>
> Ahh. I'd still use a good hash function, though. And I'd also consider
> adding a MAC, just to protect against modifications.
>
> -- [mdw]
Well if I am sending a zip file I encrypted then I need not add a MAC.
The goal was to make a super small file encryption program (in C). In
my program (I can show the source if you want, but it's not exactly ANSI
C) I used a variation of MD2 (cuz I didn't have a ref for it at the
time) and RC2-CBC.
Tom
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sun, 30 Apr 2000 13:15:55 GMT
Anthony Stephen Szopa wrote:
>
> Tim Tyler wrote:
> >
> > In sci.crypt James Felling <[EMAIL PROTECTED]> wrote:
> >
> > : [...] No algorithim is bias free that is a fact of life.
> > : (Please review your information theory) -- all algorithims produce
> > : output with SOME bias -- the goal is to minimise this bias. The fact
> > : that you claim "no bias" seems to me to indicate that you have a
> > : flawed understanding og the way that things work.
> >
> > "Bias" is a technical term with a definition that implies that it can
> > be rather easy to generate streams with *absolutely* no bias.
> >
> > Perhaps you should say what you mean by this term if your definition
> > differs - if, say, you're using it as something like a synonym for
> > "deviations from randomness".
> > --
> > __ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> > |im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
>
> Even true random processes have significant bias over relatively
> short runs. The longer the run the less the bias. The bias may
> never disappear but it will most certainly shift. The problem is
> identifying this bias.
>
> OAP-L3 produces the same sort of output as a true random process
> once the key reaches sufficient length, this length being, in part,
> the point where brute force attack becomes infeasible.
That's awesome... no wait, any cryptographic prng shares this same
property... Oh well.
Tom
--
From: "ronnie bonnie" <[EMAIL PROTECTED]>
Subject: Re: - Bestcrypt and ATA-66 enabled m/b - Anyone get these working without
conflicts/BSOD?
Date: Sun, 30 Apr 2000 11:55:56 +0200
Take a look at pgpdisk. It is in the
Cryptography-Digest Digest #670
Cryptography-Digest Digest #670, Volume #10 Fri, 3 Dec 99 00:13:01 EST
Contents:
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tom McCune)
Re: Encrypting short blocks ("Dan Schwartz")
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: Quantum Computers and PGP et al. (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES (Johnny Bravo)
Re: The $10,000.00 contesta (Johnny Bravo)
Re: Any negative comments about Peekboo >> how to confirm designer
([EMAIL PROTECTED])
Re: Any negative comments about Peekboo >> How to verify that promised
([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
repeated DH over MOD P (jerome)
Re: NP-hard Problems (Bill Unruh)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Fri, 03 Dec 1999 01:09:42 GMT
In article <8274av$hn0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
>I trust it's security enough to send a message across irc, but I wouldn't
>choose to use it to say, encrypt my credit card to another person.
This thread has gained enough of my interest to download it, and I'm
generating a key right now - actually it didn't take very long and I have
already made another one so I can use the program with myself. I am a little
puzzled with the above level of trust - since I often hand my credit card over
to all kinds of strangers (for purchases), I personally consider credit card
info encryption to require very little confidence.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
--
From: "Dan Schwartz" <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 2 Dec 1999 20:36:03 -0500
Markus Peuhkuri wrote in message ...
> What I want is following property: given message M1 (length N
> bits) produces same encrypted message E1 (length N bits) every
> time run. Message M2 produces message E2, which is different
> from E1 iff message M2 is different from M1. However, I'm
> willing to accept some probability of collisions, less than
> 1/1000 (different messages M1 and M2 produce same result E1).
It sounds like you don't need to decrypt the messages, i.e. derive M1 from
E1. If that's the case, just pad each message to a standard block length
(e.g. 64 bits), use any encryption algorithm, and take N bits of the result.
Any good encryption algorithm should produce results that "look" random,
making the likelihood of a collision between any two messages roughly 1 in
2^N.
If you want a very simple algorithm, and don't require super strong
security, check out TEA.
Dan Schwartz
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 20:43:21 GMT
On Thu, 02 Dec 1999 11:36:08 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>There are so many cases of everybody being wrong when someone else is
>right. You honestly cannot reject a single detractor on sight. I assure
>you that I want to see evidence of his claims if possible, or define them
>at least worth more study.
If they have a claim and offer evidence to support this claim, then
we can define the claim as worth more study.
Making a claim and offering no proof other than the assertion "I'm
right, and you are wrong." is not worth further study. This is
because even if you prove that one claim wrong, they will just throw
out more claims. It is easier to make claims that to support or
disprove them, why should the community be tasked with debunking every
crackpot theory that anyone could ever come up with. If you want
people to consider your claims, you need evidence that your claim is
valid.
>The last thing I am going to do is reject
>claims if there is reason to believe that they might be true.
Really? I claim you are a murderer. Given that the other people on
this group don't personally know either of us (and have no idea if I
know you personally or not), there is a reason to believe that it
might be true. So now you should prove to the group that you are NOT
a murderer.
>Being open
>to such things may seem a burden, but it is a requirement nonetheless.
There is no requirement that we should accept spurious claims
without evidence. Logic suggests otherwise.
>Personaly, I have a few rather unpopular ideas myself, backed up by my
>experience; if they prove accurate according
Cryptography-Digest Digest #670
Cryptography-Digest Digest #670, Volume #9Sun, 6 Jun 99 12:13:03 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (Lincoln Yeoh)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: Scottu: I actually saw something usefull (SCOTT19U.ZIP_GUY)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Oriental Language Based Enryption ("Markku J. Saarelainen")
Crypto Systems for International Business (MJS)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Scottu: I actually saw something usefull (Horst Ossifrage)
Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 12:42:18 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 04 Jun 1999 20:24:05 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
> I have worked on many aircraft simulations and OFP;s one of the main
>problems that seems to occur over and over is that other people keep
>missing the obvious errors in the code becasue most people inheirently
>put faith on the comments and this leads to major maistakes that take
>years to find and fix. But I was considered an expert in fixing such code.
>LIke I said it is usually easier once one has input and outputs to just
>shorten internal names and fix the code. I have even been tasked with adding
>routines for certain projects that I have written and some managers where
>Yes I am bragging so what.
Scott,
You find short names easy.
Others find long names easy.
You find reading your own code easy, but have you tried reading OTHER
people's code? Was it as easy?
If you want to keep the code to yourself you don't have to bother about
others.
If you want more people to use or appreciate your code, make it easier for
them.
Cheerio,
Link.
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
***
--
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 12:44:23 GMT
On Sun, 06 Jun 1999 06:13:57 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> If you look at my code you will realize that decryption if anything
>would be slower than encryption since I am sort of going against
>the normal data flow
What do you mean by ".. against the normal data flow .." ?
In scott19u.zip, you load the whole of the
plain text into memory before working on it.
Working start to finish is no different from
working finish to start. Or am I missing something ?
I thought that the data was treated as one large static block held
in memory.
Please produce a document that describes your *algorithm* clearly and
concisely to remove any of these confusions that I, and others,
have about it.
- Tim.
--
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Sun, 06 Jun 1999 13:26:09 +
Boris Kazak wrote:
>
>Actually, it would be much safer (and simpler) to use one single
> multiplier, or, for paranoids, change the multiplier once every round.
> In this case different bytes will always yield a different product.
>The old adage KISS (Keep It Simple, Stupid!) is still true...
>
>The 256-enrty table will be excessive, the code will run faster.
>
>Any suggestions on the multipliers?
Well, since 2^32+1 is not prime, choosing a multiplier that is not coprime
to the modulus will again allow one to find collisions.
On the other hand, choosing a multiplier coprime to 2^32+1 results in another
weakness. This is because it makes the block-multiplication function invertible.
(Assuming my understanding of it is correct - please correct me if I'm wrong).
To see this, consider the final mod 2^32+1 multiplication applied in the final
(3rd) round of block processing. Since we know its output and one of its inputs
(the constant multipler) we can compute the other input and so undo the effect
of this multiplication. We can carry on doing this to undo the entire 3-round
block processing operation.
Denoting your hash scheme as H[i+1] = B(M[i] XOR H[i]) where the M[i] are
the message blocks and H[0] = IV a fixed quantity and B() is the block processing
operation. With the final M[i] being a padding/message-length encoding block
and the final hash value being the XOR of left and right halves of the last H[i].
Now, since B() is invertible, we can compute preimages of a given hash output
as follows:-
Given a hash value, create a H[n] value consistant with it. Now invert B() giving
H[n-1] XOR M[n-1]. Set H[n-1] co
