Cryptography-Digest Digest #299, Volume #12 Thu, 27 Jul 00 14:13:01 EDT
Contents:
Re: Selecting cipher - which one to use? (Runu Knips)
Re: Selecting cipher - which one to use? ("Scott Fluhrer")
Crypto Export Controls ([EMAIL PROTECTED])
Re: RC5 Question ("Douglas A. Gwyn")
Re: New stream cipher ("Douglas A. Gwyn")
Re: PGP US Versions Broken,no good?? ("Douglas A. Gwyn")
Re: School question for you regulars. ("Douglas A. Gwyn")
counter as IV? ("Douglas A. Gwyn")
Re: Question.How to avoid weak curves? ("Douglas A. Gwyn")
Re: School question for you regulars. ("Douglas A. Gwyn")
PalmOS web browser security (rot26)
Re: counter as IV? (stanislav shalunov)
Re: counter as IV? (John Myre)
Re: Crypto Export Controls (jungle)
Re: MD5 algorithm questions (Scott Long)
Enigma (Matthew S)
Re: Enigma (Mark Wooding)
JavaCard vs Multos security ([EMAIL PROTECTED])
Re: Database encryption (ganges)
Gretacoder Hardware Encryption (ganges)
Re: MD5 algorithm questions (John Myre)
Re: What is DES3mCBCMACi64pPKCS5? (Alan Braggins)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Anton Stiglic)
Re: MD5 algorithm questions (Tom Anderson)
Re: MD5 Expansion (Anton Stiglic)
Re: How is the security of Outlook Express encryption ? ("Joseph Ashwood")
Re: Finding prime numbers (Anton Stiglic)
Re: Elliptic Curves encryption (Mike Rosing)
Re: Diffie's New directions in Cryptography (Anton Stiglic)
----------------------------------------------------------------------------
Date: Thu, 27 Jul 2000 16:26:37 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Eric Lee Green wrote:
> Cryptosystems design is a field for paranoids, not for
> normal well-adjusted people :-).
In fact, one of the main reasons why I like crypto is far
there are so many possiblities for designing own algorithms,
while in other fields, for example sorting, the ways to do
it are far more limited. :-)
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Date: Thu, 27 Jul 2000 07:15:18 -0700
Lisa Retief <[EMAIL PROTECTED]> wrote in message
news:8loiue$s4j$[EMAIL PROTECTED]...
> Hi all,
>
> I am a crypto ignoramus and need to select a cipher to use in a software
> development project. The requirements are as follows - we will need to
> encrypt a large amount of data as a whole (as securely as possible), but
> when decrypting we will only be decrypting small chunks of the larger data
> at a time - ie. we will not have access to the rest at the time. Someone
has
> suggested IDEA but I can't find any documentation on this cipher?
It sounds like you need to answer (or at least ask) a few questions first:
- What is the attack model? What are you trying to prevent the attacker
from doing? What is the attacker allowed to do?
I assume that you are trying to prevent the attacker with access to the
encrypted database from reading it. Is he allowed to write values into the
database, and see what happens? There are several things he can attempt
with this possible attack: success if the gibberish written is accepted,
success if he copies some other database record, success if by reading the
resulting plaintext, he is able to gain insight into other database records.
- What operations does a legitimate user need to have? Will there be
several levels of users, some allowed to read the database, and others
allowed to update the database? Will some users be able to read only
defined portions of the database?
- If you are using a symmetric cipher (such as IDEA), how do you do key
distribution? That is, a user of a symmetric cipher must have a secret key
that allows access to the data. How will legitimite users gain access to
the key?
- Will there ever be the need to change the secret key?
- How much worth would it be to an attacker to break your system? How much
would you lose if it is broken?
If you want, you can talk about your needs. However, if you are trying to
protect anything significant, I strongly urge you not to take the advise of
some guys on a newsgroup, but instead find a good security consultant.
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Crypto Export Controls
Date: Thu, 27 Jul 2000 14:30:10 GMT
Hi, I'd like to use crypto in software I write, and I'm worried about
export controls (I'd like the product to be exportable). I'd like to
write one version of the software and make it available for download --
and I don't want to restrict it to just United States users. In
particular, I'm interested in knowing to what extent I can use crypto
routines without actually having to get a license of any sort.
- From what I understand, it is ok to use Authentication routines
(digital signatures / MACs) as long as they can't "implicitly" be used
for confidentiality (though it's not clear what that means given
Rivest's Chaffing and Winnowing idea). Is this correct?
- Are there public domain libraries that I can use in software I write
without having to get any kind of license? (e.g. maybe Wei Dai's
Crypto++?) What about libraries that you have to pay for?
- Are there versions of existing standard cryptographic schemes that
are OK for export? e.g DES or some other well known algorithm with a
40-bit key?
- In general, how can I (and to what extent can I) use cryptographic
routines in software I develop witohut needing a license of any sort?
Where can I find more resources that talk about the current state of
crypto export controls?
Thanks for any help you can offer.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: RC5 Question
Date: Mon, 17 Jul 2000 22:28:59 GMT
phil hunt wrote:
> >#include <inttypes.h>
> >typedef uint32_t u4;
> Is this standard C/C++ now?
It is part of the 1999 C standard, and has been found on
many platforms (especially 64-bit ones) for several years.
One nice thing is that if <inttypes.h> is missing on your
current system, it is not hard to provide your own. There
is a free tailorable implementation at
http://kbs.cs.tu-berlin.de/~jutta/c/q8/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Thu, 20 Jul 2000 14:58:07 GMT
[EMAIL PROTECTED] wrote:
> AOTP-Alex One Time Pad stream cipher. ...
> Idea of this algorithm goes up to Vigenere cipher. ...
> Key has length 256 byte. ...
Then it is certainly not a "one time pad" system and
ought not to be labeled as such.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: PGP US Versions Broken,no good??
Date: Tue, 25 Jul 2000 15:26:30 GMT
Bill Unruh wrote:
> [Or perhaps there exist problems which are difficult to solve even with
> a lot of money, but that could not be the explanation in either of these
> cases, could it.]
About the *least* effective way to solve a problem is to have
the government allocating funds for it.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: School question for you regulars.
Date: Tue, 25 Jul 2000 15:40:58 GMT
The Gorf wrote:
> I am very interested in Computer Science, but I fear that while I will
> build strong programming skills, I might not gain the solid math I want.
With the exception of Community Colleges and Technical Institutes,
college Computer Science courses tend to be less about programming
and more mathematical than you think. There is also (usually)
nothing to prevent a Computer Science major from taking non-required
Mathematics courses such as advanced algebra. Some universities
have Mathematical Sciences, Statistics, etc. departments that cover
the more applied aspects of mathematics.
> ... My desire is to do signal analysis/processing, cryptanalys, ...
Signal processing is usually taught by the Electrical Engineering
department.
Obtain course catalogs from the colleges you're considering, and
see whether you'll be able to enroll in suitable classes.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: counter as IV?
Date: Tue, 25 Jul 2000 16:05:05 GMT
This is somewhat related to the RC4 discussion thread,
but I want to focus on one specific issue in this new thread.
Consider the scheme:
secret key K established
counter N, init 0
for each plaintext block Bi:
encrypt Bi using key (K XOR N) in algorithm E
increment N
N replaces the usual random Initialization Vector and is used
only to prevent a replay attack within the session. (A new
secret key K is securely established for each session.)
Assume the encryption E is sufficiently secure against
known-plaintext attack, for example Skipjack. The enemy
knows or can guess the values of N, but not K. There are
enough bits involved to make brute-force search infeasible.
The question I have is this: What *specific* weakness is
introduced by using a simple counter N instead of a truly
random IV? I.e., how does using a counter facilitate
cryptanalysis or some other more meddlesome attack?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question.How to avoid weak curves?
Date: Tue, 25 Jul 2000 20:35:00 GMT
DJohn37050 wrote:
> See IEEE P1363 and P1363a.
How? The Web site seems to be restricted to just committee members.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: School question for you regulars.
Date: Tue, 25 Jul 2000 20:39:45 GMT
"James Pate Williams, Jr." wrote:
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> >Note that programming skills are not the same as computer science.
> If not in a computer science cirriculum, where the heck do people
> learn programming skills?
Some CS classes teach programming, but that is not the bulk
of a CS curriculum. Actually, most experienced programmers
have learned far more about programming through reading
books, articles, and other people's code, and by thinking
about the issues, than they ever were exposed to in class.
------------------------------
From: rot26 <[EMAIL PROTECTED]>
Subject: PalmOS web browser security
Date: Thu, 27 Jul 2000 14:57:45 GMT
I don't know how many fellow sci.crypt readers own a PalmOS machine or
know much about it, but I can't help but wonder about the security of
the available web browsers for the OS that support SSL.
What it boils down to is this: is there enough entropy in the system to
create good quality session keys? And if so, is it actually being used
by the browsers?
I did have a brief look at the PalmOS spec, but couldn't find anything.
Not that I am going to do a $1m Swiss bank account money transfer on my
Palm with a mobile phone while travelling on the bus, of course (but
it'd be cool wouldn't it? ;-)
For those who are interested, one browser that supports SSL is Avantgo
available from http://avantgo.com .
rot26
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: counter as IV?
Date: 27 Jul 2000 11:29:35 -0400
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> secret key K established
> counter N, init 0
> for each plaintext block Bi:
> encrypt Bi using key (K XOR N) in algorithm E
> increment N
But itsn't it the case that key schedule setup is much slower for a
lot of ciphers than encryption of one block? Performance would be
terrible.
--
"If my Eternal Life Device does not give immortality, then the entire
Bible is a joke." -- Alex Chiu
http://www.alexchiu.com/affiliates/clickthru.cgi?id=shalunov
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: counter as IV?
Date: Thu, 27 Jul 2000 09:25:57 -0600
"Douglas A. Gwyn" wrote:
<snip>
> encrypt Bi using key (K XOR N) in algorithm E
> increment N
<snip>
> The question I have is this: What *specific* weakness is
> introduced by using a simple counter N instead of a truly
> random IV? I.e., how does using a counter facilitate
> cryptanalysis or some other more meddlesome attack?
Would "related key" cryptanalysis count? I presume that you
were not thinking of using the IV to modify the key, but to
use in some more traditional mode (e.g. CBC)?
JM
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: Crypto Export Controls
Date: Thu, 27 Jul 2000 12:10:12 -0400
This is a multi-part message in MIME format.
==============2019C89DF5518BCC709AE203
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[EMAIL PROTECTED] wrote:
>
> Hi, I'd like to use crypto in software I write, and I'm worried about
> export controls (I'd like the product to be exportable).
==============2019C89DF5518BCC709AE203
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mozilla-Status2: 00000000
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 25 Jul 2000 22:29:18 -0400
From: jungle <[EMAIL PROTECTED]>
Organization: You can't force Privacy on people ...
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: alt.security.pgp,alt.privacy
Subject: US companies can export, without a license, any encryption product to
any end user in the ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
you may know this already ...
==============================
U.S. companies can export ... without a license ... any encryption product to
any end user in the 15 nations of the European Union as well as Australia,
Norway, Czech Republic, Hungary, Poland, Japan, New Zealand and Switzerland
full text at http://www.whitehouse.gov/library/hot_releases/July_17_2000_1.html
==============2019C89DF5518BCC709AE203==
------------------------------
From: Scott Long <[EMAIL PROTECTED]>
Subject: Re: MD5 algorithm questions
Date: Thu, 27 Jul 2000 09:28:37 -0700
Reply-To: [EMAIL PROTECTED]
Well thanks to everyone responding to this.. Maybe it will make more
sense if I explain exactly what it is that I'm doing.
I'm implementing a network with an amorphous (unconstrained) topology
and I am using hashing to eliminate cycles in the network. Packets are
rather blindly forwarded between connected nodes, unless the hash code
of the packet is found in a rolling queue.
Packets are UDP and, in the most common case, will have 64 bits of data
inside (plus 64 bits of hash, the hash is transmitted with the packet to
avoid recalculating it on each traversal). Therefore knowing the
approximate frequency of collisions is useful. Four bits in the packet
are dedicated to "stirring up" the hash, in case a packet turns out to
have a previously-seen code when, in fact, it is a unique packet that
should be forwarded. Combined with a one-second resolution timestamp, I
believe this system should be effective.
I realize that this is a probabilistic system and that is absolutely
acceptable. I was considering MD5 because it seems to shuffle the bits
incredibly well. Speed of algorithm is not an issue, since the hash will
only be calculated once, when the packet is first transmitted from the
initiating host.
I realize that it seems wasteful to transmit a 64-bit hash with some
64-bit data. Without going into too much detail about my algorithm, I
will say that this is still necessary for performance reasons. Anyone
who has some degree of knowledge of data structures can probably figure
out why...
Thank you everyone.
Scott
------------------------------
From: Matthew S <[EMAIL PROTECTED]>
Subject: Enigma
Date: Thu, 27 Jul 2000 17:37:31 -0500
Hi,
Does anyone know where I can get source code or PC executable for an
Enigma machine? I have only found source for a 1 rotor machine when I'd
like 3 or 4.
As a learning exercise I intend to write code to break Enigma.
Thanks,
..matthew
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Enigma
Date: 27 Jul 2000 16:47:31 GMT
Matthew S <[EMAIL PROTECTED]> wrote:
> Does anyone know where I can get source code or PC executable for an
> Enigma machine? I have only found source for a 1 rotor machine when I'd
> like 3 or 4.
>
> As a learning exercise I intend to write code to break Enigma.
In that case, I recommend that you write the code to implement the
Enigma as part of your exercise. It's not exactly going to be
difficult, now, is it?
As an aside, I do find that I gain a better understanding of a cipher
after having implemented it, even after having gone through the
definition carefully.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: JavaCard vs Multos security
Date: Thu, 27 Jul 2000 16:38:45 GMT
Can anyone comment on the security aspects of Javacard vs Multos.
Javacard uses standard Java security
Multos is a special OS heavily based on ENcryption technology..
The details of the security model are unkown ....
Any references would help greatly
Thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: ganges <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Date: Thu, 27 Jul 2000 16:38:25 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Paul Rubin wrote:
> > So in general, one should not use cryptography software to secure
> > highly sensitive data. It's simply too easy for keys to escape by
> > accident or on purpose. If the software crashes and leaves a core
> > dump, the keys may be in it. If the computer gets a virus, that
might
> > scan memory and find the keys. And so on. Sensitive data should be
> > secured by hardware.
>
> But if you can steal the disc, you can steal the hardware with the
> keys, too ? I don't understand the advantage here.
>
Not true, with many hardware encryption boxes, the casing is tamper
proof. So, if the box is pried open, or disturbed in any way the
encryption keys are automatically deleted.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: ganges <[EMAIL PROTECTED]>
Subject: Gretacoder Hardware Encryption
Date: Thu, 27 Jul 2000 16:47:59 GMT
Does anyone have any available information on the GC 650 link encryptor
manufactured by Gretacoder?
Cheers
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: MD5 algorithm questions
Date: Thu, 27 Jul 2000 11:07:38 -0600
Scott Long wrote:
<snip>
> Packets are UDP and, in the most common case, will have 64 bits of data
> inside (plus 64 bits of hash, the hash is transmitted with the packet to
> avoid recalculating it on each traversal). Therefore knowing the
> approximate frequency of collisions is useful. Four bits in the packet
> are dedicated to "stirring up" the hash, in case a packet turns out to
> have a previously-seen code when, in fact, it is a unique packet that
> should be forwarded. Combined with a one-second resolution timestamp, I
> believe this system should be effective.
1. I suppose the hash is of the entire packet? Or just the 64 bits
of data?
2. Doesn't every packet have a CRC or something already? (Not 64
bits, of course.)
3. In your envisioned algorithm, if the 64 bit hash collides, then
the packet is discarded? Or do you keep more info to check?
JM
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 27 Jul 2000 18:17:50 +0100
[EMAIL PROTECTED] (Mark Wooding) writes:
> > I'm using a cryptography module that supports an encryption mode
> > called Mech_DES3mCBCMACi64pPKCS5.
>
> It simply applies PKCS5 padding, does CBC encryption with the IV you
> gave it (or makes one up for you if you didn't give it an IV) and then
> gives you back the last 64-bit block of the ciphertext.
>
> Some authorities recommend further encrypting the CBC-MAC result. The
> module you're trying to use doesn't do that.
> > Does anyone know if there's a standard way to do this? I don't think
> > the PKCS standards say anything about it.
In PKCS#11 terms it's CKM_DES3_MAC_GENERAL (with the "general" paramter
being 8 (8-bytes = 64-bits)). It's a signature mode, not an encryption mode.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Thu, 27 Jul 2000 13:27:57 -0400
Bob Silverman wrote:
>
> In article <[EMAIL PROTECTED]>,
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> > Bob Silverman wrote:
> > >
>
> <snip>
>
> > Hmmm, I was playing around with Open-SLL prime number generator.
> > Generating a 2048 bit strong pseudo-prime (you want a strong prime p =
> > 2q + 1
> > in DH for different reasons,
>
> You can't possibly mean this. Why would you want a pseudo-prime????
Sorry, I meant to say a "probable prime".
Thanks for the remark.
Anton
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: MD5 algorithm questions
Date: Thu, 27 Jul 2000 18:29:54 +0100
On Thu, 27 Jul 2000, Scott Long wrote:
> I'm implementing a network with an amorphous (unconstrained) topology
> and I am using hashing to eliminate cycles in the network. Packets are
> rather blindly forwarded between connected nodes, unless the hash code
> of the packet is found in a rolling queue.
aha; what you need, then, is a unique identifier for every packet. one
option, certainly, is to hash the data, but there are other options.
if you have a unique identifier for every node, then if nodes keep count
of how many packets they've sent, (node-id,packet-number) is unique for
every packet. alternatively, just count how many you've sent this second,
and (node-id,time,packet-number) is unique. using this approach (which is
nice because it survives node crashes well), your fields are:
node id - 4 bytes - use an IP number; if you're crossing firewalls which
use NAT, you will need to be cleverer here
time - 2 bytes - use the low bits of the second clock; wraps round every
2^16 = 65536 s ~= 18 hours, so as long as your packets don't live this
long, you're ok
count - 2 bytes - allows 2^16 = 64 k packets per second; you suggest 8
bytes of data per packet, plus 20 for the IP header and 20 for the UPD
header, which is 48 bytes, makes 3 MB/s, which, unless you're on a fat
pipe, is plenty (btw, i'd suggest trying hard to get your data-per-packet
up: you're sending 8 bytes of data in a 48 byte packet, which means you're
wasting 80% of your data on headers - ouch).
for a 64-bit packet UID which is guaranteed to be unique. so, have i got
anything wrong?
the only issue, i think, is possible contention for the counter by
multiple threads on the node; this can be avoided by giving each thread a
counter, where the high N bits are a counter ID and the low 16-N bits are
a count; with N=4 you get 16 threads simultaneously, N=8 gives you 256. if
you need still more, share a counter between multiple threads; you still
get contention, but less of it. of course, if you're not multithreading,
you can ignore this.
> I realize that it seems wasteful to transmit a 64-bit hash with some
> 64-bit data. Without going into too much detail about my algorithm, I
> will say that this is still necessary for performance reasons. Anyone
> who has some degree of knowledge of data structures can probably
> figure out why...
no idea!
i confronted this problem - duplicate-checking in unstructured networks -
myself a while ago; the key problem was the time needed to look up the UID
in the seen-list (especially as we were doing it with multiple threads, so
we needed to do it thread-safely, which was a nightmare). in the end, my
associate and i decided it was easier to restructure the network to avoid
duplication that to solve it!
tom
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Thu, 27 Jul 2000 13:37:41 -0400
"David A. Wagner" wrote:
>
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> > So a provable way of extending the output of a secure hash
> > function h is to simply split the input m into two equal halves
> > am and bm (such that m = am || bm, || is concatenation) and output
> > h(am) || h(bm).
>
> Be careful. This can't make collisions any easier to find, but the
> `secrecy properties' get worse, because the construction can make
> dictionary attacks easier.
>
> (Each half of the message might have only half the entropy of the total
> message, so the complexity of dictionary attacks might go down from 2^n
> to 2^{n/2}, or something like that.)
Yes, of course, the extended function will be just as secure as the one
that it uses. So if you are using a 160-bit hash function,
transforming
it into a 320-bit hash functions, the extended hash function security
relies on the 160-bit hash function only (so you take that into account
for dictionary attacks and the birthday paradox and so on).
I would think that to get 320-bit security, you'd have to redesign the
hash function from scratch. (?)
Maybe a more flexible hash function (similar to Blowifish, RC4/5 are
compared to DES in the block cipher world), who's *internals* can be
easily modified to produce different size outputs, would be a good idea?
Anton
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Thu, 27 Jul 2000 10:29:16 -0700
> >The protocols used for email (SMTP and POP3) are NOT encrypted.
> >Thus your ISP can read all your emails.
> >
> >Outlook downloads these messages in clear, and then encrypts them
> >before writing them to disk.
> Not being an Outlook user now I know why not to use it. Other than the
ease
> that "worms" have attacked it.
Actually it's a problem with the protocols themselves, the same protocols
that EVERYONE uses. Whether you choose AOL, Netscape, OE, PINE, mailtool,
mail, or even sending and receiving the data yourself, you still use the
same SMTP protocol, with the same lack of security, and generally you will
use the same POP3 protocol with the same lack of security. Sorry.
Joe
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: Thu, 27 Jul 2000 13:42:01 -0400
Scott Fluhrer wrote:
>
> Anton Stiglic <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Tony T. Warnock" wrote:
> >
> > > > then you need to show that the gap between a prime p and next prime
> (the
> > > > number of loop iterations) is bounded by a polynomial in log(p). Now,
> > > > looking at prime gap tables, that appears to be very likely, but I
> didn't
> > > > anyone has proven that.
> > > >
> > > > If that has been proven, could someone enlighten me? If you are
> thinking of
> > > > a different next-prime algorithm, could you enlighten me?
> > > >
> > >
> > > One does have the theorem that there is a prime between P(k) and 2P(k),
> also
> > > there is a prime between P and P**c for (I think) any c>1+epsilon.
> >
> > Even better: there is a prime between p and p + 1/5p, for primes p > 9.
> > and there is a prime between p and p + 1/13p for primes p > 11
> Huh? Setting p=13, there is a prime between 13 and 14?
>
> (Actually, that should be for integers > 117. In addition, the website
> listed below appears to claim it's true for > the 118th prime number (647),
> which is correct, but not the lowest possible bound).
>
> > and even tighter gaps for bigger n.
> > See
> > http://www.utm.edu/research/primes/notes/gaps.html
> >
> > but these gaps are polynomial in p, not log(p).
> >
> > Define g(p) to be the number of composites between p and the next prime.
> > There are interesting results and conjectures on bounds of g(p)/log(p).
> > Again, see
> > http://www.utm.edu/research/primes/notes/gaps.html
> > for example.
> Interesting site. Thanks. Still doesn't invalidate my claim (that there is
> no proven bound on g(p) which is polynomial in log(p)).
No, it doesn't invalidate your claim, it just says that we don't know
yet! :)
Anton
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Thu, 27 Jul 2000 12:33:06 -0500
diana wrote:
>
> I'm wondering if elliptic curves is the next trend in encryption.... is it?
> or can anyone think of something else?
It's the next trend for production and industry. This is from an
economic standpoint. For academics it's pretty old stuff. For newer
ideas check out NTRU and the latest CRYPTO conference papers.
ECC uses fewer resources than RSA, so it's cheaper to implement in
hardware. The keys are also much smaller for the same strength, so
it uses less bandwidth. For many commercial applications this is
important. For many other applications, it isn't important at all.
So the crypto to use for any particular situation depends on a lot
of external factors, not just the math used.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Diffie's New directions in Cryptography
Date: Thu, 27 Jul 2000 13:47:51 -0400
Anton Stiglic wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> > From where will I get an online copy of the original "New directions
> > in cryptography" by Diffie and Hellmann?
> >
> > Here is a description of the paper
> > ?New directions in cryptography?,
> > IEEE Transactions on Information Theory, 22
> > (1976), the IEEE 22nd Annual Symposium on Foun-dations
> > of Computer Science,
>
> I doubt you will find a 1976 paper as such on the web, unless someone
> re-wrote it or scaned it.
> Your best bet would be to find a library that has the IEEE FOCS
> series books.
>
> For example, Springer Lecture Notes in Computer Science has a CD
> of scanned versions of all the papers from 1981 - 1997.
And furthermore, ACM digital library (which has a *huge* collection of
articles, from different proceedings and magazines), seem to only have
online copies of papers dated > 1985.
So as a general rule, for papers dated < 1980, you might be out of
luck.
Anton
------------------------------
** 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
******************************
