Cryptography-Digest Digest #413, Volume #13 Tue, 2 Jan 01 21:13:00 EST
Contents:
Re: unique codes (Paul Rubin)
Re: unique codes (Mok-Kong Shen)
Re: Test Data for DES? (Simon Johnson)
Very Simple Gift Certificate Scheme (Tom St Denis)
Re: Very Simple Gift Certificate Scheme (Simon Johnson)
Re: Wierd key (PGP v3 RSA) (Wim Lewis)
Re: Very Simple Gift Certificate Scheme (Tom St Denis)
Re: GOST 28147-89 ("[Basic]")
Comets, Meteors, and Mitotic Spindles ([EMAIL PROTECTED])
Re: "Content Protection for Recordable Media" (nobody)
Re: GOST 28147-89 (Tom St Denis)
Re: Very Simple Gift Certificate Scheme (David A Molnar)
question on makeKey in Rijndael ([EMAIL PROTECTED])
Re: Test Data for DES? ("Dave Rudolf")
Re: question on makeKey in Rijndael (Tom St Denis)
Re: GOST 28147-89 ("[Basic]")
Re: Very Simple Gift Certificate Scheme (Tom St Denis)
Re: Very Simple Gift Certificate Scheme (Bryan Olson)
Re: One Way Hash Functions ([EMAIL PROTECTED])
Re: Very Simple Gift Certificate Scheme (Tom St Denis)
Re: GOST 28147-89 (Tom St Denis)
Re: computing RSA keys ([EMAIL PROTECTED])
Re: Genomes (Pealco)
----------------------------------------------------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: unique codes
Date: 02 Jan 2001 11:17:10 -0800
[EMAIL PROTECTED] (Eric Mosley) writes:
> I recentlt received a promotional gift certificate from Amazon. It was
> designated by a unique code:
> CLAIM CODE : XM82-VJY26W-H2LCNQ
> Now, I need to generate unique codes like that! Does anybody know of an
> appropriate algorithm or software library that could be used to generate
> codes like that. I think the key thing here is that you have to be
> unlikely to be able to guess somebody elses/another code..
Well, that's 16 alphanumeric characters; 36**16 = about 2^82.7. So
you can just generate them at random and you'll have to generate more
than a trillion of them before there's much likelihood of any
collisions. Anyway, whenever you generate one you have to record it
in a database so you'll be able to track the amount of the gift
certificate, what promotion it was for, whether it's been redeemed
yet, and so forth. So whenever you generate a new one, you can simply
check that it's not already in the database.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: unique codes
Date: Tue, 02 Jan 2001 20:25:05 +0100
Eric Mosley wrote:
> I recentlt received a promotional gift certificate from Amazon. It was
> designated by a unique code:
> CLAIM CODE : XM82-VJY26W-H2LCNQ
> Now, I need to generate unique codes like that! Does anybody know of an
> appropriate algorithm or software library that could be used to generate
> codes like that. I think the key thing here is that you have to be
> unlikely to be able to guess somebody elses/another code..
I don't know of any ready to use software. From discussions
in a recent thread, it seems that one solution is to run an
appropriate encryption algorithm, which is a bijective
mapping of 16 digits in base 36 and which presumably need
not be very sophisticated for the purpose of your
application, in counter mode.
M. K. Shen
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Test Data for DES?
Date: Tue, 02 Jan 2001 20:33:21 GMT
In article <FCe46.22253$[EMAIL PROTECTED]>,
"Dave Rudolf" <[EMAIL PROTECTED]> wrote:
> Howdy,
>
> I'm doing a software implementation of DES for a school project.
Alas, it has a
> bug. The first round works fine, but it all sems to crap out after
that. It
> would be helpful to have some sample output after each round to
compare with my
> work. Can anyone point me in the right direction?
Put your current version of the algorithm on a website, and put the URL
in this thread :)
> Also, rather unrelated, it seems as though the Initial Permutation in
DES, and
> it's inverse, do not actually add any security to the system, as they
are both
> unary functions. Is this so, or am I missing something?
Nope. They are not really important to the security of the algorithm.
> Thanks,
>
> Dave.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Very Simple Gift Certificate Scheme
Date: Tue, 02 Jan 2001 20:36:57 GMT
My very-simple-most-likely-thought-of-before-but-never-really-discussed-
because-too-many-people-get-this-stuff-wrong paper on simple gift
certificates.
http://www.geocities.com/tomstdenis/files/gcert.ps.gz
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Very Simple Gift Certificate Scheme
Date: Tue, 02 Jan 2001 21:14:04 GMT
In article <92te5a$gn0$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> My very-simple-most-likely-thought-of-before-but-never-really-
discussed-
> because-too-many-people-get-this-stuff-wrong paper on simple gift
> certificates.
>
> http://www.geocities.com/tomstdenis/files/gcert.ps.gz
>
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
>
I hate to moan, but could i have a PDF of this? :)
Simon
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
Crossposted-To: alt.security.pgp,comp.security.pgp.tech,comp.security.pgp.discuss
Subject: Re: Wierd key (PGP v3 RSA)
From: Wim Lewis <[EMAIL PROTECTED]>
Date: 02 Jan 2001 13:42:26 -0800
"Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
> Can someone explain this key to me? What's with the two plain text lines
> at the start of the key block, how is that BASE-64 code?? How come my
> version of PGP understands these headers?
Because that's part of the PGP key block format --- there are some
number of rfc822-ish headers before the base64 data. As far as I know
they never contain any vital data. Usually they indicate the version
of PGP used.
> And what about the 0xCODECODE keyID, doesn't that reduce security? Is it
> possible to generate such a key using secure 1010 bit primes and doesn't
> that take forever? (p == 1/(2^32), so instead of 1 minute it now takes
> ten thousand years instead to create this not-so-random key).
Actually, because the old-style RSA keyID is just the least-significant
32 bits of the modulus, it's easy to modify your prime search algorithm
so that it will only search through numbers which, when multiplied,
produce the desired keyID. It doesn't take significantly longer than
the unmodified algorithm. The result is a perfectly valid key
pair, so all the RSA operations will work on it.
The new-style keyID is the LSBs of the *fingerprint*; it's much harder
to generate a key with a specified fingerprint. As far as I know the
only method is brute force.
> This key looks insecure. In order to change the KeyID to 0xCODECODE, the
> modulus has to be altered, most likely resulting multiple small factors
> easing an attack on the private modulus.
No, the modulus is not altered; instead, primes are chosen to produce
the desired modulus.
Faking another key's keyID this way is sometimes referred to as
a "0xDEADBEEF attack"; it's one reason why you should always use a
fingerprint to authenticate keys, not just the keyID.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Very Simple Gift Certificate Scheme
Date: Tue, 02 Jan 2001 22:04:46 GMT
In article <92tgam$inh$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <92te5a$gn0$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > My very-simple-most-likely-thought-of-before-but-never-really-
> discussed-
> > because-too-many-people-get-this-stuff-wrong paper on simple gift
> > certificates.
> >
> > http://www.geocities.com/tomstdenis/files/gcert.ps.gz
> >
> > Tom
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
> I hate to moan, but could i have a PDF of this? :)
Sure..
http://www.geocities.com/tomstdenis/files/gcert.pdf
It's a very small paper btw...
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "[Basic]" <[EMAIL PROTECTED]>
Subject: Re: GOST 28147-89
Date: Tue, 2 Jan 2001 23:43:42 +0100
As I don't speak c/c++ I dont have any compiler for it.
So please now stop talking, take your masterpiece, encrypt something in ecb
mode and post the details here.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.geo.earthquakes,alt.fluid-dynamics,alt.sci.astro.eclipses
Subject: Comets, Meteors, and Mitotic Spindles
Date: Tue, 02 Jan 2001 22:47:12 GMT
RE: http://www.geocities.com/antarii_rescue/index.html
http://www.geocities.com/antarii_rescue/index2.html
http://www.geocities.com/antarii_rescue/antares.html
http://www.geocities.com/antarii_rescue/aldebaran.html
http://www.angelfire.com/de/CassandraCrossing/PAGE3B.html
The Feb 2001 SKY & TELESCOPE magazine published a story by the Vatican
astronomer Guy Consolmagno titled "The Story of Space Rocks".
He was none too pleased with the recent Smithsonian Press book
called "Asteroids: A History".
Myself, I always thought it was clear to all schoolchildren that
asteroids are lava chunks spewed out by volcanoes here on Earth and
elsewhere, that fly out of the planet's orbit into space.
Meteors have parts iron and parts silicon. Asteroids have next to no
iron. When meteors slam into earth they cause a thermonuclear
explosion and leave much melted glass [tektites], and large salt domes.
To wit: Marquez Dome of Texas; the Upheaval Dome of Moab, UT; the
Ayers Rock region of Australia; the Serpent Mound of Ohio, USA; the
Libyan Desert; the Barringer Crater of AZ; and the underwater crater of
the Barents Sea [the most salty ocean].
The volcanic underwater mountain ridges of the Azores are asteroidal;
as are the Pacific Fire Rim underwater mountain ranges; the whole area
of Hawaii; most of Icelandic quarters; the Mauritius Island archepilago
in the African Indian Ocean; et al.
These asteroidal volcanic areas seem to be seldom, if ever, bombarded
by comets or meteors. Why?
Could Signor Consolmagno please explain this remarkable phenomena!
Could it go back to the arguments of the ancient Ammonites, before they
were turned to pillars of salt [Lot was one of their people], that
concern the difference between asters and astrals?
An aster is a fake star and not genuine. It is also the name of
tubular flowers, tulip like, in China.
An astral is a real star and has a genuine mitotic and meitotic
component.
An aster has a spurious radial arrangement around a spindle-like
mitotic and meiotic cyst.
Hope this stimulates debate.
M. Moroni
In article <[EMAIL PROTECTED]>,
"Roy Sharif M. Sison" <[EMAIL PROTECTED]> wrote:
> A new earthquake just struck Southern Philippines a few moments ago.
> It's either a new quake or a strong shock after the M7.2 submarine
quake
> yesterday afternoon.
> Can anybody point me to a URL with real-time eq monitoring? The USGS
> site does not have a record of the eq yet.
> Thanks.
>
> Regards,
>
> Roy
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: nobody <[EMAIL PROTECTED]>
Subject: Re: "Content Protection for Recordable Media"
Date: Tue, 02 Jan 2001 23:12:11 +0000
>But won't the hackers still be able to intercept the data, when it's on
>its way to, say a PC monitor. Have a debugger copy it from the video
>memory
>or something? Or are you saying that decryption of a video sequence is
>done
>inside the monitor?
sure, when it is decrypted it can be copied. if this is done in
software (e.g. sw player) then it will be a pretty easy task. harder
if in hw. of course, there may be no sw player and the drive could act
just as a storage device moving it between (supposedly secure
tamperproof) hardware players.
though most copy protection schemes when outputting analog signal (and
i think cpsa does this too) will embed a watermark into the media with
copyright signals. compliant devices will look for this watermark and
deal with the media appropriately (in some cases refusing to play it)
funny that you should mention decryption in the monitor. this is of
course the 'holy grail' so to speak. i remember reading of patents for
such technology a while back.
i think part of cpsa does cover high speed interfaces and digital
monitors.
the spec seems pretty comprehensive. just wait to see how the
implementation of it goes.
--
pel
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GOST 28147-89
Date: Tue, 02 Jan 2001 23:21:03 GMT
In article <92tliv$a5v$01$[EMAIL PROTECTED]>,
"[Basic]" <[EMAIL PROTECTED]> wrote:
> As I don't speak c/c++ I dont have any compiler for it.
>
> So please now stop talking, take your masterpiece, encrypt something
in ecb
> mode and post the details here.
Why if you can't program then what does it matter?
Anyways...
key: 00 01 02 03 04 05 06 07 .. .. ..
ct : aa 6e 47 af 95 1c 9f 2a
pt : 00 01 02 03 04 05 06 07
Happy?
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Very Simple Gift Certificate Scheme
Date: 2 Jan 2001 23:25:06 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> My very-simple-most-likely-thought-of-before-but-never-really-discussed-
> because-too-many-people-get-this-stuff-wrong paper on simple gift
> certificates.
Could you include in the next version of the paper some discussion of who
gets it wrong, and what they do wrong?
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: question on makeKey in Rijndael
Date: Tue, 02 Jan 2001 23:32:31 GMT
Hi,
Please bear with me if my question sounds really naive here. :-)
I have a question regarding the "key material" used by Rijndael. Can
the key material be a binary string instead of a ASCII string? The
free implementation I downloaded from Rijndael home page seems to only
allow ASCII input as key material.
Thanks for your answer.
c6ap
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Dave Rudolf" <[EMAIL PROTECTED]>
Subject: Re: Test Data for DES?
Date: Tue, 02 Jan 2001 23:56:45 GMT
Fair enough, though all I really need are some more plaintext-ciphertext pairs,
and it would be nice to have some intermediate values (say the output of each
round, to make sure mine isn't finicky). But if you're just aching to do some
testing, I stashed the code here:
http://members.home.net/dave.t.rudolf/prog/crypto/des-java.zip
The implementation is in Java, and it doesn't use any special packages or
anything. All you need is the basic Java Runtime Enviromnent. I am not too
worried about speed, or else I wouldn't have used Java :) I am primarily
concerned with the correctness of my implementation. Besides, linear speed-up
makes everything happy.
As for the functionality, I have tried it with a fair amount of different keys
and plaintexts (about 100 keys by 1000 texts), and the code will encrypt it and
successfully decrypt it. Whether or not it is to IBM's exact specifications is
still an issue. The data that I have been comparing to disagrees with the final
output (after the inverse initial permutation), but is fine up until the end of
the 16th round. I simply need more (reliable?) data to compare to, as I only had
4 actual plaintext-ciphertext pairs to compare with, 2 of which aggreed with my
code.
Cheerio,
Dave
=======================================================
http://members.home.net/dave.t.rudolf
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:92tduh$gic$[EMAIL PROTECTED]...
In article <FCe46.22253$[EMAIL PROTECTED]>,
"Dave Rudolf" <[EMAIL PROTECTED]> wrote:
> Howdy,
>
> I'm doing a software implementation of DES for a school project.
Alas, it has a
> bug. The first round works fine, but it all sems to crap out after
that. It
> would be helpful to have some sample output after each round to
compare with my
> work. Can anyone point me in the right direction?
Put your current version of the algorithm on a website, and put the URL
in this thread :)
> Also, rather unrelated, it seems as though the Initial Permutation in
DES, and
> it's inverse, do not actually add any security to the system, as they
are both
> unary functions. Is this so, or am I missing something?
Nope. They are not really important to the security of the algorithm.
> Thanks,
>
> Dave.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: question on makeKey in Rijndael
Date: Tue, 02 Jan 2001 23:46:03 GMT
In article <92toef$q6t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
>
> Please bear with me if my question sounds really naive here. :-)
>
> I have a question regarding the "key material" used by Rijndael. Can
> the key material be a binary string instead of a ASCII string? The
> free implementation I downloaded from Rijndael home page seems to only
> allow ASCII input as key material.
Rijndael is speicifed as taking in binary bit strings as keys. If you
source can ONLY read ascii then it's a load of crap. Perhaps you
misread or misunderstood the provided functions?
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "[Basic]" <[EMAIL PROTECTED]>
Subject: Re: GOST 28147-89
Date: Wed, 3 Jan 2001 02:10:54 +0100
"Tom St Denis" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:92tnon$pkl$[EMAIL PROTECTED]...
> In article <92tliv$a5v$01$[EMAIL PROTECTED]>,
> "[Basic]" <[EMAIL PROTECTED]> wrote:
> > As I don't speak c/c++ I dont have any compiler for it.
> >
> > So please now stop talking, take your masterpiece, encrypt something
> in ecb
> > mode and post the details here.
>
> Why if you can't program then what does it matter?
the only language i speak is x68 assembler
>
> Anyways...
>
> key: 00 01 02 03 04 05 06 07 .. .. ..
> ct : aa 6e 47 af 95 1c 9f 2a
> pt : 00 01 02 03 04 05 06 07
thx for you work but without knowledge of the SBoxes that were used this
example is useless.
btw post if you increment the key in hex and it's half the work
>
> Happy?
yes
>
> Tom
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Very Simple Gift Certificate Scheme
Date: Wed, 03 Jan 2001 01:29:27 GMT
In article <92to0i$si5$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > My very-simple-most-likely-thought-of-before-but-never-really-
discussed-
> > because-too-many-people-get-this-stuff-wrong paper on simple gift
> > certificates.
>
> Could you include in the next version of the paper some discussion of
who
> gets it wrong, and what they do wrong?
Well it's just a small snippet paper since I have seen people ask this
question before. Often you goto sites like mail.yahoo.com and get
tokens "mail.yahoo.com/read.pl?rand=294724892734" where rand= is a
certificate of sorts. I wonder how they made it...
I dunno.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Very Simple Gift Certificate Scheme
Date: Wed, 03 Jan 2001 01:29:56 GMT
Tom St Denis wrote:
> My
very-simple-most-likely-thought-of-before-but-never-really-discussed-
> because-too-many-people-get-this-stuff-wrong paper on simple gift
> certificates.
>
> http://www.geocities.com/tomstdenis/files/gcert.ps.gz
I suggest you read up on digital cash.
This scheme, as well as I can make it out, does nothing to
protect the customer from denial of a good certificate, nor
from an imposter selling bogus certificates. There's no note
of any value recorded with the certificate either.
At the very least, the seller should have a well known public
key that signs the certificates, and each certificate should
hold a public key supplied by the buyer (as well as the nonce
and value indication). To spend the certificate, the buyer
signs an order, which includes the certificate, with the
associated private key, and sends the order to the seller.
In case of a dispute over whether a certificate is good, the
buyer shows the certificate. If it's does not verify with the
seller's public key, it's not good. If it does, then the
seller shows the corresponding order message. If the order
does not verify with the public key in the certificate, then
the certificate is still good. If the order does verify, then
the certificate is already spent. We still have the question of
whether the order was filled, but that's the same as with any
on-line transaction.
Note that in this scheme only the private keys are secret.
All the messages can pass in the clear. If the certificate is
to be a gift, then the buyer sends the public key of the gift's
recipient for inclusion in the certificate.
There are still other improvements we could make. Does the
seller have to record orders forever? Can gifts be given so
that the seller can't tell who gave what to whom? Digital
cash schemes answer such questions and more.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: One Way Hash Functions
Date: Wed, 03 Jan 2001 01:39:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Nemo psj) wrote:
> could any of you point out where I can get some info
> on One way Hash functions and or source or mathematicle epxlanations.
i hope this PhD thesis will help,
Y. Zheng(1990), "Principles for Designing Secure Block Ciphers and One-
Way Hash Functions" at http://crypto.ee.ntu.edu.tw/lab333/tech-
rep/crypto/theses
W.S.Chong
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Very Simple Gift Certificate Scheme
Date: Wed, 03 Jan 2001 01:42:11 GMT
In article <92tvad$t$[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > My
> very-simple-most-likely-thought-of-before-but-never-really-discussed-
> > because-too-many-people-get-this-stuff-wrong paper on simple gift
> > certificates.
> >
> > http://www.geocities.com/tomstdenis/files/gcert.ps.gz
>
> I suggest you read up on digital cash.
>
> This scheme, as well as I can make it out, does nothing to
> protect the customer from denial of a good certificate, nor
> from an imposter selling bogus certificates. There's no note
> of any value recorded with the certificate either.
>
> At the very least, the seller should have a well known public
> key that signs the certificates, and each certificate should
> hold a public key supplied by the buyer (as well as the nonce
> and value indication). To spend the certificate, the buyer
> signs an order, which includes the certificate, with the
> associated private key, and sends the order to the seller.
>
> In case of a dispute over whether a certificate is good, the
> buyer shows the certificate. If it's does not verify with the
> seller's public key, it's not good. If it does, then the
> seller shows the corresponding order message. If the order
> does not verify with the public key in the certificate, then
> the certificate is still good. If the order does verify, then
> the certificate is already spent. We still have the question of
> whether the order was filled, but that's the same as with any
> on-line transaction.
>
> Note that in this scheme only the private keys are secret.
> All the messages can pass in the clear. If the certificate is
> to be a gift, then the buyer sends the public key of the gift's
> recipient for inclusion in the certificate.
>
> There are still other improvements we could make. Does the
> seller have to record orders forever? Can gifts be given so
> that the seller can't tell who gave what to whom? Digital
> cash schemes answer such questions and more.
I assumed (if you read the paper) that a secure HTTPS connection had
been negotiated (and this includes a theory of trust via CA signed
keys).
The protocal given is secure provided that the person who hands you the
certificate is trusted (which is assumed) and that you don't give out
your certificate to anyone else.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GOST 28147-89
Date: Wed, 03 Jan 2001 01:40:20 GMT
In article <92tu70$e3l$01$[EMAIL PROTECTED]>,
"[Basic]" <[EMAIL PROTECTED]> wrote:
>
> "Tom St Denis" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
> news:92tnon$pkl$[EMAIL PROTECTED]...
> > In article <92tliv$a5v$01$[EMAIL PROTECTED]>,
> > "[Basic]" <[EMAIL PROTECTED]> wrote:
> > > As I don't speak c/c++ I dont have any compiler for it.
> > >
> > > So please now stop talking, take your masterpiece, encrypt
something
> > in ecb
> > > mode and post the details here.
> >
> > Why if you can't program then what does it matter?
>
> the only language i speak is x68 assembler
>
> >
> > Anyways...
> >
> > key: 00 01 02 03 04 05 06 07 .. .. ..
> > ct : aa 6e 47 af 95 1c 9f 2a
> > pt : 00 01 02 03 04 05 06 07
>
> thx for you work but without knowledge of the SBoxes that were used
this
> example is useless.
> btw post if you increment the key in hex and it's half the work
The sboxes are in the source code I referenced. Just pull em out!
And the key bytes go from 0 to 31 (decimal).
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: computing RSA keys
Date: Wed, 03 Jan 2001 01:43:49 GMT
I'm looking into PKCS #1. Thanks for that.
> Miller-Rabin is good, but here's the sequence I recommend:
>
> 1. Sieve to eliminate candidates with small prime factors.
> 2. Do one base-2 Fermat test.
> 3. Do several Miller-Rabin tests.
>
I haven't looked at Fermat yet. I'll look it up.
> Exactly how many small primes to sieve against is
> unimportant;
Going straight to Miller-Rabin is giving results in acceptable time
now. I was finding that GCD with the multiplied agregate of primes less
than 200 was hanging for some small primes because the multiplied
agregate was much larger. I think with normal sized keys I could
probably put it back in, but I'm still not convinced that the time
saved is worth the extra step.
> I think small values for e are fine. Three is particularly
> efficient. Given the standard RSA formatting, no one has
> shown how to break these faster than random e. On the other
> hand there are respectable cryptologists who suspect that
> small public exponents may weaken RSA.
How curious. I can tell I'm approaching this problem so differently
from others... I started with the article, "The Mathematical Guts of
RSA Encryption," I think in connection with rfc2315.
If e is 3, I'd think one could simply add the public modulo (pq) until
you find a total which can be cube-rooted evenly. I suppose there might
be other even cube-roots besides the first... Is that what makes it
difficult?
> Below is complete code for modular inverse with arbitrarily
> large integers in Python. Javascript will not be as neat.
Thanks for this -- I'll see if this gives results faster than the
method I'm using.
Thanks, Bryan, for the very helpful reply.
John
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Pealco)
Date: 03 Jan 2001 01:52:38 GMT
Subject: Re: Genomes
Actually I believe this has been done. The winner of 2000's Intel Science
Talent Search did her project on DNA-Based Steganography.
Here's the link: http://www.intel.com/pressroom/archive/releases/ed031300.htm
--Pedro
------------------------------
** 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
******************************
