Cryptography-Digest Digest #675, Volume #12 Wed, 13 Sep 00 23:13:01 EDT
Contents:
Re: question on the bible code (Ed Kubaitis)
Re: Ideas on elliptic curves (Scott Contini)
Re: Announcement (Tom St Denis)
Re: question on the bible code (Jim Gillogly)
Re: question on the bible code ("Mikal 606")
20 suggestions for cryptographic algorithm designers (David Hopwood)
----------------------------------------------------------------------------
From: Ed Kubaitis <[EMAIL PROTECTED]>
Subject: Re: question on the bible code
Date: Wed, 13 Sep 2000 20:27:45 -0500
TaoenChristo wrote:
>
> In article <[EMAIL PROTECTED]>,
> JCA <[EMAIL PROTECTED]> wrote:
> > This stuff has already been thoroughly debunked like the
> > scam it is.
>
> Has it really? I have seen vain attempts at dedicated mathmeticians
> and staticians to "debunk" the reality of the Code, but sorry, even the
> lates "debunking" will show to be nothing then a vain attempt to
> discredit what has allready "passed the test".
Recommend you contact Mike Siegal (Coast to Coast AM ) soonest.
Suspect he would be sympathetic to your argument.
/ejk
>
> > Mikal 606 wrote:
> >
> > > I understand many peoples deep desire to believe in this code.
> > > But I ask you, what else does it add?Are you not already a believer?
> > > Do you understand what I mean?
> > >
> > > "TaoenChristo" <[EMAIL PROTECTED]> wrote in message
> > > news:8pm1ig$a2f$[EMAIL PROTECTED]...
> > > > In article <8pbko1$n2m$[EMAIL PROTECTED]>,
> > > > "Mikal 606" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > "John Kennedy" <[EMAIL PROTECTED]> wrote in message
> > > > > news:9lcu5.20946$[EMAIL PROTECTED]...
> > > > > >
> > > > > > Then explain it.
> > > > > > >Whats your interest in the matter?
> > > > > > I think it's just interesting to see the names pop up....
> > > > >
> > > > > heres a good handling of ELS-
> > > > > /
> > > > > http://www.nctimes.net/~mark/fcodes/elsyesh.htm
> > > > >
> > > > >
> > > >
> > > > To explain why the ELS in the Bible is unique, you must
> understand, it
> > > > is not just the occurance of words at certain skip lengths, as the
> > > > author of this web page assumes. Even if the word Yeshua occured
> with
> > > > cross (or whatever) in differant text, that shows nothing, but a
> neat
> > > > coincidence... now find me ANY text that has the following words:
> > > >
> > > > Herod, Annas and Judas, ALL 12 diciples,"the Marys weep
> bitterly," "let
> > > > him be crucified," "true Messiah" and "son of Mary"
> > > >
> > > > These in turn are intersected by hundreds of other similar ELSs.
> > > >
> > >
> > > It *has to be reconstructed* from the Hebrew alphabet and you can
> rebuild
> > > all kinds of words when the original alphabet is missing vowels!
> > >
> > > > All of these words and phrases are found intersecting Isaiah 52-
> 53. The
> > > > odds of all of the above phrases and words being found in ELS
> code, in
> > > > only 2 chapters of one book of 66, would be somewhere around 1 in
> > > > 3,408,749,015,176,240,000,000,000,000,000,000,000,000,000,000.
> > > >
> > >
> > > Really now!
> > >
> > > > though you might be able to find Yeshua intersecting Christ or
> some
> > > > other such combinations in other books, I find it to very
> unlikely that
> > > > you will EVER find the combinations above in any other book
> anywhere!
> > > >
> > > > --
> > > > Romans 1 20 For the invisible things of him from the creation of
> the
> > > > world are clearly seen, being understood by the things that are
> made,
> > > > even his eternal power and Godhead; so that they are without
> excuse:
> > > >
> > > >
> > >
> > > Jeremiah 14:14
> > > Then the LORD said unto me, The prophets prophesy lies in my name:
> I sent
> > > them not, neither have I commanded them, neither spake unto them:
> they
> > > prophesy unto you a false vision and divination, and a thing of
> nought, and
> > > the deceit of their heart.
> > >
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Before you buy.
> >
> >
>
> --
> Romans 1 20 For the invisible things of him from the creation of the
> world are clearly seen, being understood by the things that are made,
> even his eternal power and Godhead; so that they are without excuse:
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Ideas on elliptic curves
Date: 14 Sep 2000 01:34:36 GMT
In article <8pp25n$tdf$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <8poo90$lh3$[EMAIL PROTECTED]>,
> "�lisabeth Konstantinou" <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'm beggining my master thesis on elliptic curves
>> and I search for a more specific topic on that (example DSA, discrete
>log
>> etc).
>> Does anyone have any good ideas for something interesting
>> (some recent developments) in this field in order to elaborate?
>
>
>Try looking at curves over medium fields, i.e. GF(p^q) where p
>is moderately large and q is near log p. This differs from current
>practice of using GF(2^n) for large n or GF(p^1) where p is very
>large
I think this is related to Bob's suggestion...
You might take a look at the paper
"Rational groups of elliptic curves suitable for cryptography"
by David Kohel, which is available at:
http://www.maths.usyd.edu.au:8000/u/kohel/
You may try to consider how efficiently arithmetic can be done
on the curves he suggests. You will need to familiarize yourself
with efficient scalar multiplies on Koblitz curves (see Solinas'
paper in Crypto '97. Also worth seeing: a paper by V Mueller in
J. of Cryptology Vol 11, No 4 and a paper in the poster collection
on PKCS 200 by Yukio Tsuruoka and Kenji Koyama).
Scott
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Announcement
Date: Thu, 14 Sep 2000 01:27:29 GMT
In article <8pp6g9$d9$[EMAIL PROTECTED]>,
"rosi" <[EMAIL PROTECTED]> wrote:
> ROSi has decided to venture past concept into implementation.
>
> --- (My Signature)
What the heck does that mean? BTW don't post 10x ok?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: alt.bible.prophecy
Subject: Re: question on the bible code
Date: Thu, 14 Sep 2000 01:45:08 +0000
TaoenChristo wrote:
>
> In article <[EMAIL PROTECTED]>,
> JCA <[EMAIL PROTECTED]> wrote:
> > This stuff has already been thoroughly debunked like the
> > scam it is.
>
> Has it really? I have seen vain attempts at dedicated mathmeticians
> and staticians to "debunk" the reality of the Code, but sorry, even the
> lates "debunking" will show to be nothing then a vain attempt to
> discredit what has allready "passed the test".
An excerpt from http://cs.anu.edu.au/~bdm/dilugim/moby.html :
- The following challenge was made by Michael Drosnin:
-
- When my critics find a message about the assassination of a prime minister
- encrypted in Moby Dick, I'll believe them.
- (Newsweek, Jun 9, 1997)
If you're as open-minded as Drosnin claimed to be, visit the site and
see the proof, and reflect on Mark 4:9. (No, I'm not a Christian, but
people like me can quote scripture for their own purposed. :)
--
Jim Gillogly
Highday, 23 Halimath S.R. 2000, 01:41
12.19.7.9.17, 6 Caban 20 Mol, Eighth Lord of Night
------------------------------
From: "Mikal 606" <[EMAIL PROTECTED]>
Crossposted-To: alt.bible.prophecy
Subject: Re: question on the bible code
Date: Wed, 13 Sep 2000 22:01:16 -0700
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> TaoenChristo wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > JCA <[EMAIL PROTECTED]> wrote:
> > > This stuff has already been thoroughly debunked like the
> > > scam it is.
> >
> > Has it really? I have seen vain attempts at dedicated mathmeticians
> > and staticians to "debunk" the reality of the Code, but sorry, even the
> > lates "debunking" will show to be nothing then a vain attempt to
> > discredit what has allready "passed the test".
>
> An excerpt from http://cs.anu.edu.au/~bdm/dilugim/moby.html :
>
> - The following challenge was made by Michael Drosnin:
> -
> - When my critics find a message about the assassination of a prime
minister
> - encrypted in Moby Dick, I'll believe them.
> - (Newsweek, Jun 9, 1997)
>
> If you're as open-minded as Drosnin claimed to be, visit the site and
> see the proof, and reflect on Mark 4:9. (No, I'm not a Christian, but
> people like me can quote scripture for their own purposed. :)
>
> --
> Jim Gillogly
> Highday, 23 Halimath S.R. 2000, 01:41
> 12.19.7.9.17, 6 Caban 20 Mol, Eighth Lord of Night
I *am* a Christian and cannot defend this book and this code-it isn't true.
So sorry, Taoen.
_L_
------------------------------
Date: Thu, 14 Sep 2000 02:13:22 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: 20 suggestions for cryptographic algorithm designers
=====BEGIN PGP SIGNED MESSAGE=====
Here are some general suggestions to designers of cryptographic algorithms,
on how to promote interoperability and make life easier for implementors:
1. If an algorithm is a research contribution rather than intended for
serious use, or if a paper includes variants of an algorithm that
are defined for exposition only, say so clearly. The remainder of
these suggestions apply mainly to algorithms intended for serious use.
2. If a paper defines more than one algorithm, give each of them a distinct
name, and explain why an implementor might want to use one as opposed
to another.
3. For parameterised algorithms, specify precisely the set of allowable
values for each parameter, and give recommended values. Don't include
values that would be insecure in the allowable range.
4. Use consistent capitalisation and punctuation for algorithm names, and
define an unambiguous way to specify any parameters as part of the
name. Consider submitting the algorithm to SCAN (Standard Cryptographic
Algorithm Naming), and following the "name(parameter,...)" format used
there; see <http://www.users.zetnet.co.uk/hopwood/crypto/scan/>.
5. As far as possible, there should be sufficient information in the
paper defining the algorithm, that independent implementations that
are consistent with the paper will automatically interoperate.
(For network protocols and other algorithms involving two or more
parties, that might be unrealistic.)
6. Specify any binary inputs, outputs, keys, etc. as sequences of octets
(i.e. integers between 0 and 255 inclusive). Allowing arbitrary bit
sequences rather than octet sequences is more hassle than it is worth,
and very rarely used. Define octet-sequence representations for any
abstract mathematical objects that would need to be stored,
transmitted, etc. As far as possible, try to follow existing standards
(e.g. IEEE P1363) when doing this, but *don't* use ASN.1.
7. For public key algorithms, specify the distribution of key pairs that
should be used, and algorithms for validating keys. For protocols,
include explicit checks that received values are in the sets assumed
by the mathematical description.
8. Number sequences and indexed variables starting with zero. If there is
a completely arbitrary choice of byte order, use big-endian. Don't use
inconsistent byte order in different parts of an algorithm (although
this needn't prevent using auxiliary functions like hashes, etc. that
internally use a different byte order to the algorithm being defined).
9. Write octet sequences as two hex characters per octet (most followed by
least significant nybble), and left-to-right as they would be stored in
memory or transmitted. This may sound obvious, but the documentation and
test vectors for at least three of the 1st round AES submissions (FROG,
SAFER+ and Serpent) used the opposite (right-to-left) convention.
10. Provide a C reference implementation that is byte-order independent,
uses only aligned memory accesses, does not depend on the sizes of
built-in C types or the signedness of 'char', does not assume that
signed types are twos-complement, and does not use compiler-specific
directives, or any other non-portable tricks. Test it with several
compilers on different platforms.
Ideally use <inttypes.h> for integer types, and provide a minimal
version of this (which can just be a few lines in most cases) for
compilers that don't have it. "Byte-order independent" means using code
that accesses individual bytes/octets, *not* BIG_ENDIAN and LITTLE_ENDIAN
conditional compilation and pointer casts. Use macros only where it
clarifies rather than obfuscates the code.
11. Provide an optimised C/assembler implementation. This may use
compiler-specific embedded assembler, conditional compilation of code
that works better on some machines, etc., but it should still act as a
plain C version when assembler for the target machine is not available.
12. In both reference and optimised C implementations, treat inputs, outputs,
keys etc. as arrays of an unsigned 8-bit type (e.g. uint8_t from
inttypes.h), to correspond with the mathematical definition in terms of
octets. Put test code that checks an implementation against test vectors
in a separate source file, that can be compiled with either the reference
or the optimised implementation.
13. Optionally provide a Java reference implementation that interoperates
with the C ones. For this treat inputs, outputs, keys etc. as byte arrays
(with the obvious two's-complement mapping between the Java 'byte' type
and octet values). Look at other optimised Java crypto code to see how
to fake unsigned types efficiently, and various other tricks. Put test
code in a separate class from the algorithm.
14. Put up a WWW page from which all of the papers, code, test vectors, etc.
relating to the algorithm are available. Post an announcement about this
page to at least sci.crypt. Keep the page up to date, and reference any
published cryptanalysis of the algorithm from it, including that by other
researchers. If the page is mirrored then use some method that ensures
that mirrors will be kept up to date.
15. Make available, at least as a text file and as C test code, test
vectors for *all variants* of the algorithm, and for a selection of
parameter choices (if it is a block cipher then this should cover all
block sizes, and a selection of numbers of rounds or key sizes, for
example). Include both values that are byte-order-invariant (e.g.
0x12343412 for 32-bit words), and values that are not, for each input
to the algorithm.
16. For the most common parameter combinations, also include a fully
worked out example with intermediate values at each stage of the
computation (including dumps of such things as scheduled keys).
Make sure that the test vectors are sufficient to test all parts of
the algorithm (e.g. encryption and decryption, or signing and verifying).
In the case of non-deterministic algorithms, e.g. a public key
algorithm with a randomised padding method, give test vectors that
use fixed values for the random input. For yes/no tests give both
values that should pass, and values that should fail for various
different reasons, if applicable.
17. Don't revise papers, implementations, test vectors, etc. without stating
that they have been revised, and when. Make sure that all on-line versions
are up-to-date, using Archie and Metacrawler to search for any copies
you might not otherwise know about. Also give a brief summary of what
has changed.
18. If an algorithm is modified incompatibly, give the modified version a
new name. Don't change the name for simple mistakes such as typographical
errors that are found soon after publication (but see 17). If the spec
and the reference implementation are found to be inconsistent, consider
carefully which one needs to be changed, or whether it is better to
define a new version, considering both disruption and security
consequences.
19. Make papers available on-line in at least PDF and Postscript formats,
and preferably also as the original source (e.g. LaTeX or whatever).
Use an HTML page that has an abstract of the paper and links to the
various formats, and recommend that links from other sites be made to
this page rather than directly to the .pdf/.ps files.
Some journals have restrictions on when a paper submitted to them
can be made publically available; in that case put it on-line as soon
as possible within those restrictions. Put a reference to the algorithm's
web page in the journal version.
20. If the algorithm is ever broken (perhaps not completely, but enough
that you no longer recommend its use), say so on the web page, and
post an announcement of that to sci.crypt.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOcAkSTkCAxeYt5gVAQHBxQf+M/gDLpIh+mvsQRwe7zvWKFOVZCdOIxBy
mjXlr0Z9rtkEH6rALWpPzlTGSkKd5OtfC37MIV1AAJHXpFlxtY9JatF0sYi+wVie
qDw1BxK22qzowjBblX6pRA4m+A2e4+/UVEPke+Jh91M5tWm9JyVN7f4MXgRZ45hR
A4AA90IGSiFOJNmHe5YdNQKrjeyiH4Y/SwOauTBO55LO0yuJ/FN7PHCtwART82xk
u+KDw3NQ998tw2xxf7VRRD34pxZLcJmuxnr2wLdEcOjYhMQGkDuV9wVv9U1MrAtW
U8ouT2W7XbZmfq+3KL+tqoRxOuGIDMUTeH2frZ1NQb3EXhhsn6DZpg==
=Q2/N
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
