Cryptography-Digest Digest #942, Volume #11 Mon, 5 Jun 00 01:13:00 EDT
Contents:
Re: RSA Algorithm (tomstd)
Re: Observer 4/6/2000: "Your privacy ends here" (me)
Re: P=NP and a polynomial to find all primes. (Dido Sevilla)
Re: Call for evaluating and testing a stream cipher program (tomstd)
Re: Need "attack time" measurements on a toy cipher... (long) ("TheGPFguy")
Re: No-Key Encryption (David Hopwood)
Re: XTR independent benchmarks (David Hopwood)
Re: The lighter side of cryptology ("TheGPFguy")
Re: Evidence Eliminator, is it patented, copyrighted, trademarked ? ("Hiram Yaeger")
Re: Concerning UK publishes "impossible" decryption law ("Hiram Yaeger")
Re: Could RC4 used to generate S-Boxes? ("Scott Fluhrer")
Re: Could RC4 used to generate S-Boxes? (David A. Wagner)
Re: Newcomer seeks clarification re download encryption (Andru Luvisi)
An interesting page on the Rabin-Miller PP test (Andrew John Walker)
Re: XTR independent benchmarks (David A. Wagner)
Re: Cipher design a fading field? (wtshaw)
----------------------------------------------------------------------------
Subject: Re: RSA Algorithm
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 04 Jun 2000 19:17:47 -0700
In article <OGpvl4oz$GA.326@cpmsnbbsa09>, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
>That would of course result in a cipher that would be less
>than perfect because it would very clearly reveal the
>difference between your encrypted stream and random data,
>thus what you have proposed is a method of weakening triple
>DES. It is well known that one can through untelligent moves
>weaken security.
Nope afraid you are wrong again. It depends if you are trying
to hide the ciphertext. If not my idea is just inefficient not
insecure. Of course if you want to hide the ciphertext
symmetric encryption is not the way to go about it.
Just by inserting zero bits doesn't change the actual ciphertext
comming out of 3des (note I am not changing the input either).
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: me <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Sun, 04 Jun 2000 19:32:43 -0700
Reply-To: alt.conspiracy.spy
Isn't it Wonderful? Don't you feel more secured now? Remember, that
all of those laws are here to *protect you*. Don't you know?:)
Don't think!! Let the Government do it for you.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: P=NP and a polynomial to find all primes.
Date: Mon, 05 Jun 2000 10:43:26 +0800
Simon Johnson wrote:
>
> I was wondering wether i am correct i asumming that finding a
> polynomial such that f(n)= n'th prime would prove that P=NP.
>
> I reason this must be the case because the only way to deterimine
> wether a number is prime, with 100% acuracy, is to factor it. Since
> factoring is a NP problem and the polynomial is P. It would prove that
> NP equals P. (If this is wrong, please explain why)
>
> Now, hasn't it already been proven that such a polynomial can't exist,
> if so where can i find the proof?
As far as I know it has been proven that there exists no polynomial f(n)
= nth prime number. And also, to the best of my knowledge, factoring is
not NP-complete, so finding a polynomial algorithm for factoring
integers would not necessarily prove that P=NP. All the NP-complete
problems have the property that any one polynomial-time algorithm for
one can be adapted to any other by a suitable transformation (which may
not be trivial). For example, the knapsack problem can easily be
converted into the traveling salesman problem by considering the weights
in the knapsack to be distances between cities for the traveling
salesman. It is not clear whether such a transformation between integer
factorization and some true NP-complete problem such as satisfiability,
knapsack, or traveling salesman can be formulated; I think it has even
been proven that such does not exist (correct me if I am wrong). In
fact, you can think of all algorithms to perform factoring as being O(N)
algorithms, where N is the size of the number you want to factor!
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
Mobile Robotics Laboratory +63 (917) 4458925
University of the Philippines Diliman
------------------------------
Subject: Re: Call for evaluating and testing a stream cipher program
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 04 Jun 2000 19:57:24 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>We are offering $200 reward to the person who can break our
new, fast
>stream cipher. The details are available on this website:
>
>http://CascadeResearch.ebz.com/
>
>You can obtain an executable, source code, and description.
You have to be joking right? Your scheme is such a stupid idea
that it even hurts to read.
You feed three LFG's and a BBS gen into some mixing functions,
etc... Do you even know what a BBS gen is? It's a very slow
somewhat secure prng. Why would you post-process it?
How could you put the words 'fast' and BBS together anyways?
What asham.
Tom
>
>Cascade Research
>
>
>
>
>
>
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "TheGPFguy" <[EMAIL PROTECTED]>
Subject: Re: Need "attack time" measurements on a toy cipher... (long)
Date: Mon, 05 Jun 2000 03:14:07 GMT
Paul Pires <[EMAIL PROTECTED]> wrote in article =
<fyg_4.57815$[EMAIL PROTECTED]>...
>=20
>> I would have thought you would start by using C[0] and C[1].
>> Or by comparing multiple ciphertexts since I was stupid enough to use =
the
>> same key on all of them.
>=20
> This is what I was getting at "I would have thought you would have..." =
You
> start setting up defenses according to your idea of what the adversary =
would
> do and you are already toast.
>=20
Actually, when I phrased it this way, I was wearing my "newbie =
cryptanalyst" hat. The example is deliberately weak and (it should be =
obvious) included deliberate stupidities such as reuse of the key. But =
your comment is still entirely valid and is instructive. I fully =
expected this example to get toasted.
> I pointed out that there probably was Known plaintext, it was just =
something
> you were not worried about cause it was old. I think you confirmed =
that I
> scored a clean hit there.=20
Clean "hit" indeed confirmed. Unless there *is* no prior plaintext.
Remember that one of the arguments I'm trying to formulate is "doing 'x' =
[in this case, a weak Vigenere-type cipher] will keep someone out *at =
most* for time 't' in the most hopeful case." It's then easy to show =
that it gets even worse from there (lack of protection gets even =
weaker).
> In conjunction with using the same key (which it
> turns out is not the case), that means that:
>=20
> you got a 6 character pre-pad, thats P[0] thru [5]
>=20
You don't know the pre-pad unless you attack the PRNG, because a new one =
is generated each time you generate a ciphertext. But as you said =
below, Joseph Smith's post shows how easy the attack against auto-key =
would be.
> Then the length of the plaintext P[6]. (I know this value cause I =
caught you
> napping and snatched it up from where you didn't think to look. The
> assumption is that I also have the related ctext).
>=20
> P[6] - C[5] =3D T[6]. If it's negative, add 256.
>=20
> C[6] - T[6] =3D K[6]. if it's neg, add 256.
>=20
> K[6] yeilds the plaintext size of any other plaintext from it's =
ciphertext
> right?
>=20
> If I have the whole plaintext and not just it's length I think I have =
your
> whole key from K[6] to the last character before the pad.
>=20
> Did I miss something? If I did, go to Joseph smiths post as he seems =
to know
> the real answer.
I think you're right about having the whole key from K{6...] in the =
known-plaintext case, but it's late and I will need to look at it when =
I'm fresh. For the "no-previous plaintext available" case, Joseph =
Smith's post indeed shows me how to do it. I haven't had time to write =
an attack like his, but I plan to. This is an extremely instructive =
exercise for me (as I said previously, I have absolutely NO knowledge or =
experience in Cryptanalysis). I have no particular attachment to the =
toy algorithm under consideration, since I didn't develop it and it is a =
reinvention of something very old anyway.
>=20
> I wasn't trying to show you a break I was trying to point out that the
> mindset of building a fortress and standing in the portal with your =
sword in
> hand is a habit you should break. Don't worry about cryptanalysis =
until you
> have ruled out dumpster diving.
Oh, the real case is much worse. I can show them at least three ways =
someone can obtain these parameters in about 20 minutes, with nothing =
involving cryptologics.
>=20
> Finding out the conventional flaw with your system doesn't tell you =
squat
> about the worst case risk. If you got a time approximation from =
someone here
> and it was something you could live with, would you have used it?
>=20
Used the system? Or used the approximation?
I would use the approximation if the explanation provided rational =
grounds for evaluation.
I *might* use the system if I can't get those other holes closed up, =
just because I don't want them relying on the $1000 deadbolt on their =
hollow-plywood-frame bathroom door. Then I'd sigh and voluntarily stop =
being a weenie (employed) for just a tiny while. Remember, my job title =
is not Cryptologist, (nor even "security expert"), and we already know =
what to call employers who want security but won't spring for real =
experts and choose to rely on the best their engineers can do.
The larger and more important result of all this is that I think you =
guys have got me hooked on crypto. I've *got* to learn more about =
cryptanalysis in particular and this sure provides a start.
------------------------------
Date: Mon, 05 Jun 2000 03:49:45 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No-Key Encryption
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> David Hopwood wrote:
>
> > What identity? '*' was not stated to form a group [1], so A/A is not
> > necessarily the same for all A. Even if it were, (A/A)*A is not
> > necessarily equal to A (note that this is *not* implied by (A*A)/A = A),
> > and certainly (A/A)*B is not necessarily equal to B, which your argument
> > implicitly relies on.
>
> Sorry for a dumb question: '/' is the inverse of '*', isn't it? What does
> 'inverse' mean? Could you give a tiny easily comprehensible example?
If *, / and \ are binary operators on S, and ^-1 is a unary operator on S
(written on the right, i.e. as a^-1), then
"/ is a right-inverse to *" means "for all a, b in S: (a * b) / b = a"
"\ is a left-inverse to *" means "for all a, b in S: a \ (a * b) = b"
"^-1 is an inverse to *" means
"there exists I in S such that for all a in S:
(a * a^-1 = a^-1 * a = I and I * a = a * I = a)"
(The \ notation isn't particularly standard; I just made up an arbitrary
symbol for left-inverse.)
If * is associative in S and has an inverse ^-1 according to the above
definition, then (S, *) is a group; if the group is written multiplicatively,
then I is normally written as '1' (often in bold to distinguish it from the
integer 1, if it needs to be distinguished).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTsVITkCAxeYt5gVAQHiKgf9EDF+BmePiz7xM52qMjMeyWUrnIxCo0QJ
4Mw2ZZRukadqJAy8Y1/9uy7gyFTR1QfxXL3mBftPb6TyXW1X72zTqmKBPJw07rGC
32AIBUphio4vty0ooZd51KKPqaqFrV/AG2TS71MwoAbyHeLRPorGjKUUA+to10/o
QJh03bx+4JCxnoF7YWL/MS9s+WvGpi2YLIofaDLLd3Y1hfxUdHTQFbqZSTo0pxNF
FbHXXkI7qNBeZPm8DYtgL2HCjuw5BeoKWy7yNHksdDXUoivcou9mlVwgtbeUiPcO
sA5YKa1WvzaalQ2JDTt4YGsg0jyff0Wgd9ny85JYi/whgaGurRdTjQ==
=pVu9
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 05 Jun 2000 04:19:53 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: XTR independent benchmarks
=====BEGIN PGP SIGNED MESSAGE=====
Eric Verheul wrote:
> > > [...]
> > > The hard part of parameter generation in XTR consists of
> > > generation of two prime numbers of about 170 bits.
> > > No way, that LUCDIF parameter is faster! It should
> > > (theoretically) be about 3^4=81 times slower!
> >
> > Yes, LUCDIF parameter generation is almost certainly slower
> > (although I didn't test it), but how often do you generate new
> > paramemters?
>
> *Almost* certainly?? Do you have shares in LUCDIF, or something?
>
> Generating a strong prime (as you do) of about 512 bits is a lot
> slower than generating 2 of 170 bits!
> According to your posting you seem to believe that generation of
> a strong prime number of 512 bit (as with your LUCDIF) costs
> 5.21 msec, while the generation of two prime numbers of 170 bits
> (as with XTRDIF) costs 8.35 msec! It seems that you believe
> more in the output of your software, than in Math.
The benchmarks that Wei Dai posted did not include parameter
generation (and said what they did include, quite clearly).
> The point is that you said: "XTR is actually slower than LUCDIF",
> and I'm disproving that. Period. Moreover, when generating
> parameters for a public key for digital signatures, this
> typically needs to be done on a trusted device, like a
> smartcard.
No. For DL-based schemes, only key generation (i.e. one exponentiation)
needs to take place on a per-user basis, not parameter generation.
Trying to generate the parameters on a smart card is just silly, IMHO.
> If this takes too long, users will pull out the smartcard of the reader:
> generation time is crucial.
Key generation, yes. Parameter generation, no.
> Where your LUCDIF parameter generation on a
> smartcard (!) takes the time of generation of a 1024 RSA key,
> i.e. up to 10 minutes, XTR's parameter generation takes seconds.
... which explains why RSA is a poor choice for such applications,
but *any* of the DL-based schemes (e.g. DH over GF(p), ECC, LUC*,
or XTR) would be perfectly reasonable with respect to key generation
time.
> And yes, if you precompute the LUCDIF parameters the actual
> public key generation will take seconds, but then a lot of users
> will share the same parameters (like with ECC): this is not advisable.
Why is it not advisable? Just like any other DL-based cryptosystem,
parameters for LUC* should be chosen conservatively large enough to
make the precomputation stage of index calculus discrete log algorithms
infeasible. In that case it doesn't matter that users share parameters.
(Note: I'm not particularly recommending LUC. I would recommend either
ECC over GF(p), or plain GF(p) instead.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTsU5jkCAxeYt5gVAQFRDAgAkVjtltljg54rkoqMobAXH6mScZlg4z7h
ybzgy41GHZVnasEB84aAxkH+rXVN0c6p+fgU7sn4OW3dWFv4syx/x12o7RPLD469
zX8LcUGnKIvoLK4fR76A8RL0KSM9dgbBFjte2RpahYOXIm/AZ8A5KnLzi/4HNZnH
KXPtpoDy47fnN5lg59sXO0UH8D2JvaSUX15vomhcXGSp1qy9KJIlboyW2LJXseEN
ztiBY2te6SKbZpLNJP+aE+JRq1PQVV0H7fB6tJYtOiNflLYum7fjbcjr9C7H1hkn
5aMsayl0359gftO2EG/QURGHqzfHHFI3NvLGx7y3s8+t5tUrVqwX4w==
=k29g
=====END PGP SIGNATURE=====
------------------------------
From: "TheGPFguy" <[EMAIL PROTECTED]>
Subject: Re: The lighter side of cryptology
Date: Mon, 05 Jun 2000 03:33:58 GMT
Has anyone seen....
"Superpolylogarithmic Subexponential Functions!
Faster than a polylog but slower than exponential:
Even though they're hard to say, they're truly quintessential.
Superpolylogarithmic Subexponential Functions!
(Um diddle diddle diddle, um diddle aye! Um diddle diddle diddle, um =
diddle aye!)
"For Alice to send a message through to Bob when Eve's evesdropping,
Do use a one-way trapdoor function, not a one-key mapping.
First take a message 'x', let's say, and raise it to the 'e'.
Then mod it out by 'p' times 'q' but keep these secretly! Oh..."
[Chorus]
* * *
Sung to the tune of "Supercalifragilisticexpialidocious".
The whole thing is longer than this. I didn't write it but I wish I =
had. :-)
[Did you know that if you invert one, you get a
Functionential Subexporithmic Superpolylogarebus?
But that's going a bit too far, don't you think? :-) ]
------------------------------
From: "Hiram Yaeger" <no@email>
Subject: Re: Evidence Eliminator, is it patented, copyrighted, trademarked ?
Date: Sun, 4 Jun 2000 16:12:37 -0700
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
"jungle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> where trademarked ? what country ?
> it is not trademark in USA ...
>
> Hiram Yaeger wrote:
> >
> > "jungle" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > the other 2 ?
> > >
> > > Lucifer wrote:
> > > >
> > > > On Sat, 03 Jun 2000 06:13:12 -0400 jungle <[EMAIL PROTECTED]>
wrote:
> > > >
> > > > >Evidence Eliminator, is it patented, copyrighted, trademarked ?
> > > >
> > > > It's copyrighted when it's written.
> > > >
> > > > No filing is required.
> >
> > I would assume that "Evidence Eliminator" is legally their trademark.
As
> > for patented, they use methods for overwriting data that are well known
and
> > have been in use for years. They didn't invent it. No patent.
I'm not a lawyer. I was taking a guess, which is why I said I assume. I
don't know how trademarks work.
------------------------------
From: "Hiram Yaeger" <no@email>
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Sun, 4 Jun 2000 20:57:38 -0700
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
"Dave Howe" <DHowe@hawkswing> wrote in message
news:[EMAIL PROTECTED]...
> In our last episode (<alt.security.pgp>[Sun, 04 Jun 2000 17:35:52
> -0400]), jungle <[EMAIL PROTECTED]> said :
> >no ...
> >Jim wrote:
> >> >128 bit PGP has been cracked according to announcements
> >> >posted here some time ago.
> >> I don't think anyone saw any proof of this, did they?
> >no ...
> But a 128 bit key is pretty lousy by today's standards. I would be
> horrified to think that anyone would consider 128 bit RSA trustworthy.
I'm horrified to think that someone believes that hogwash.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Could RC4 used to generate S-Boxes?
Date: Sun, 4 Jun 2000 21:16:52 -0700
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <8hej6v$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Guy Macon) wrote:
> >tomstd wrote:
> >>
> >>
> >>In article <8hdt3k$apl$[EMAIL PROTECTED]>, Simon Johnson
> >><[EMAIL PROTECTED]> wrote:
> >>>I've read somewhere that RC4 is secure against both diff & lin
> >>>cryptanalyis. I figure this secuirty must be derived from its
> s-
> >>box. My
> >>>real question is, is the secrecy of the s-box that makes it
> >>secure or
> >>>does the algorithm generate diff & lin optimized s-boxes?
> >>
> >>Chances are you have a bit of reading todo on sbox
> construction.
> >>
> >>The reason RC4 is secure is that it's hard to model the
> internal
> >>state based on output only. Some 'weak keys' have been
> >>identified which leak more information about the state.
> >>
> >>The sboxes RC4 makes are by no means secure on their own (i.e
> in
> >>a feistel cipher), and don't always have optimial cryptographic
> >>properties (SAC, BIC, non-linear, bijective, low xor-pairs).
> >>
> >>Tom
> >
> >Sorry for being a bother, but I am a clueless newbie who has a
> >special interest in RC4 (the ciphersaber implementation, really)
> >and the above went over my head. Could someone explain the
> above
> >in simple terms?
Maybe you want to pick up a copy of Applied Cryptography by Schneier (second
edition) and look at it -- RC4 might be the simplest believed-secure cipher
in existence.
>
> Sure no prob. RC4 is a STREAM CIPHER, not a sbox generator.
> The only reason RC4 is secure is that it's hard to model the
> internal state (i.e the table) from only the output.
>
> RC4 does not always make secure sboxes for block ciphers or
> other components. In a block cipher generally you use the same
> sbox over and over (without any change) so it has to have some
> ideal cryptographic properties. Such as being non-linear (avoid
> the output and keybits being expressed by one boolean expression
> with a higher probability), or low input-output xor pairs to
> avoid differential cryptanalysis (all pairs are equally low
> probable), or satisfy SAC which states "If bit j of the input
> changes bit i of the output will change with prob 1/2", or BIC
> which states "bit j and i (j != i) of the output are not
> linearly dependant". RC4 is not designed to make 8x8 boxes that
> fulfill these requirements.
Well, if you are doing a fixed sbox, yes, a random stream is not the way to
go -- you really need to spend the time to make sure that no bad
characteristics occur. If you are using a key dependant sbox, well, you
don't need to do such an exhaustive check (the attacker has no idea where to
look), which is a good thing, because at rekey time, you really can't do an
exhaustive check anyways.
So, if you need a key dependant sbox which is a random function (as opposed
to a random permutation), ARC4 [1] is not an insane way to go.
However, looking at the OP's question, it appears that he wasn't asking
about using the RC4 output to generate SBoxes, it was more RC4's SBoxes,
perhaps because the IP was thinking about hijacking RC4's internal SBoxes
for use in another cipher. And, since RC4 really doesn't use SBoxes, this
really isn't possible.
> Asides from that RC4 is not a super prng anyways, it's better
> then nothing but that's about it.
Actually, it's considerably better than nothing. The only known way to
reconstruct the inner state in less than lifetime-of-the-universe is to use
Mister and Tavares' cycle analysis, which takes a truly huge amount of
keystream. It is known that the RC4 keystream can be distinguished from
random with a gigabyte or so of output, but that is hardly a fatal weakness.
There are a lot of prng's that you can't say that about...
[1] Or RC4 if you don't mind RSA Labs going after you :-)
--
poncho
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Could RC4 used to generate S-Boxes?
Date: 4 Jun 2000 21:36:32 -0700
In article <8hdt3k$apl$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> I've read somewhere that RC4 is secure against both diff & lin
> cryptanalyis. I figure this secuirty must be derived from its s-box. My
> real question is, is the secrecy of the s-box that makes it secure or
> does the algorithm generate diff & lin optimized s-boxes?
Nope, RC4 doesn't have a S-box, at least not in the traditional
sense of the word (i.e., a S-box is a lookup in a fixed table).
Instead, it has a constantly-changing 256-element permutation
that is used to derive output.
There is no special optimization for security against differential
or linear cryptanalysis (apparently none is needed).
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Newcomer seeks clarification re download encryption
Date: 04 Jun 2000 21:33:44 -0700
"Andy Carroll" <[EMAIL PROTECTED]> writes:
> Hi
>
> Here is my problem. I want to sell my book over the internet. I want the
> customer to be able to download the book and then the customer dials up and
> receives a key from my server based on various identifiers e.g. name,
> perhaps CPU ID or Hard Drive ID. This would mean that the customers
> environment would be the only environment where the book could be read. I am
> unsure as to whether I would have to be able to encrypt the file for each
> download. Can anyone offer advice or products capable. I am sure this will
> become a big topic in months / years to come.
>
> Thanks in advance for your assistance
>
> Andy Carroll
What you wish to do can't be done.
If it could, you would make your book far less valuable to your
customer than it would be otherwise. I for one will *not* buy a
book which I do not have a *guarantee* of being able to read
in 10 years. I won't always have the same computer!
You promise you'll still be giving out coppies to
those who switch to a new computer then? Big deal. Your promise
doesn't mean anything if your company folds.
Your book will never be available on an entirely Open Source
system. Anyone who had the source code could patch out the
copy encumberance, so the source code to the reader could not
be distributed, especially under an Open Source license which
would have to allow modification.
People could not search your book with their searching tool of
choice, and they couldn't view it with their viewing tool of
choice (mine is emacs).
In short: Don't try. To the extent that you succeed, you will hurt
your customers. This will hurt *you*.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
Crossposted-To: sci.math
Subject: An interesting page on the Rabin-Miller PP test
From: [EMAIL PROTECTED] (Andrew John Walker)
Date: 5 Jun 2000 14:42:08 +1000
Recently I stumbled across an interesting page at
http://www.geocities.com/SiliconValley/Network/2811/primes/higgins.htm
This paper deals with the number of non-witnesses to a composite number
n using the Rabin-Miller test.
For a number n=p*q, p and q distinct primes, they conjecture
that the number of non-witnesses is a function of
d=gcd(p-1,q-1)
and that if d=2^t*r (r odd)
then the number of non-witnesses is equal to
r^2*(2+(4^t-4)/3)
Does anyone know
a) if these results have been proved
b) if they have been extended to other forms of composite numbers?
Something not mentioned on the page, I believe from a few
trials with ubasic that p^n has p-1 non-witnesses.
For example, 17^4 has 16 non-witnesses:
1
4260
15541
20051
23543
23738
24723
27493
56028
58798
59783
59978
63470
67980
79261
83520
Also, if you try numbers of the form n=p*q*r
with p,q fixed and r increasing, you will notice some patterns
that may help with a general result.
At the end they also conjecture that numbers N=p*q,
p,q prime, p=2r+1, q=4r+1, r odd
have (p-1)(q-1)/4 non-witnesses which supposedly follows from the first
conjecture. In other words, these numbers approach the 25% limit
for the number of non-witnesses.
Andrew Walker
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: XTR independent benchmarks
Date: 4 Jun 2000 21:48:06 -0700
In article <[EMAIL PROTECTED]>,
Wei Dai <[EMAIL PROTECTED]> wrote:
> RSA 1024 Encryption 0.57
> RSA 1024 Decryption 19.44 (40)
> XTR-DH 342 Agreement 62.63
> DH 1024 Agreement 10.53
> LUCDIF 1024 Agreement 27.16
> EC over GF(p) 168 DHC Agreement 14.18
So XTR is -- in this implementation, and if we ignore keypair generation
times -- substantially slower than all the usual competitors? Did I misread
this chart?
Does the following summary of XTR advantages and disadvantages look right?
+ Pro: low-bandwidth, like ECC
+ Small pro: relatively fast keypair generation
(but this is probably less important, except where you want forward secrecy)
- Con: it's slow
Did I miss something, or does that seem about right?
If I am confused, I hope someone will jump in and show me where I went wrong.
I'm just trying to understand the big picture a little better.... Thanks!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cipher design a fading field?
Date: Sun, 04 Jun 2000 21:13:41 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>
> (a) It has not been demonstrated that a group of amateurs can
> in fact design a truly "strong" cipher.
Ah..the old problem: What is strength?
>
> (b) I wish that the amateurs would quit inventing a plethora
> of new encryption schemes until they have figured out how to
> defeat the existing ones. This may be relevant to your thesis.
>
A new cipher each day can clear the palate.
Under your argument here, it is part of the game to keep the pursuers in sight.
egeyd eaoy oane,drs sygdi pp .s pork g, tsn dgte ia fgum kfu hya,Uram pr h.rpkf
The above is encrypted with a base-10 stream cipher using all characters
as two cases in my plaintext answer, and douglasagyn as the key (it threw
out the w since it was not in the keysource text.). The upper case
followed by the lower case are:
Underyouagmth,ispfk.
Fun ain't it?
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
------------------------------
** 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
******************************
