Cryptography-Digest Digest #933, Volume #10 Thu, 20 Jan 00 00:13:01 EST
Contents:
Re: Predicting Graphs. (Guy Macon)
newbie help (elliptic)
Re: What about the Satanic Seven??? ("r.e.s.")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (DJohn37050)
ANN: ECBackup 1.1 - archiver with strong-security, based on open key technology
(ECC) ("Andre N Belokon")
Encryption Speeds of Stream Ciphers Implemented on Hardware ("Duncan")
Re: New Crypto Regulations ("Trevor Jackson, III")
Re: McDonald's claims Nobel peace fries ("Trevor Jackson, III")
Re: Java's RSA implimentation (Paul Schlyter)
Re: Java's RSA implimentation (Paul Schlyter)
Re: RSA survey ("Trevor Jackson, III")
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: RSA survey (NFN NMI L.)
Re: Forward secrecy for public key encryption (new proposal, long) (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Predicting Graphs.
Date: 19 Jan 2000 21:02:13 EST
In article <865fve$t2k$[EMAIL PROTECTED]>, [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
>
>Come on, somebody, answer my question!
>
O.K. Happy now?
------------------------------
From: elliptic <[EMAIL PROTECTED]>
Subject: newbie help
Date: Thu, 20 Jan 2000 01:57:55 GMT
I need some help for implementing strong encryption in Perl(MacPerl).
Onyone wann give me a hand???
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: What about the Satanic Seven???
Date: Wed, 19 Jan 2000 18:22:16 -0800
Thanks for the link.
What does it mean for simply discussing, say, ARC4's algorithm?
It's still not clear to me whether, for US citizens, public-domain
"hard crypto" source code or algorithms may be posted without
restriction in NGs. Does Paragraph 15 imply that it's OK to do so
as long as one somehow informs BXA concurrently with every posting?!
--
r.e.s.
[EMAIL PROTECTED]
"David Crick" <[EMAIL PROTECTED]> wrote ...
: "John E. Kuslich" wrote:
: >
: > How do you stop those people in the seven bad nations from downloading
: > your stuff??? Do you have to have your server attempt to filter this
: > stuff?
:
: See http://207.96.11.93/Encryption/qanda.htm for answers to these
: and many other questions :)
:
: David.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 20 Jan 2000 02:24:15 GMT
In the Montgomery talk, he only had each machine talking to its N,S, E, and W
neighbors. And each machine had only a part of the matrix. A lot was over my
head.
Don Johnson
------------------------------
From: "Andre N Belokon" <[EMAIL PROTECTED]>
Subject: ANN: ECBackup 1.1 - archiver with strong-security, based on open key
technology (ECC)
Date: Thu, 20 Jan 2000 04:34:27 +0200
Reply-To: "Andre N Belokon" <[EMAIL PROTECTED]>
Hi All !
In new version add BWT-based compression method (like bzip2). Improved
compression speed. For more detail visit to http://softlab.od.ua
ECBackup 1.1
is a archiver with strong-security, based on open key technology.
We used elliptic curves for open key and Blowfish for cipher. This has
allow to get the greater security in contrast with RSA-based systems under
the smaller length of key and more high speed. Key length up to 1900 bits
(equivalent to more than 50,000 bits RSA-key) - it's a "paranoic"
level of security !
Package contains three programs - keymaker, archiver and viewer. Keymaker
create public key for your private password. Archiver uses this public
key (not private password) for cryptooperation. With viewer you can view
and extract files from archive, but for this you are to know private
password.
Open key technology guarantees impossibility of recovering a secret key
on an known open key.
Also you are to use this program for the safe exchange (like PGP) any
types of files over internet or other facility to communications.
WBR Andre N Belokon
http://softlab.od.ua
mailto:[EMAIL PROTECTED]
------------------------------
From: "Duncan" <[EMAIL PROTECTED]>
Subject: Encryption Speeds of Stream Ciphers Implemented on Hardware
Date: Wed, 19 Jan 2000 21:40:48 -0500
I'm looking for the encryption speeds of stream ciphers implemented on
chips. Bruce Schneier's Applied Cryptography 2/e (Table 17.3) gives the
speeds of A5, PIKE, RC4 and SEAL on a 33MHz 486SX. Is there any information
about the speeds of stream ciphers on hardware?
------------------------------
Date: Wed, 19 Jan 2000 21:55:32 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
JPeschel wrote:
> "Douglas A. Gwyn" [EMAIL PROTECTED] writes:
>
> >JPeschel wrote:
> >> "Douglas A. Gwyn" [EMAIL PROTECTED] writes:
> >> >To the extent that people think a democracy is desirable,
> >> >the US ideal of government that promotes individual rights
> >> >has already died.
> >> This is, of course, pessimistic nonsense.
> >
> >No, it isn't. A democracy is merely a slowed-down version of mob rule.
> >Mobs aren't known for watching out for individual rights.
>
> Wrong again.
>
> Not only was your last assertion wrongheaded,
> this latest bit of sophistry, despite
> possessing a minutiae of merit as nihilistic
> black humor, is elitist nonsense.
Tell that to the Greek legislators (Atheniams I believe) who declared it
monstrous that they could not pass any law they wished. Democracy in action
is a terrifying sight.
------------------------------
Date: Wed, 19 Jan 2000 22:07:02 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: McDonald's claims Nobel peace fries
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>
> >Anyway, it is also counterproductive to try to lend so-called
> >"humanitarian aid" to a country whose leadership we oppose.
> >The more aid we send, the more comfortable (relatively) the
> >population is, so the more they support their leaders (who
> >get the credit for any improvements). If we really want the
> >population to rise up and overthrow, for example, Sadaam
> >Hussein, we should make sure that they feel miserable under
> >his rule. In the long run, such a policy reduces death and
> >suffering. (A major problem with US foreign policy is that
> >nobody is thinking in terms of principles or the long run.)
>
> You are wrong. Comfortable populations have a strong
> historical trend of turning towards democracy, and
> impovershed opulations have a strong historical trend
> of turning towards dictatorships.
>
I disagree. The greatest threat of developing nations is the tide of rising
expectations. As people become aware of the potential fruit of development their
appetite for those benefits grows much more quickly than the capacity of the economy
to satisfy them. The result is expectations that are not met, and social chaos.
The analogue in US politics is the influence "the economy" has upon the elections.
It appears to be direct and quite strong. How strong would it be here if the issue
weren't college educations and second televisions, but feeding kids under 5 enough
protein that their mental development is not impaired. I suspect it would have even
more influence that it does now.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Java's RSA implimentation
Date: 20 Jan 2000 02:24:43 +0100
In article <[EMAIL PROTECTED]>, larry <[EMAIL PROTECTED]> wrote:
> One big concern I have is that Java bignums (BigInteger objects) are
> "immutable". They can't be altered once created. If you do something
> like "A=A+1", a new object is created (with the new value of A), and
> the old object (with the old value of A) becomes garbage, but remains
> lying around in memory until the garbage collector decides to recycle
> it (i.e. until who knows when).
> So the problem is, private key material kept in BigIntegers can't be
> wiped out when no longer needed. It sits in memory for an
> undetermined and potentially long time. Long enough to make being
> swapped out to a pagefile rather likely (or long enough for a memory
> sniffer to find it). If someone can get that pagefile, they can get
> the private key.
> If I need to have private key material in memory, I prefer it to be
> for the shortest duration of time possible. If it's in a Java
> BigInteger, I have no way to restrict how long it stays in memory.
What would happen if you instead of A=A+1 tried e.g. B=A+1; A=0; ???
Yep, this can be a problem. But what you want isn't controlled
garbage collection (even if the discarded A is collected by the
garbage collector, it may sitll be lying around somewhere in memory
until actually overwirtten). but a way to overwrite memory containing
sensitive info once it's no longer needed. Which indeed becomes a
hard problem, even outside Java, once you're running an OS with
virtual memory: your sensitive data may then be lying around
in the swap file on disk even when your program has finished
executing!
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Java's RSA implimentation
Date: 20 Jan 2000 02:25:11 +0100
In article <865cnf$orj$[EMAIL PROTECTED]>,
Bayard Randel <[EMAIL PROTECTED]> wrote:
> larry <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>>
>> One big concern I have is that Java bignums (BigInteger objects) are
>> "immutable". They can't be altered once created. If you do something
>> like "A=A+1", a new object is created (with the new value of A), and
>> the old object (with the old value of A) becomes garbage, but remains
>> lying around in memory until the garbage collector decides to recycle
>> it (i.e. until who knows when).
>> So the problem is, private key material kept in BigIntegers can't be
>> wiped out when no longer needed. It sits in memory for an
>> undetermined and potentially long time. Long enough to make being
>> swapped out to a pagefile rather likely (or long enough for a memory
>> sniffer to find it). If someone can get that pagefile, they can get
>> the private key.
>> If I need to have private key material in memory, I prefer it to be
>> for the shortest duration of time possible. If it's in a Java
>> BigInteger, I have no way to restrict how long it stays in memory.
>
> Is there not a method that can be applied for garbage collection/flushing
> buffers?
That won't solce the problem: memory contents aren't automatically
erased just becuase buffers are flushed. What's needed is a way to
actually overwrite sensitive memory when it's no longer needed.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Date: Wed, 19 Jan 2000 22:11:34 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA survey
Bob Silverman wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (NFN NMI L.) wrote:
> > <<A 1024 bit modulus is more than enough.>>
> >
> > When 512-bit moduli can be cracked by large corporations with enough
> funds?
> > Sorry. I want strength that will keep messages secure until I'm in
> the cold,
> > hard ground. Better too much than too little. Just you wait.
>
> It never ceases to amaze me how much nonsense gets spouted by people
> who are totally ignorant of the subject they are discussing.
>
> Do you have any idea of how much harder 1024 bits is than 512?
> Do you know the SPACE requirements for 512 bits? Do you know the SPACE
> requirements for 1024 bits?
>
> No? They how can you make ANY statement regarding whether 1024 bits
> is sufficiently secure???
Are the current best time/space requirements particularly strong? I.e., is
there some reason to believe the current scaling figures are the best
possible?
If there is no lower bound on the resource requirements then the
possibility of serious improvements in scaling cannot be ignored.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Wed, 19 Jan 2000 19:17:15 -0800
"CLSV" <[EMAIL PROTECTED]> wrote ...
: "r.e.s." wrote:
:
: > [ repost of my 1/15/00 "Changing ARC4's State-Space Size" ]
:
: [...]
:
: > So I would like to consider the following encryption method:
: >
: > (1) A state vector of M distinct symbols is managed by mod M pointer
: > arithmetic, using the same logic as ARC4's stream generator.
: > (2) Modular addition is used as the combiner, instead of ARC4's XOR.
: > (3) The method for initializing the state vector is not specified,
:
: Ah, I has the same idea about using RC4 as you pointed out.
:
: [...]
:
: > To get a "hand cipher", choose M as a small multiple of the size N
: > of the plaintext alphabet, e.g. M=m*N, and use addition mod N as the
: > combiner. For example, we can take M=52 and use addition mod 26 for
: > the combiner, similar to Solitaire.
:
: > The case M=52 is tedious but not difficult to implement either with
:
: One of the weak points of this cipher is that it is not optimized
: for hand use. Maybe it could be changed by subsituting mod 52 arithmetic
: with some simpler operations that could be executed with help of
: the deck of cards. But otherwise I still think it is a very strong
: cipher especially for small messages.
:
: Regards,
:
: CLSV
Another thing I've tried, with very good success for speed, is taking
M=40 instead of 52, using a deck of 40 cards (A-10 in four suits) plus
2 jokers. "Digitize" the plaintext, converting from letters to decimals,
say with a straddling-checkerboard), and then use addition mod 10 (very
easy by hand) to encipher the digits using the ARC4(M=40) digit stream.
Of course such a reduction of state makes it more important to know
ARC4's performance with decreasing M.
A mitigating factor for the decimal scheme is that at least another
22 bits come from the substitution table for digitizing the plaintext,
giving a total of at least 180 bits of entropy.
A similar mod40/mod10 scheme can be applied to MIRDEK and Solitaire.
Paul says the state space for MIRDEK is (26!)^2, as I recall, but it
really looks like 52! to me. If he's right though, reducing to (20!)^2
may not be acceptable, while 40! (159 bits) might be. A mitigating
factor favoring the decimal scheme is that at least another 22 bits
come from digitizing the plaintext, for a total of at least 180 bits
of entropy.
(My hands-on experience with MIRDEK is that it's by far the easiest &
fastest card-cipher I've tried -- it's just that, like Solitaire, its
cycle properties are mostly unknown. That was my main motivation for
thinking about extending ARC4, which I thought was regarded as one of
the most secure stream ciphers around.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Thu, 20 Jan 2000 03:33:43 GMT
In article <864ujc$fmo$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <8637ni$7ii$[EMAIL PROTECTED]>,
> Greg <[EMAIL PROTECTED]> wrote:
> > In article <862sm9$vdb$[EMAIL PROTECTED]>,
>
> <snip>
>
> >
> > I concur. But for the same reason I would never use a random
> > EC curve
>
> Huh? This is the first time I have *ever* seen anyone suggest that
> a random curve is undesirable. In fact most experts I know suggest
> that random curves are more desirable than structured curves precisely
> because they have less structure to attack and exploit.
>
> Please tell us why you have this belief.
Perhaps I leave myself open to a known attack of a well studied
curve, but it seems to me that this is prefered to leaving one's
self open to a weakness in a random curve. Does this make sense?
> > I could not see using a random prime.
>
> Again, why? Please tell us what you think is wrong with
> randomly chosen primes.
Well, I mentioned in another thread that I am not sold on primes
that are so large that they are tested and then at some point
simply assumed to be prime. Some have told me that this does not
weaken the cryptosystem, but I have always wondered why that would
be if the strength depended on primes to begin with.
Again, I believe a well studied cryptosystem and all of its
components are superior to anything randomly selected on the
fly- the latter seems like a crap shoot. If anything is
randomly selected, it should be just as equally capable
of being a strong candidate as any other. With primes,
you do not have this. With integers used for ECC private keys,
you get exactly that- except in a few cases, like 0, 1, and n-1,
which are too easy not to avoid.
IMHO, every cryptosystem today has its own small element
of unknown. I simply have more confidence in one set of unknowns
than I do in others. I really can't sleep at night knowing that
my data is hanging from a crap shoot. It just does not work
for me.
> > RSA relies on
> > this approach since primes are not "studied" ahead of use.
>
> I can't understand what you are saying here. What does it mean to
> "study" a prime? Also, what is the antecedent of the word "this"
> in the phrase "this approach"?
As I understand it, RSA randomly generates prime candidates
to use for private keys. You cannot take a lot of time and
a lot of people to study a pair of primes to ensure they are
really primes like you can an elliptic curve, because to do
so exposes the keys. But again, others would say that this
is not important- that a number does not have to be a pure
prime. If you could explain that to me, I would be all ears.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: RSA survey
Date: 20 Jan 2000 05:01:43 GMT
<<By making million
bit RSA keys you just appear silly.>>
8192. That's several orders of magnitude different. Moron. "Quite some time
now" is not a century.
S. "Crackpots would be funny..." L.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Forward secrecy for public key encryption (new proposal, long)
Date: 19 Jan 2000 21:00:42 -0800
Allow me to sketch the bare bones of a possible attack direction, and
I hope you will tell me whether it works or not.
If I understand correctly, we have
y_t = F(R,t)^{2s} = alpha^{x_t} mod m
where F() behaves pseudorandomly and F,R,t,s,alpha,m are known.
Suppose we recover the private key at time t, so that x_t becomes known.
If we set a = F(r,t)^s mod m and b = alpha^{x_t/2} mod m, we will obtain
the relation
(*) a^2 = b^2 mod m.
When x_t is even -- half of the time -- we can compute a and b from the
known quantities and thus form the value gcd(a-b,m).
Now *if* a and b behave as though there were chosen randomly from the
set of values satisfying (*) -- and I have no idea whether this will
happen or not -- then gcd(a-b,m) would reveal a non-trivial factor of m
with high probability. Of course, if we could factor m using these
tricks, we could break the forward secrecy properties and recover x_{t'}
for t' < t, which is supposed to be forbidden.
The catch is, all this might not work. This handwaving is certainly
not a proof! I could imagine that the way the parameters are chosen
might ensure that relation (*) never reveals a non-trivial factor of
m (for instance, if for some reason we always have a = b), and I can't
see off the top of my head whether this is an issue or not.
What do you think? Am I off my rocker? Is there a chance this might
work, or does the choice of parameters prevent the information leakage?
------------------------------
** 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
******************************
