Cryptography-Digest Digest #964, Volume #13 Wed, 21 Mar 01 17:13:01 EST
Contents:
Re: A future supercomputer ("JCA")
Re: Idea ("Simon Johnson")
Re: Defining a cryptosystem as "broken" ("Joseph Ashwood")
Re: What happens when RSA keys don't use primes? ("Joseph Ashwood")
Re: What happens when RSA keys don't use primes? ("Joseph Ashwood")
Applied Cryptography Source Disk ("Stevan Gostojic")
Re: An extremely difficult (possibly original) cryptogram (daniel mcgrath)
Re: Most secure way to add passphrase verification to "CipherSaber" ("John L. Allen")
Re: Popular Mechanics article on NSA (John Savard)
Re: redodancy (John Savard)
Re: What happens when RSA keys don't use primes? (Doug Stell)
Re: A future supercomputer (Anne & Lynn Wheeler)
SSL question (Patrick Knight)
Re: I was so so right about PGP ... so right when I started writing (Frank Gerlach)
Re: NSA in the news on CNN (Doug Stell)
Security of Triple-DES ("Arne Baltin")
Re: SSL question (David Schwartz)
Re: SSL question (Paul Rubin)
Re: looking for "Crowds" ("thomas kuehne")
Re: RC4 test vectors after gigabyte output?. (Ian Goldberg)
Re: [OT] Java (Frank Gerlach)
Re: Advice on storing private keys (Darryl Wagoner)
Re: Idea (amateur)
----------------------------------------------------------------------------
From: "JCA" <[EMAIL PROTECTED]>
Subject: Re: A future supercomputer
Date: Wed, 21 Mar 2001 11:59:00 -0800
In article <[EMAIL PROTECTED]>, "Mok-Kong Shen"
<[EMAIL PROTECTED]> wrote:
> Computing power is ONE of the fundamental requirements. If everything
> else is solved in theory, without the computing power to do that is
> futile, like one understands perfectly how a rocket works but without
> the required fuel. With more computing power, one can try algorithms
> that would otherwise be impossible. (See e.g. simulation of nuclear
> explosions, which was why the ASCIs were built.) M. K. Shen
Let me turn your analogy upside down - in order to actually launch a
rocket one must be able to build a fuselage first. But just having this skill
without knowing the physical principles on which rockets are based will
take one nowhere fast.
The same with raw computing power and the human brain. Humongous
horsepower is probably a relatively minor part of the solution, and hence
my belief that ASCI and Blue Gene are not likely to change things at all in
this respect.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Wed, 21 Mar 2001 20:23:24 -0800
John Joseph Trammell <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 19 Mar 2001 06:58:53 GMT, SCOTT19U.ZIP_GUY wrote:
> > Time is to precious wasting it using a spell checker.
>
> Your time is more precious than mine, then? I'd say that
> time is too precious to waste writing unintelligible
> scribblings, but hey, maybe that's just me.
But then I'd argue that there is sufficient redundancy in his English for
you to make sense, very quickly, of his far from unintelligible text and
your just being a little silly.
Simon.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Defining a cryptosystem as "broken"
Date: Wed, 21 Mar 2001 12:04:44 -0800
I think we agree on that, no there's no way we can be certain of an
attackers compute power (or analytic power for that matter). So it will take
conservative estimation, buffer zones, whatever you want to call it, and we
can still be bitten by it. However with cryptography it's fairly well known
that all we can do is fix the odds in our favor, just as we assume that no
one will guess a 128-bit number on the first try. I think we agree though.
Joe
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Joseph Ashwood wrote:
> >
> > Of course the user will have problems. That's where well paid
cryptanalysts
> > come in :) I think I can say safely that we all agree that most systems
> > simply haven't been designed with security in mind (I point to MS
<insert
> > name here/> as an example). The difference is that I did not say this is
a
> > countable set, only you have made that assumption about what I have
said.
> > What I have said is that a threat/attack model needs to be made, I have
> > never said that it is an easy problem, I have never said that the set of
all
> > models is countable (although because I expect that they will all be
finite
> > in length they are not only countable but finite), I have only said that
one
> > needs to be constructed for the situation. Choosing the right model
should
> > be done for the user, in fact the programmer will fix the threat/attack
> > model whether he/she knows it or not. The only decision about the
> > threat/attack model that the user makes is which programs to use. I am
not
> > discussing an arbitrary change it at run time impossibility, I am
discussing
> > exactly what I have done for a period of years now, define threat/attack
> > models for things, make sure at design-time (and through later review)
that
> > it meets that model. That is a solvable problem, the changing threat
models
> > based on user input is not (although a selection from a small set of
them
> > may be possible, see SSL as an example).
>
> There is no question that your project/goal is very
> laudable/justified and one should attempt that as far
> as one can. My point is that, even after one has achieved
> that goal, there yet remains certain essential uncertainty
> that cannot be avoided, namely which model to choose
> in a concrete application. A hypothetical analogy: Suppose
> medicine could classify all diseases and give for each an
> effective treatment but the diagnostic techniques remain
> imperfect, i.e. a doctor cannot determine a patient's
> trouble with 100% accuracy, then there still can't be
> absolute guarantee that all people will be healed. I
> already mentioned as example the estimation of the
> computing resources of the opponent. In most cases one
> never knows that for sure. One could be conservative and
> think (guess) of some sort of upper bound. But that's a
> subjective matter, isn't it?
>
> M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: Wed, 21 Mar 2001 12:08:44 -0800
"Mxsmanic" <[EMAIL PROTECTED]> wrote in message
news:bv7u6.25457$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:3u6u6.98761$[EMAIL PROTECTED]...
>
> > No it means you should use a mathematically sound
> > probable prime generator such that the probability
> > of failure is astronomically small. (i.e Rabin-Miller)
>
> And if it fails, how will you know?
Simply put, if it fails you know because it doesn't work (with high
probability). Insuring yourself against the failure of the system is also
rather easy (assuming that for some strange reason it works, but one of the
2 factors is composite), just choose your RSA key such that it is 20% longer
than you believe is necessray for security, this will make the factoring at
least as difficult (under modern algorithms). So make your RSA keys larger
than you think they need to be, and perform a test encrypt/decrypt.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: Wed, 21 Mar 2001 12:10:35 -0800
There is a fair probability that there will exist at least 3 values that
will encrypt/decrypt correctly, the first two are 0 and 1 (they will always
work), the other(s) can vary widely. However your odds of finding that
collision are steeper than the odds of guessing 128-bit key.
Joe
"Mxsmanic" <[EMAIL PROTECTED]> wrote in message
news:au7u6.35406$[EMAIL PROTECTED]...
> "Paul Thomas" <[EMAIL PROTECTED]> wrote in message
> news:99a8nc$51e$[EMAIL PROTECTED]...
>
> > the encryption / decryption will break, for example
>
> Will it break for _every_ encryption and decryption, or only for certain
> plaintexts or ciphertexts? That is, can one safely assume that a key
> pair derived from non-prime numbers will immediately and unconditionally
> make itself obvious by breaking any encryption or decryption, or will
> some encryptions and decryptions work, even with the bad numbers? The
> former isn't much of a problem; the latter is much more serious.
>
>
------------------------------
From: "Stevan Gostojic" <[EMAIL PROTECTED]>
Subject: Applied Cryptography Source Disk
Date: Wed, 21 Mar 2001 21:09:02 +0100
I was wondering if it is possible to find the source code from the book the
on the Web?
--
[EMAIL PROTECTED]
Smrt fasizmu - Sloboda narodu !
------------------------------
From: [EMAIL PROTECTED] (daniel mcgrath)
Crossposted-To: rec.puzzles
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Wed, 21 Mar 2001 20:32:13 GMT
On Mon, 19 Mar 2001 20:37:50 GMT, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>daniel mcgrath wrote:
>> So have you figured out the system? (I think Douglas has it.)
>
>Actually I got close enough to convince myself that the
>rest wouldn't be too hard, then turned to other more
>pressing matters.
How did you get "general" and "however"?
==================================================
daniel g. mcgrath
a subscriber to _word ways: the journal of recreational linguistics_
http://www.wordways.com/
------------------------------
From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Wed, 21 Mar 2001 20:23:51 GMT
Benjamin Goldberg wrote:
> John L. Allen wrote:
> >
> > I was thinking about adding some rudimentary passphrase (Key)
> > verification check capability to the CipherSaber protocol (see
> > http://ciphersaber.gurus.com/). So, among the following choices, Which
> > of these message streams is most secure as a means of providing a way
> > for the decryptor to verify the correctness of the decryption Key
> > without giving an attacker useful info:
> >
> > 0. IV, E(msg) # This is the current
> > CipherSaber protocol
> > 1. IV, E(IV), E(msg) # bad: "known plaintext"
> > 2. IV, E(E(IV)), E(msg)
> > 3. IV, E(E(msg{1..10})), E(msg) # bad: "known plaintext"
> > 4. IV, E(E(E(msg{1..10}))), E(msg)
> > 5. IV, H(msg{1..64}), E(msg)
> > 6. IV, E(H(msg{1..64})), E(msg)
> > 7. IV, E(Key), E(msg)
> > 8. IV, H(Key), E(msg)
> > 9. IV, E(H(Key)), E(msg)
> >
> > Where, IV is a random initialization vector.
> > E() is an encryption algorithm using key Key.
> > H() is a hash function.
> > msg is the message
> > msg{1..N} is the first N bytes of the message.
> >
> > Also, if a hash function is not available, what is the best way then?
> >
> > I lean toward #9 if a hash is available, otherwise, maybe #2 or #4.
> > Encrypting the key and sending that as in #7 doesn't _look_ too good
> > at first, but is it really that bad?
>
> All of these have their strengths and weaknesses, but here's what I
> would consider the best way:
>
> IV is a random initialization vector.
> k is the user passphrase
> pt is the plaintext message
> ct is the ciphertext message
> E(x,y) is the encryption of y using key x
> H(x) is a hash of x
> + is concatenation.
>
> Normal CipherSaber encryption is either:
> ct = IV + E( k + IV, pt )
> or:
> ct = IV + E( IV + k, pt )
> I'm not sure which, and I don't believe it matters.
It's the first, and it's supposed to matter because the key is restricted to
ascii printable chars and so avoids a class of weak keys.
> If we have a hash function (like sha) available, a better way might be:
> ct = IV + E( H(k + IV), pt + H(pt) )
> Done this way, there's no limit on the length of the user passphrase, or
> on the IV. We can check that the passphrase is correct by decrypting,
> and then comparing the hash of the actual plaintext with the appended
> hash.
Using a hash result as the key directly may unnecessarily restrict the
size of the key space, no? Also, you'd at least have to agree on the
size of the IV because you have to know how big it is to extract it
from the message stream.
And because of possible slowness of a hash function implemented
in certain intrepreted languages that CipherSaber is likely to be written in,
I wanted to avoid having to hash the entire plaintext, which was why
I was limiting it to the first 64 bytes. [BTW, you may have seen
another post of mine asking about MD2. The MD2 algorithm is pretty
simple to code, and is also RC4-like. It may be 20 times slower than
SHA, but if only 64 bytes are hashed, it would be acceptable. My
other post asked how the MD2 sbox permutation was calculated,
with the view of encoding it algorithmically instead of verbatim as
I have seen it in all the source code I have looked at. I also wanted
to know if the particular permutation mattered much for security.]
Do you have a "best" choice for passphrase verification if a hash function
is _not_ used?
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Popular Mechanics article on NSA
Date: Wed, 21 Mar 2001 20:19:35 GMT
On Wed, 21 Mar 2001 19:45:18 GMT, "Mxsmanic" <[EMAIL PROTECTED]>
wrote, in part:
>"John Savard" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> They refer to TEMPEST as an eavesdropping program.
>TEMPEST is actually an eavesdropping methodology, if I recall correctly,
>but it is often used in other ways to qualify equipment generated to
>protect against such eavesdropping, and so on.
Nope. It's a (now obsolete) codeword for the standard of resistance to
such eavesdropping that equipment manufactured for the government may
be called upon to meet.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: redodancy
Date: Wed, 21 Mar 2001 20:21:00 GMT
On Wed, 21 Mar 2001 18:19:57 +0100, "dexMilano"
<[EMAIL PROTECTED]> wrote, in part:
>Is there some simple algoritm to remove redodancy in text?
>I tried ZIP but it's too heavy.
Do you mean the algorithm in ZIP leaves files that are still too big,
or that the algorithm is too complicated for you to write a program to
do it?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: What happens when RSA keys don't use primes?
Date: Wed, 21 Mar 2001 20:38:26 GMT
On Wed, 21 Mar 2001 19:41:58 GMT, "Mxsmanic" <[EMAIL PROTECTED]>
wrote:
>"Paul Thomas" <[EMAIL PROTECTED]> wrote in message
>news:99a8nc$51e$[EMAIL PROTECTED]...
>
>> the encryption / decryption will break, for example
BTW, the test will pass for a composite p or q that is a Carmichael
number, but they are scarce. See the HAC, page 137 for a discussion of
Carmichael numers.
------------------------------
Subject: Re: A future supercomputer
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 21 Mar 2001 21:01:21 GMT
"JCA" <[EMAIL PROTECTED]> writes:
>
> Let me turn your analogy upside down - in order to actually launch a
> rocket one must be able to build a fuselage first. But just having this skill
> without knowing the physical principles on which rockets are based will
> take one nowhere fast.
>
> The same with raw computing power and the human brain. Humongous
> horsepower is probably a relatively minor part of the solution, and hence
> my belief that ASCI and Blue Gene are not likely to change things at all in
> this respect.
the counter argument is that huge amounts of excess, disposable
resources result in all sorts of new innovation.
lots of innovation is going on with computers in the past ten years
that wouldn't have happened in the 60s .... in large part because of
the lack of computer resources. It isn't just a single supercomputer
... it is having lots & lots of them (i.e. the processing power of
most PCs today are orders of magnitude larger than what was available
in the 60s and a whole lot more numerous).
however, rate of innovation isn't necessarily linearly proportional to
the huge amount excess disposalbe resources ... there is still a whole
lot of brownian motion going on.
the ASCI stuff is just a lot of normal processors all ganged together
random refs:
http://www.garlic.com/~lynn/2001c.html#86
http://www.garlic.com/~lynn/2000d.html#2
http://www.garlic.com/~lynn/2000d.html#3
http://www.garlic.com/~lynn/95.html#13
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (Patrick Knight)
Subject: SSL question
Date: Wed, 21 Mar 2001 21:07:05 +0000 (UTC)
I am reading about SSL and it seems that any transaction using SSL is
initiated by the client. For e-commerce I guess I can understand this
but SSL can be used for other purposes can't it? My need is for a server
to be able to initiate a session with a client also in order to update
data on its clients. Can SSL facilitate this?
Thanks,
PK
--
Posted from [63.115.79.131]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: I was so so right about PGP ... so right when I started writing
Date: Wed, 21 Mar 2001 23:06:20 +0100
Mxsmanic wrote:
> All their bug shows is that it's not a good idea to post one's private
> key one a Web site or community bulletin board.
I think you got something wrong. Private keys are kept private. Public
keys are made public (ie. posted on the internet).
The flaw is related to compromising the private key, which should be safe
either. If somebody can compromise the private key, he/she can most
probably also install malicious software to intercept the input to the
terminal, which runs pgp.
>
>
> <[EMAIL PROTECTED]> wrote in message
> news:99ai7o$gdk$[EMAIL PROTECTED]...
> > Cryptologists from Czech company ICZ detected serious security
> vulnerability
> > of an international magnitude
> > A bug has been found in worldwide used security format OpenPGP.
> >
> >
> > http://cryptome.org/pgp-email-flaw.htm
> >
> >
> > ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the
> Web -----
> > http://newsone.net/ -- Free reading and anonymous posting to 60,000+
> groups
> > NewsOne.Net prohibits users from posting spam. If this or other
> posts
> > made through NewsOne.Net violate posting guidelines, email
> [EMAIL PROTECTED]
> >
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: NSA in the news on CNN
Date: Wed, 21 Mar 2001 20:59:41 GMT
On Wed, 21 Mar 2001 09:50:53 GMT, "Mxsmanic" <[EMAIL PROTECTED]>
wrote:
>They have a gift shop??
Yup. NSA purchased the hotel that sits in front of Fort Meade, at the
NE corner of the interestion of Rt 32 and the B-W parkway. (They tend
to take over anything around the Fort that might be a useful location
for an adversary.) The museum and gift shop are located there. It's an
interesting place to visit. They have lots of Enigma machines and a
Bombe on display and coffee cups, shirts, ties, etc. are in the gift
shop.
------------------------------
From: "Arne Baltin" <[EMAIL PROTECTED]>
Subject: Security of Triple-DES
Date: Mon, 19 Mar 2001 16:39:20 +0100
Hi experts,
once more: how secure is the Triple-DES?
I think an attack against (single-)DES with
known plaintext of length 2^43 in 1994 succeeded.
Is there an analogy to Triple-DES?
I hope someone will answer me.
Thanks,
Arne Baltin
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: SSL question
Date: Wed, 21 Mar 2001 13:24:41 -0800
Patrick Knight wrote:
> I am reading about SSL and it seems that any transaction using SSL is
> initiated by the client. For e-commerce I guess I can understand this
> but SSL can be used for other purposes can't it? My need is for a server
> to be able to initiate a session with a client also in order to update
> data on its clients. Can SSL facilitate this?
The terms "client" and "server" are arbitrary. For purposes of SSL, the
term "client" is defined as "whatever initiates the connection" and the
term "server" is defined as "whatever accepts the connection". So, for
SSL purposes, your client is also a server.
DS
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: SSL question
Date: 21 Mar 2001 13:36:55 -0800
[EMAIL PROTECTED] (Patrick Knight) writes:
> I am reading about SSL and it seems that any transaction using SSL is
> initiated by the client. For e-commerce I guess I can understand this
> but SSL can be used for other purposes can't it? My need is for a server
> to be able to initiate a session with a client also in order to update
> data on its clients. Can SSL facilitate this?
Normally the definition of a client and a server is that the client
initiates sessions. If you're saying you want a remote site to
initiate a session on a user's PC, no problem. You install a server
program on the user's PC and a client program on the remote site.
If you're just trying to periodically update data in a browser, then
the usual way is to use the html meta tag to refresh the data once
a minute, or else do something similar with javascript. That's
completely independent of SSL and can be done with or without SSL.
------------------------------
From: "thomas kuehne" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: looking for "Crowds"
Date: Wed, 21 Mar 2001 21:37:14 -0000
Reply-To: "thomas kuehne" <[EMAIL PROTECTED]>
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Paul, thank you very much for your help.
Paul Rubin schrieb im Newsbeitrag news:[EMAIL PROTECTED]...
> "thomas kuehne" <[EMAIL PROTECTED]> writes:
> > Eric Goldstein(Human Rights Watch) worte a report about "The Internet in
the
> > Mideast and North Africa". In this 1999 report he mentions a privacy
tool
> > "Crowds" which was back than under development. Is this project still
> > existing? If so, please post me some links!
> > ("Crowds" is a extreamly bad keyword ...)
>
> Yes, see http://www.research.att.com/projects/crowds for info.
>
=====BEGIN PGP SIGNATURE=====
iEYEARECAAYFAjq5HvQACgkQW6NV6qy/x5idRACgvQlAP9kbeaOgDz0keXlm9p1L
2zIAnROnwUBN8FZoKW07HdUfSuxUj1r0
=yWKJ
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: RC4 test vectors after gigabyte output?.
Date: 21 Mar 2001 21:48:36 GMT
In article <e66u6.98711$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>"those who know me have no need of my name" <[EMAIL PROTECTED]>
>wrote in message news:[EMAIL PROTECTED]...
>> <34Nt6.90673$[EMAIL PROTECTED]> divulged:
>>
>> >If your implementation matches for about a kb or so then I think you can
>be
>> >assured it's ok.
>>
>> are you sure about that?
>
>Yup. If you compare the RC4 states of two diff implementations after a kb
>or so and they match then you can be reasonably assured they work.
Careful! You're likely correct if you compare the *internal states*,
but NOT if you compare the *outputs*.
Remember that Ada version of RC4 that was posted here a few weeks back?
it had a bug such that it would be correct for several kb, but by the
time you've output 64KB, it would likely have started outputing all
0's.
- Ian
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: [OT] Java
Date: Wed, 21 Mar 2001 22:58:38 +0100
Jeffrey Williams wrote:
> Tom, I'll agree that Java takes more effort to learn than say C or C++.
What ???
That might be true for hackers coming from the assembler community, but
definitely not for normal human beings. People who can't think in concepts,
but just in dirty hacks will have trouble; the rest will not miss the
nightmares of even getting a piece of C++ code compile on NT and five unix
flavors.
Newbies will quickly learn java, but they will need 3 to 4 years to become C++
pros.
The pitfalls of C/C++ mandate several years of experience until one can
understand the unecessarily complex code possible with C++. Templates, macros,
operator overloading, stack versus heap, destructors, multiple inheritance,
variable argument lists, ridiculous typecasting. All those features are
randomly used in many commercial systems.
The java language is very lean compared to that. Developers need to learn only
a small part of the powerful java standard library, depending on their current
project.
> But you have to realize that its underlying philosophy is vastly different
> (remember that C predates Java by 25 years or so
Age has nothing to do with it. The Algol-type languages are more than 25 years
old. Ask Kernigan, Richtie and Thompsonand they will admit that they just
needed a quick and dirty portable assembler to decouple their operating system
from the pdp11.
> - an eternity in the field
> of software). It's a strongly typed language, unlike C.
That comes closer to the truth. The AT&T folks didn't care about solid
engineering, but about quick coding and maximum performance. That is OK for
research, but not for the hostile environment of the internet.
> That's neither
> good nor bad - just a different approach. Don't give up on Java (or on
> strong typing). Even if you never use it, it contains lots of good concepts
> that you can apply to your code in other languages. Certainly, if I wanted
> to write heavy duty numbercrunching code, I'd think twice before using
> Java.
Numbercrunching is better done in Fortran; just the pointer aliasing of C++ is
a huge mess. In fact, the low-level optimization of pointers complicates
higher-order optimization by compilers greatly.
> But if I wanted to write an interactive application with a nice GUI,
> Java would be a serious contender for the task.
>
> "non-portable"????? If you do Java code correctly, it's highly portable.
> Especially if you're doing GUIs.
Exactly. From my engineering experience, it reduces cross-platform issues at
least at a factor of 100 compared to C++. For non-gui apps (ie servers) write
once, debug once, run anywhere is close to reality.
> Don't stop learning.
>
> LL&P
>
> Jeff
>
> Benjamin Goldberg wrote:
>
> > Tom St Denis wrote:
> > [snip]
> > > Sorry this is OT but...
> > >
> > > JAVA sucks... it's slow, non-portable and gives errors on anything a
> > > normal C compiler would just warn you about. It's hard to develop
> > > software for...
> > >
> > > Tom
> >
> > Absolutely! I mean, I try to assign a pointer to int to a pointer to
> > float, and in C, it would give me a warning about assigning a pointer of
> > the wrong type, and in Java, it gives me an error saying there's no such
> > thing as a pointer! I mean, it's almost as if it's an entirely
> > different language, can you believe it?
> >
> > --
> > The difference between theory and practice is that in theory, theory and
> > practice are identical, but in practice, they are not.
------------------------------
From: Darryl Wagoner <[EMAIL PROTECTED]>
Subject: Re: Advice on storing private keys
Date: Wed, 21 Mar 2001 16:50:12 -0500
Reply-To: [EMAIL PROTECTED]
"SCOTT19U.ZIP_GUY" wrote:
>
>
> I have not kept up wiht all the rules but for hams isn't
> encryption still illegal in the US.
Yes, the project I am working is Trusted QSL cards which in most cases will
not be sent over
the air, but even if it is, I am only using DSA which I don't think is
counted as encryption.
I think the only problem happens when there is an attempt to obcure
information. At
any rate the transport will be the Internet.
73
Darryl WA1GON
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Wed, 21 Mar 2001 16:49:11 -0400
Be more explicit. Who you wnat to kill?
Who are you threatening?
Let me understand what you mean when you say "i really don't want to
> killfile all of netcom.ca. thank you."
> .
those who know me have no need of my name wrote:
>
> <[EMAIL PROTECTED]> divulged:
>
> >I'm not using a secret algorithm.
>
> will you please keep a single from header. i really don't want to
> killfile all of netcom.ca. thank you.
>
> --
> okay, have a sig then
------------------------------
** 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
******************************
