Cryptography-Digest Digest #405, Volume #11 Thu, 23 Mar 00 20:13:01 EST
Contents:
Re: Open source or not. (Was: Re: Planet Poker Claims...) (Mike Caro)
Re: Factoring Large Numbers - I think I figured it out! (Jerry Coffin)
Re: Big Float: square root (Mike Mccarty Sr)
Re: Concerning UK publishes "impossible" decryption law ("�R���")
Re: Concerning UK publishes "impossible" decryption law ([EMAIL PROTECTED])
Re: NIST publishes AES3 papers ("Trevor L. Jackson, III")
Re: Next Vernam variety idea. ("Adam Durana")
Re: implementing rot13 (Gregory G Rose)
Re: Concerning UK publishes "impossible" decryption law (Will Dickson)
Re: new Echelon article (Mok-Kong Shen)
Re: NIST publishes AES3 papers ("Douglas A. Gwyn")
Re: implementing rot13 (Owen Rees)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David
Hopwood)
Re: implementing rot13 ("Douglas A. Gwyn")
Re: Opinions? ([EMAIL PROTECTED])
Re: root mod a prime? (lordcow77)
Re: Secret Key (En|De)cryption functions (Doug McNaught)
Re: bigfloat works (kinda) (lordcow77)
----------------------------------------------------------------------------
From: Mike Caro <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Date: Thu, 23 Mar 2000 23:10:09 GMT
On Thu, 23 Mar 2000 17:41:12 -0500, Johnny Bravo <[EMAIL PROTECTED]>
wrote:
>On Wed, 22 Mar 2000 06:16:36 GMT, Mike Caro <[EMAIL PROTECTED]> wrote:
>
>>I also specifically challenge the idea that "atomic decay" methods of
>>random number generation are a superior solution.
>
> Because natural atomic decay is proven to be random. If you know of a
>flaw in John Bell's proof or Alain Aspect's experimental verification of
>that proof, publish it and pick up your Nobel Prize in Physics. :)
Interesting, and I take it in the good smiley-face spirit it was
delivered, but it doesn't seem to apply to what I said.
Straight Flushes,
Mike Caro
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Thu, 23 Mar 2000 16:11:49 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Richard Anthony Hein wrote:
> > Oh yeah, I forgot to mention that the method would have enabled us to solve
> > for the 3 numbers which multiply to make a number as simply as 2 numbers,
> > and at the same time. 4 and more would also eventually be possible ... if
> > it would have worked. Or is this something that we are already able to do
> > efficiently?
>
> It doesn't much matter, because once one factor is known, division by
> that factor is very fast, relatively speaking, so you just iterate
> the factoring method. Compared to the cost of finding even *one*
> (nontrivial) factor, the rest of that procedure is peanuts.
...usually. Now and then, numbers have been factored to the point of
producing a relatively large composite factor that took a great deal
longer to factor. IIRC, Knuth gives one example like this in V2, and
others have undoubtedly occurred since then as well. I'm not sure,
but ISTR there being at least one situation like this right now,
where one of the factors of a number is known to be composite, but
nobody knows what its factors are (yet).
Simply being smaller doesn't necessarily mean a number is easier to
factor.
Though I'm sure Doug knows at least as much about this point as I do
(and Bob Silverman certainly knows a lot MORE than I do) most methods
used for factoring really large numbers find all factors more or less
simultaneously. If you're using the QS or NFS, it makes little real
difference whether a number has 2 factors or 20, they'll all be found
at once, and you never see a composite factor at all.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Mike Mccarty Sr)
Subject: Re: Big Float: square root
Date: 23 Mar 2000 22:50:20 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
)Fixed a bunch of bugs and added one more basic function. Turns out that
)the division algorithm in Knuth does not work, so I switched to one that
)does. There seems to be a bug in the ascii_to_float routine for very
Interesting. When I wrote a multiprecision package many years ago, it
worked for me.
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: "�R���" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Fri, 24 Mar 2000 10:20:06 +1100
I don't know, just saying that as far as I know, in aussie land, we can get
what we want, except for where we only get international versions of
encryption, where exporting from originating countries of 128 bit encryption
is illegal. if I have 128 bit now, I am allowed, but you aren't allowed to
give it to me. at least that is my understanding.
--
"Oh GOD, Please save me from your followers"
more of my ramblings can be found at http://oakgrove.mainpage.net
"Man is a part of nature, not apart from nature"
anti spam, remove 'nospam' to mail me
ICQ:16544782
"Richard Herring" <[EMAIL PROTECTED]> wrote in message
news:8bd9m3$2ou$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, �R��� ([EMAIL PROTECTED])
wrote:
> > I know a little of engineering, but not enough to say it will work,
history
> > was my major, at least I know not to repeat history. as for magnets, I
> > should maybe take my foot out of my mouth to find a new topic. I have to
> > think of different ways to hide data, as 128 bit encryption is not
available
> > to me as far as I know in Australia,
>
> Not available, or not allowed?
> You can easily find it, e.g. http://www.pgpi.org
>
> > and I have heard that 56 k has been decoded by authorities.
>
> 56-*bit*? PGP may be crackable with available computer power, but
> triple-DES is probably still way beyond that kind of attack.
>
> --
> Richard Herring | <[EMAIL PROTECTED]>
>
>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Thu, 23 Mar 2000 23:39:37 GMT
I'm in Australia too... I think you can probably use PGPi here, I read the Crypto
survey
somewhere, and it said that there wasn't really any restrictions if I remember right
On Fri, 24 Mar 2000 10:20:06 +1100, "�R���" <[EMAIL PROTECTED]> wrote:
>I don't know, just saying that as far as I know, in aussie land, we can get
>what we want, except for where we only get international versions of
>encryption, where exporting from originating countries of 128 bit encryption
>is illegal. if I have 128 bit now, I am allowed, but you aren't allowed to
>give it to me. at least that is my understanding.
>
>--
>"Oh GOD, Please save me from your followers"
>more of my ramblings can be found at http://oakgrove.mainpage.net
>"Man is a part of nature, not apart from nature"
>anti spam, remove 'nospam' to mail me
>ICQ:16544782
>"Richard Herring" <[EMAIL PROTECTED]> wrote in message
>news:8bd9m3$2ou$[EMAIL PROTECTED]...
>> In article <[EMAIL PROTECTED]>, �R��� ([EMAIL PROTECTED])
>wrote:
>> > I know a little of engineering, but not enough to say it will work,
>history
>> > was my major, at least I know not to repeat history. as for magnets, I
>> > should maybe take my foot out of my mouth to find a new topic. I have to
>> > think of different ways to hide data, as 128 bit encryption is not
>available
>> > to me as far as I know in Australia,
>>
>> Not available, or not allowed?
>> You can easily find it, e.g. http://www.pgpi.org
>>
>> > and I have heard that 56 k has been decoded by authorities.
>>
>> 56-*bit*? PGP may be crackable with available computer power, but
>> triple-DES is probably still way beyond that kind of attack.
>>
>> --
>> Richard Herring | <[EMAIL PROTECTED]>
>>
>>
>
>
=====================================================
PGP key:0x5B70E7A5 3072/1024 DH/DSS
Fingerprint:10BC 8849 4215 537D 89E5 1C85 12AA E55C 5B70 E7A5
------------------------------
Date: Thu, 23 Mar 2000 18:56:38 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Paul Koning wrote:
> Trevor,
>
> It would be much easier to read your posts if you could configure
> your software so it wraps lines, or wrap them by hand. Reading
> 1000-characters lines by horizontal scrollbar is a major pain.
>
> paul
Sorry, I'm trying to get away from
the
effect of having a word-wrap
setting
that doesn't match the setting
of
the readers or writer. I'm sure
you
know what I mean. ;-)
P.S. Is wrap-to-window rare?
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Next Vernam variety idea.
Date: Thu, 23 Mar 2000 18:50:08 -0500
You are right the security of your system depends on the first key, so why
change the key at all? You could easily exchange a key using DH, RSA, and
etc. Then use that key in a stream cipher or block cipher. Sending random
data when you aren't using the link seems like a waste, because at what
frequency are you going to send the random data? I suppose you could send
the random data at random frequencies. If you send it too frequently you'll
be wasting quite a bit of bandwidth and if you send it too infrequently real
data will be easy to spot, since someone using the link will most likely be
sending several packets within a small space of time. However there are
systems that work like this, where a network has random data being sent
across it. However the goal of these systems is to hide any "real"
activity, so someone monitoring the network could not tell if anyone was
using it or not. In your system if someone is intercepting all the data
including the random data they know someone is using it to chat. This
sounds sort of like Rivest's "chaffing and winnowing", where instead of
encrypting data you send a bunch of data and the real data is intermingled
with the random data, and the key allows the reciever to filter out the
random data to find the real data. I say you use a good stream cipher and
exchange keys using DH or RSA, and don't even bother with sending random
data. As it is now your system is over complicated, and making a crypto
system that is very complicated is bad, especially when there is a much
simpler solution.
- Adam
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: implementing rot13
Date: 23 Mar 2000 15:53:07 -0800
In article <[EMAIL PROTECTED]>,
<>for ( char *s=string; *s; s++)
<> *s += isalpha(*s) ? (toupper(*s)<('A'+13))*26-13 : 0;
<
<Cute.
<
<Okay, the gauntlet has been thrown -- who can do it in even
<fewer (non-whitespace) characters?
You should have specified the programming
language, methinks...
tr A-Za-z N-ZA-Mn-za-m
is a shell command that works on linux, GNU and
BSD-derived Unix systems. (The syntax is
slightly different on System-V derived versions.)
Since there is an equivalent in Perl, which runs
on just about anything:
perl -pe 'tr/A-Za-z/N-ZA-Mn-za-m/'
is a very portable alternative (note that I've
given *complete* programs, with input and
output!). I can't understand why anyone would
prefer to use C for this job.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: [EMAIL PROTECTED] (Will Dickson)
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Fri, 24 Mar 2000 00:00:12 GMT
[EMAIL PROTECTED] (Richard Herring) wrote:
>In article <[EMAIL PROTECTED]>, �R��� ([EMAIL PROTECTED]) wrote:
>
>[upside-down quoting restored]
>
>> "Richard Herring" <[EMAIL PROTECTED]> wrote in message
>> news:8b5e2s$f9d$[EMAIL PROTECTED]...
>> > In article <[EMAIL PROTECTED]>, �R��� ([EMAIL PROTECTED])
>> wrote:
>> > > an electric magnet is not so hard to make or get hold of, its harmless
>> > > unless power is given to it, and when powered, can be easily be strong
>> > > enough to destroy data an the disks.
>> >
>> > I find that difficult to believe Can you provide figures to
>> > justify your assertion?
>
>> well, if configured right to use power from your power pack, it might be
>> strong enough to damage your disks,
>
>I'll take that as a "no", then. The word was "destroy", not "damage",
>and the request was for quantitative data.
FWIW: I don't have precise figures to hand (I probably ought to be
able to work it out, but I'm waaay rusty), but to an order of
magnitude, you'd probably need the thick end of a Tesla. That kind of
field over a macroscopic region needs hundreds of amps to kiloamps, so
you're talking either superconducting (for which you'd really need
liquid helium cooling, but you might be able to get away with pumped
nitrogen) or fluid-cooled normal-state coils. And power supplies the
size of a freezer. Further, you really want AC field for degaussing,
and reversing _that_ lot is non-trivial - the coil induction doesn't
want you to, and since it has a megajoule or so of field energy
backing it up (that's comparable to the energy released by exploding a
stick of dynamite, to put it in context) it can fight you very
effectively. Putting your machine on a turntable might be a better
alternative (and no, I'm not being even slightly serious here).
Mind you, it might be the case that when the LEO sees that lot, s/he
writes you off as a mad scientist-type nutter and doesn't bother to
look at the disk anyway :-).
A more practical alternative is the recovery-resistant wipe schedule
developed by Peter Gutmann (sp?) I don't have the reference handy but
I could look it out if you're interested. It's slow - 35 passes - but
you can do it in software and unlike the above it's practical.
Will.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: Fri, 24 Mar 2000 01:29:29 +0100
John Savard wrote:
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
> >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.
>
> And that is a good general principle. Why Germany, and _most other
> countries_, waive this principle in connection with bribing officials
> in some countries is because there are countries in which the
> government is in such a condition that there is no option but to give
> in to demands for bribes if you want to do business.
There can be absolutely no question that the principle is good, in my
humble opinion. I suppose that is also an acknnowledged principle
in German and European justice, although, being not a lawyer, I can't
say anything about its practical applications. I am personally of
the opinion that bribery should be eliminated much like other bad
things like drugs. There were once opinions expressed in German
newspapers criticizing the matter I mentioned. But obviously there
was not sufficient 'momentum' to be able to push the politicians
to modify the laws. On the other hand, you were mentioning bribery
in the context of the payers being in the developed countries and the
receivers being in the developing countries. What I wanted to pointed
out is that this is only part of the scene, because there are cases
where both the payers and receivers are in the (same or different)
developed countries. That is, bribery is an issue rather independent
of the countries (where it occurs) being developed or not (quite
like AIDS that is everywhere).
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Fri, 24 Mar 2000 00:22:56 GMT
Jim Gillogly wrote:
> there's no significant difference in strength between a
> 112-bit search and a 127-bit one... they're both out reach.
I'm sure Jim knows this, but he forgot to add the qualification:
"assuming that there is no attack substantially better than
brute-force key search". Which is quite an assumption..
------------------------------
From: [EMAIL PROTECTED] (Owen Rees)
Subject: Re: implementing rot13
Date: Fri, 24 Mar 2000 00:23:20 GMT
On Mon, 20 Mar 2000 17:20:35 -0600, Stephen Houchen
<[EMAIL PROTECTED]> wrote:
>Arthur Dardia wrote:
[...]
>> for (i=0;i<lRef.length();i++) {
>> for (int a=0;a<target.length();a++) {
>> if (target[a]==lRef[i]) {
>> target[a]=lRef[(i+xx)%25];
>> }
>> }
>> }
[..]
>> key:? abcdefghijklmnopqrstuvwxyz
>> rot13: bcdefghijklmabcdefghijklmn
>>
>> As you can see, if I input a test key and attempt to ROT-13 it, the
>> second half of the key (n->z) is properly rot-13'd; however, the first
>> half is not. What's going on?
>
>You're changing some letters twice. Notice your second for-loop pair.
>You first change the 'a' to 'n' correctly, but instead of going on to the
>next character, you change the 'n' back to an 'a' before going on.
Yes some letters are being changed twice, but not quite that way. The
outer loop steps through the translation table and the inner loop
scans the target string so what happens is:
scan target changing 'a' to 'n'
scan target changing 'b' to 'o'
...
scan target changing 'n' to 'b'
and here the original 'a', changed to 'n' is changed again to 'b'.
The target string is being updated in place, and new values are being
operated on as if they were old values. Nesting the for loops that way
round makes it hard to separate old and new values. If you step
through the target string in the outer loop, and 'break' to exit the
inner loop when you get a match, you will have the effect you want
provided that you replace 25 with 26 as pointed out elsewhere.
Other people have posted faster and shorter techniques that depend
upon an unstated assumption. The corrected version of the original
program does not make that assumption. Uncovering the assumption is
left as an exercise for the reader (at least for now).
--
Owen Rees
These are personal opinions and do not represent any
policy or position of current or former employers.
------------------------------
Date: Thu, 23 Mar 2000 03:56:12 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
=====BEGIN PGP SIGNED MESSAGE=====
Scott Fluhrer wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > iaPCBC is "integrity aware Propagating Cipher Block Chaining", by
> > Virgil Gligor and Pompiliu Donescu, as described in [1] and [2].
> >
> > It was broken by David Wagner et al at Counterpane in [3] (despite
> > a "proof of security"). [...]
>
> Huh? I thought that they made two claims in their original paper:
>
> 1. It was difficult to forge messages without knowing the key
>
> 2. It was more secure than CBC mode
>
> I though David Wagner disproved claim 2, but I thought claim 1 is still
> valid (or at least, not disproven yet).
Wagner et al disproved both claim 1 and claim 2. That is, iaPCBC (as presented
in Gligor & Donescu's original paper and Internet Draft) is broken as a means
of ensuring integrity, and also it doesn't provide significantly better
confidentiality than CBC (it is no worse in that respect than CBC, but
without the integrity feature there's not really any point in using it).
> If I'm wrong, I'd like to know the details.
I don't know whether [3] has been published yet, but you can probably obtain
it from David Wagner.
[1] Virgil D. Gligor <[EMAIL PROTECTED]>,
Pompiliu Donescu <[EMAIL PROTECTED]>,
"Integrity-Aware PCBC Encryption Schemes,"
http://www.research.att.com/~smb/papers/iapcbc.ps
November 11, 1999.
[An earlier version was presented at the 7th International Workshop
on Security Protocols, Cambridge, U.K., April 1999. An abridged
version will appear in "Security Protocols", LNCS, Springer-Verlag,
B. Christianson, B. Crispo, M. Roe (eds.)]
[2] Virgil D. Gligor, Steven M. Bellovin,
"An iaPCBC Transform for IPsec,"
http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt
(IETF draft; work in progress, expires May 2000.)
[3] Niels Ferguson, Doug Whiting, John Kelsey, David Wagner,
"Critical Weaknesses of iaPCBC,"
November 24, 1999.
- --
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
iQEVAwUBONmVoTkCAxeYt5gVAQE6fQgAusKC3SsH4LOUWW9nyNh4CB6thLgMIS69
g3LmlL+6nWFCSwU0mfUh0WsWhROyq7ApkCbt5eMIg3cVVs93+9lXLnnuFPtHFPVh
Ao/z6bgb77a265QlMXk432s+ip5eGVYE3IFy5Vhcnaw1Oxux1WIp2Nnp7OLbrCcL
4v5zI+bldDMbPuGIfbH2T9zQmWxqEnRQCmUhRmM52gGhbYisobYs8NXc5EMje+T0
4VU6S2/3zJX8ASTRWGjhZHJ7xjONWQ9a6LjQo6WCrzzGfvorYz0Q0d6zkG/B/4JN
b/Z6LiTJ6PoBaOoCiP4RXdUbPs/5JosBA8WaWfoAcGwRk21TUOfeVQ==
=+gq6
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: implementing rot13
Date: Fri, 24 Mar 2000 00:26:46 GMT
Gregory G Rose wrote:
> tr A-Za-z N-ZA-Mn-za-m
> ... I can't understand why anyone would prefer to use C for this job.
main(){return system("tr A-Za-z N-ZA-Mn-za-m");}
Getting shorter all the time.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Opinions?
Date: Fri, 24 Mar 2000 00:32:49 GMT
In article <[EMAIL PROTECTED]>,
Johnny Bravo <[EMAIL PROTECTED]> wrote:
> On Thu, 23 Mar 2000 13:19:22 GMT, [EMAIL PROTECTED] wrote:
>
> >By this statements, you're reducing the notion of randomness to
> >predictability.
>
> Not exactly. In the half life of an atom there is a 50-50 chance it
> will decay. There is no way to tell in advance if it will do so, an atom
> fresh from a reactor core have the exact same 50-50 chance as atoms of
> that type that have existed without decay for a billion years. Over the
> halflife there is a 50-50 chance, and which one occurs is entirely random.
Exactly, but that only means that you cannot predict wether it has
decayed at halflife time or not. At halflife time, when you observe it,
the atom has either decayed or not, and of course, it is not in a 50-50
state.
> You are confusing overall probability with predictability. If I can
> flip an unbiased coin a billion times, I will have a very close result in
> heads and tails. This 50-50 distribution does not have any predictive
> power.
It of course has. If I flip the coin another billion times, the result
will be similar to the previous. You mean that it has no predictive power
regarding one single flip of coin. Agreed, that's what I was talking
about.
> >However, there's a theoretical difference. If, as an
> >experiment of thought, a time machine had been invented, we would be able
> >to predict the time when one single atom decays by traveling forward in
> >time and observing it.
>
> As a similar experiment of thought God is all-knowing, and all-powerful
> and designed in advance every sequence that will be created when he
> created the universe. Since it was designed in advance, no sequence will
> ever be random. Now that the concept of randomness has been disproved, we
> can return to the real world.
That's simply wrong. The sequences God will have produced *are* random,
just as a random sequence recorded by a random generator are random. Or
do you really think that any recorded random sequences turn into non-
random just by recording?
The fact that you can predict sequences does not mean that they are not
random. Otherwise there would be no difference between predictability and
randomness. And by the way, there's a large difference between the two
experiments of thought: Mine is (to some extent) falsifyable while yours
is not. If you travel forwards in time, and happen to observe the atom in
a strange 50-50 state, and travel back and report, my argument has been
proven pointless. That's why it's a scientifically correct experiment of
thought.
Best regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: root mod a prime?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Thu, 23 Mar 2000 16:59:17 -0800
The order of a specific point on a curve is easily determined if
you know the number of points on the curve. Mike Rosing provides
a lucid description of this process in a previous posting.
* 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: Doug McNaught <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.moderated
Subject: Re: Secret Key (En|De)cryption functions
Date: 23 Mar 2000 19:34:36 EST
"David L. Nicol" <[EMAIL PROTECTED]> writes:
[algorithm snipped]
I don't pretend to be an expert (though I've done a lot of reading on
the subject) but this looks very weak cryptographically. Possible
attacks include:
1) I doubt CC numbers are truly random--with enough knowledge about
their statistical distribution, and the ability to line up
ciphertext in columns encrypted with the same key, you could
potentially recover the key.
2) Also, CC numbers have an internal consistency (check digit) that
might [rovide an avenue of attack.
There are Perl modules for known-string algorithms--Blowfish, 3DES,
IDEA--why not use them?
-Doug
------------------------------
Subject: Re: bigfloat works (kinda)
From: lordcow77 <[EMAIL PROTECTED]>
Date: Thu, 23 Mar 2000 17:09:04 -0800
Calculating the group order of the set of points on an eliptic
curve modulo a prime requires different algorithms than those
used for curves defined over a polynomial or normal basis. If
you are currently trying understand how the basic eliptic curve
encryption algorithm works, I do not suggest trying to learn
about point counting algorithms, especially over arbitrary
primes! If you truly want to get started, try reading the
Complex Multiplication method in the appendix of P1363. Any
point counting algorithm for general curves of cryptographic
interest will be rather involved though...
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
** 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
******************************
