Cryptography-Digest Digest #369, Volume #11 Mon, 20 Mar 00 09:13:01 EST
Contents:
Re: generating secure id numbers (Johnny Bravo)
Montreya nux real ("Marquesa Reyes")
Re: new Echelon article (David A. Wagner)
Montreya nux real ("Penn Wright")
encryption and decryption with elliptic curve cryptography (kingtim)
Re: new Echelon article (Mok-Kong Shen)
Re: Card shuffling (Mok-Kong Shen)
Download Random Number Generator from Ciphile Software (Anthony Stephen Szopa)
Re: Crypto books ("Christoph Moser")
Re: encryption and decryption with elliptic curve cryptography ("Tom St Denis")
Re: Download Random Number Generator from Ciphile Software ("Tom St Denis")
Re: Opinions? (ca314159)
Re: Opinions? ([EMAIL PROTECTED])
Re: DES Decryption Problem (Chuah Seong Ping)
Re: EOF in cipher??? ("Trevor L. Jackson, III")
PC-1, anyone ? (Christoph Weber-Fahr)
----------------------------------------------------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: generating secure id numbers
Date: Mon, 20 Mar 2000 01:19:29 -0500
On Sun, 19 Mar 2000 22:51:38 GMT, [EMAIL PROTECTED] wrote:
>I want to generate a secure id based system
>containing unique identifiers for people yet
>generated in such a way that they would be
>particularly difficult to guess.
Depends on what you want them for. If you are thinking of protecting a
software product with issued registration numbers, save your time, it
won't protect the product more than a couple of days anyway so there is no
sense in killing yourself debugging a complex method.
>Can I use a random number generator with a key
>and hash these to give encrypted id's ???
Would be easy, don't even need random number generator, just hash the
user id and use as much of it as you need to keep them separate.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Marquesa Reyes" <[EMAIL PROTECTED]>
Subject: Montreya nux real
Date: 20 Mar 2000 07:47:55 GMT
Nulla ipsit query don marqi ney canne real
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: new Echelon article
Date: 19 Mar 2000 23:12:10 -0800
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Do you actually know what NSA suggested during the cellular
> telephone proposal comment period? I know that people from
> my own organization testified about the utter lack of security,
> and the *FCC* (not NSA) didn't want to hear about it.
No, but I'd love to have my impressions proven wrong.
Do you have a reference you can point me to?
And, help me out here: how did the FCC enter into the equation?
I was thinking of the NSA's involvement in the CTIA AHAG,
and its effect on the security of the standard. Are you
suggesting the NSA representatives actively worked to improve
the security of the standards?
------------------------------
From: "Penn Wright" <[EMAIL PROTECTED]>
Subject: Montreya nux real
Date: 20 Mar 2000 07:52:10 GMT
Nulla ipsit query don marqi ney canne real
Tantra deva mar non kiplat
------------------------------
From: kingtim <[EMAIL PROTECTED]>
Subject: encryption and decryption with elliptic curve cryptography
Date: Mon, 20 Mar 2000 15:51:15 -0800
Please tell me simply how to do encryption and decryption with elliptic
curve cryptography.
and any web site about this topic.
thanks
kingtim
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: Mon, 20 Mar 2000 10:38:22 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > ... German companies may expend money in
> > bribery in foreign (as against national) contracts and have tax
> > deductions too. From what you wrote above, I deduce that this is
> > forbidden by law in the US.
>
> Indeed, we have a general principle that assisting someone else
> in the commission of a crime is a crime in itself.
I have some difficulty in interpreting your sentence in the current
context. But, anyway, let me stress that whatever are the laws,
principles, moral or ethical standards, religious doctrines or
prescriptions from school teachers or parents, all these become
meaningless if the practice essentially deviates from them. One
easily obtains a false feeling, an illusion of reality. And illusions
are presumably what part of the politicians like the common people
to entertain in order to help them to continue to be in power. I am
certainly not saying that we should do away with laws, etc. Only
a fool would have such thoughts. But we should pay great attention
to deviations from what is beautifully written in the documents or
sweetly proclaimed in the public and try, if possible, to eliminate
or limit such deviations from the ideal. This is so simple and
shouldn't worth any mentioning. However, in the practical world, it
sometimes happens that even stating tautologies could help.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Mon, 20 Mar 2000 10:38:13 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > Why I was asking the wrong question? For the players of a particular
> > session, isn't it a vital question whether the (particular) deck
> > that they play has been well shuffled?
>
> What is important is the process, not the result. Truly random
> shuffling *must* on occasion produce a highly ordered deck.
> If you test a single shuffled deck, there really is no way to
> tell if it was ordered by a truly random process or not, no
> matter how highly ordered or disordered the deck is.
Certainly, for a scientist studying games, it is the process not
the individual results that is important and interesting. For the
players, however, the converse it true, I suppose. Guaranteeing that
the process is random is fine. But I conjecture that one should apply
additional filtering to check that there are not patterns (or
the like since I have never played card games and am hence ignorant)
that could render the session undesirable in one sense or the
other. Just a tiny thought.
M. K. Shen
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Download Random Number Generator from Ciphile Software
Date: Mon, 20 Mar 2000 01:31:15 -0800
Download Random Number Generator from Ciphile Software
http://www.ciphile.com
see Downloads Currently Available web page
OARL3_41.zip (588KB)
The intended purpose of the OAR-L3: Original Absolutely Random - Level3
Random Number Generation Software Package is to generate or provide
random digits or numbers for statistical modeling and computer
simulations.
The OAR-L3 random number generation software is exactly the same
software as OAP-L3: Original Absolute Privacy - Level3 encryption
software except there is absolutely NO encryption or decryption
capability.
Not only have the encryption and decryption GUI forms, menus, buttons,
etc. been deleted, but also, the encryption and decryption source code
has been deleted, then the entire package recompiled. So there is no
way to enable any encryption or decryption methods or capabilities using
OAR-L3.
The Help files included with OAR-L3 are the exact same help files
included with OAP-L3 encryption software. Any references to encryption
or decryption in these help files are for informational purposes only.
These options are only available with OAP-L3.
Again, OAR-L3 random number generation software is only intended to
generate random digits or numbers for statistical modeling and computer
simulations.
------------------------------
From: "Christoph Moser" <[EMAIL PROTECTED]>
Subject: Re: Crypto books
Date: Mon, 20 Mar 2000 11:38:52 +0100
version_x wrote ...
>i'm trying to get started in cryptography and have am looking for books
>which would suit a beginner,
The Handbook of Applied Cryptography by Alfred J. Menezes, Paul C. van
Oorschot
and Scott A. Vanstone is available for download - for personal purposes at:
http://cacr.math.uwaterloo.ca/hac/index.html
It's somehow like Schneier's Applied Cryptography, but some chapters are
easy
to understand, even for beginners... it's free, so have a look at it.
Chrsitoph
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: encryption and decryption with elliptic curve cryptography
Date: Mon, 20 Mar 2000 11:53:56 GMT
kingtim <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Please tell me simply how to do encryption and decryption with elliptic
> curve cryptography.
> and any web site about this topic.
>
It's not a simple topic at all. Try reading some books, confusing yourself,
and hope for the best.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 20 Mar 2000 11:54:21 GMT
What is the period of the generator?
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Download Random Number Generator from Ciphile Software
>
> http://www.ciphile.com
>
> see Downloads Currently Available web page
>
> OARL3_41.zip (588KB)
>
> The intended purpose of the OAR-L3: Original Absolutely Random - Level3
> Random Number Generation Software Package is to generate or provide
> random digits or numbers for statistical modeling and computer
> simulations.
>
> The OAR-L3 random number generation software is exactly the same
> software as OAP-L3: Original Absolute Privacy - Level3 encryption
> software except there is absolutely NO encryption or decryption
> capability.
>
> Not only have the encryption and decryption GUI forms, menus, buttons,
> etc. been deleted, but also, the encryption and decryption source code
> has been deleted, then the entire package recompiled. So there is no
> way to enable any encryption or decryption methods or capabilities using
> OAR-L3.
>
> The Help files included with OAR-L3 are the exact same help files
> included with OAP-L3 encryption software. Any references to encryption
> or decryption in these help files are for informational purposes only.
> These options are only available with OAP-L3.
>
> Again, OAR-L3 random number generation software is only intended to
> generate random digits or numbers for statistical modeling and computer
> simulations.
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Subject: Re: Opinions?
Date: Mon, 20 Mar 2000 11:54:28 GMT
Marc Howe wrote:
>
> There is nothing that is truly random, correct?
>
> Marc
There is nothing that is truly X, correct?
X="an apple"...
Sounds like the "word problem" in formal language theory:
http://ink.yahoo.com/bin/query?p=%22word+problem%22&hc=0&hs=1
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Opinions?
Date: Mon, 20 Mar 2000 11:55:22 GMT
In article <_pWA4.1819$[EMAIL PROTECTED]>,
"Marc Howe" <[EMAIL PROTECTED]> wrote:
> There is nothing that is truly random, correct?
>
> Marc
>
>
Concerning randomness, not non-predictability, it might interest you that
most modern parapschologists believe to have found an effect or
correlation between consciousness and statistically significant
"fluctuations" of quantum-based random number generators. Test persons
are given the goal to "influence the display (connected to a random
source) by their will or mind" and they indeed produce a small, very
slight variation of the random source, that can be determined by
statistical evaluation and seems to be sort of time-independant. However,
most serious scientists believe that there is no macroscopic equivalent
of this effect and that the effect is of no practical relevance. For
cryptography it almost certainly is of no practical relevance since it is
rather concerned about unpredictability than about randomness.
For more information on ongoing parapschological research, you should be
aware of most of the esoteric-crap on the Net, most serious and
scientifically correct research is published in magazines and books and
is not available online.
For more information on the Web, you might take a look at
http://www.parapsych.org/ (with brief FAQ section)
http://www.igpp.de/english_welcome.htm (not much to read online)
http://www.csicop.org/ (for the contrary view)
Best regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 20 Mar 2000 20:44:45 +0800
From: Chuah Seong Ping <[EMAIL PROTECTED]>
Subject: Re: DES Decryption Problem
Sir ,You mean I have to use this algorithm with i starts from i=16 until
i=1;
and the R[i-1] in "L[i-1] = R[i] xor f(R[i-1],K[16-i+1])" had been used in
encipherment process
in R[i] = L[i-1] Xor f(R[i-1],K[i]) with the i = 1 to i=16;
Decipherment:
R[16]L[16] = IP(cipher block)
for 16 >= i => 1
R[i-1] = L[i]
L[i-1] = R[i] xor f(L[i],K[i])
plain block = FP(L[0]R[0])
Should i need to rearrange the selection bits in Initial
Permutation,Expansion permutation,S-box,P-box
and Inverse Permutation that i used for encryption process?
I have tried you suggestion but still cannot decrypt back to original
messages
James Muir wrote:
> In article <[EMAIL PROTECTED]>,
> "Chuah Seong Ping" <[EMAIL PROTECTED]> wrote:
> > Dear Sir,
> > I have some problem to ask you sir.
> > Can you help me to check for me the algorithm for DES Decryption as
> below
> > (picked from an article written by Matthew Fischer)
> > Decipherment:
> > R[16]L[16] = IP(cipher block)
> > for 1<= i <= 16
> > R[i-1] = L[i]
> > ****L[i-1] = R[i] xor f(L[i],K[i])*****
> > plain block = FP(L[0]R[0])
>
>
------------------------------
Date: Mon, 20 Mar 2000 08:52:43 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" wrote:
> There are a lot of things involved with any program that
> involve implementation-definedness, but so long as the program
> operates the same way no matter what choice the implementation
> made, that particular requirement for strict conformance is met.
One of the areas of Software Engineering that has received intense scruti=
ny is support for numerical operations. The following URL describes in d=
etail why numerical software is not portable among systems that are in st=
rict conformance with IEEE 754, which is a stricter standard than any C s=
tandard published to date.:
http://www.validgh.com/goldberg/addendum.html
An excerpt from the introduction describes the issues:
""""""""""""""""""""""""""""""""""""""'
The preceding paper has shown that floating-point arithmetic must be impl=
emented carefully, since programmers may depend on its properties for the=
correctness and accuracy of their programs. In particular, the IEEE stan=
dard requires a careful implementation, and it is possible to write usefu=
l programs that work correctly and deliver accurate results only on syste=
ms that conform to the standard. The reader might be tempted to conclude =
that such programs should be portable to all IEEE systems. Indeed, portab=
le software would be easier to write if the remark on page 195, "When a p=
rogram is moved between two machines and both support IEEE arithmetic, th=
en if any intermediate result differs, it must be because of software bug=
s, not from differences in arithmetic," were true.
Unfortunately, the IEEE standard does not guarantee that the same program=
will deliver identical results on all conforming systems. Most programs =
will actually produce different results on different systems for a variet=
y of reasons. For one, most programs involve the conversion of numbers be=
tween decimal and binary formats, and the IEEE standard doesn't completel=
y specify the accuracy with which such conversions must be performed. For=
another, many programs use elementary functions supplied by a system lib=
rary, and the standard doesn't specify these functions at all. Of course,=
most programmers know that these features lie beyond the scope of the IE=
EE standard.
Many programmers may not realize that even a program that uses only the n=
umeric formats and operations prescribed by the IEEE standard can compute=
different results on different systems. In fact, the authors of the stan=
dard intended to allow different implementations to obtain different resu=
lts. Their intent is evident in the definition of the term destination in=
the IEEE 754 standard: "A destination may be either explicitly designate=
d by the user or implicitly supplied by the system (for example, intermed=
iate results in subexpressions or arguments for procedures). Some languag=
es place the results of intermediate calculations in destinations beyond =
the user's control. Nonetheless, this standard defines the result of an o=
peration in terms of that destination's format and the operands' values."=
(IEEE 754-1985, p. 7) In other words, the IEEE standard requires that ea=
ch result be rounded correctly to the precision of the destination into w=
hich it will be placed, but the standard does not require that the precis=
ion of that destination be determined by a user's program. Thus, differen=
t systems may deliver their results to destinations with different precis=
ions, causing the same program to produce different results (sometimes dr=
amatically so), even though those systems all conform to the standard.
Several of the examples in the preceding paper depend on some knowledge o=
f the way floating-point arithmetic is rounded. In order to rely on examp=
les such as these, a programmer must be able to predict how a program wil=
l be interpreted, and in particular, on an IEEE system, what the precisio=
n of the destination of each arithmetic operation may be. Alas, the looph=
ole in the IEEE standard's definition of destination undermines the progr=
ammer's ability to know how a program will be interpreted. Consequently, =
several of the examples given above, when implemented as apparently porta=
ble programs in a high-level language, may not work correctly on IEEE sys=
tems that normally deliver results to destinations with a different preci=
sion than the programmer expects. Other examples may work, but proving th=
at they work may lie beyond the average programmer's ability.
In this section, we classify existing implementations of IEEE 754 arithme=
tic based on the precisions of the destination formats they normally use.=
We then review some examples from the paper to show that delivering resu=
lts in a wider precision than a program expects can cause it to compute w=
rong results even though it is provably correct when the expected precisi=
on is used. We also revisit one of the proofs in the paper to illustrate =
the intellectual effort required to cope with unexpected precision even w=
hen it doesn't invalidate our programs. These examples show that despite =
all that the IEEE standard prescribes, the differences it allows among di=
fferent implementations can prevent us from writing portable, efficient n=
umerical software whose behavior we can accurately predict. To develop su=
ch software, then, we must first create programming languages and environ=
ments that limit the variability the IEEE standard permits and allow prog=
rammers to express the floating-point semantics upon which their programs=
depend.
""""""""""""""""""""""""""""""""""""""
------------------------------
From: [EMAIL PROTECTED] (Christoph Weber-Fahr)
Subject: PC-1, anyone ?
Date: 20 Mar 2000 13:52:56 GMT
Hi,
in a project I stumbled upon a piece of software using
Alexander Pukall's PC1 (Pukall Cipher 1).
I'm trying to form an opinion on this. Abusing deja to some degree I found
a number of hints vaguely linking it to RC4, but nothing precise.
So....
- has anybody ever eard of it ? Should it be considered serious ?
- is it actually a RC4 implementation ?
- is there any kind of analysis somebody could point me to ?
I'd be grateful for any hint .
Regards, and thanks in advance,
Christoph Weber-Fahr
--
Christoph Weber-Fahr | E-Mail: [EMAIL PROTECTED]
========================== My personal opinion only =====================
------------------------------
** 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
******************************
