Cryptography-Digest Digest #193, Volume #11 Thu, 24 Feb 00 14:13:01 EST
Contents:
Re: Processor speeds. (Mok-Kong Shen)
Re: Processor speeds. (Mok-Kong Shen)
Re: Crypto Speeds... (John)
Re: Compression in the Real World (Mok-Kong Shen)
Largest known prime (Mok-Kong Shen)
Re: Implementation of Crypto on DSP ([EMAIL PROTECTED])
Re: Implementation of Crypto on DSP ([EMAIL PROTECTED])
This person, Markku-Juhani O. Saarinen, recently attacked me on the ("Markku J.
Saarelainen")
Re: EOF in cipher??? (Jerry Coffin)
Re: Transmitting ciphered data (Mike McCarty)
Re: EOF in cipher??? (Jerry Coffin)
Re: Processor speeds. ("John E. Kuslich")
Re: Largest known prime ("Rick Heylen")
Re: This person, Markku-Juhani O. Saarinen, recently attacked me on the ("Markku J.
Saarelainen")
Re: UK publishes 'impossible' decryption law (Jerry Coffin)
Re: Assistance is needed :) (Mike Rosing)
Re: Enigma (John Myre)
Re: Largest known prime (Johnny Bravo)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 24 Feb 2000 18:28:35 +0100
Clockwork wrote:
>
> I predict you can factor numbers in one 128-bit register (US export
> standards), simulate weather systems, simulate a nuclear explosion, and
> render movie sequences from Toy Story T or Jurassic Park T on an shoestring
> budget.
>
> BTW, look around the Internet read what Sony is planning for there next
> system. They ARE going to move the next PlayStationT to a WorkStation -- it
> is just a matter of time.
I simply wonder why the manufacturers have not called attention of
this potential to the circle of PC users? (Not everyone read
posts in every internet groups. Nor have I read any hints
of that in a few computing journals that I subscribe.) Apparently
an negligence of the marketing personal!
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 24 Feb 2000 18:28:29 +0100
Trevor Jackson, III wrote:
>
> I think part of the answer is the phase change that happened more than 25 years
> ago. I cannot find the attribution, but the thought is that "We do not write
> software to tell the machine waht to do. We buy hardware to execute the
> software." The translation is that software compatibility increasingly
> outweighs raw hardware performance.
>
> When a game console can handle both the applications and the tools needed to
> produce them your comparison might make sense. But AFAIK consoles are "not as
> widely supported" as PCs or even mainframes.
When the general acceptance (and hence marketing) of systems is
at issue, you are right. But for specific applications, e.g. the
implementation of a specific crypto algorithm or its cracking,
one could even afford a 'hand-made' assembler, if there is
sufficient cost benefit (i.e. when the hardware is cheap enough
to justify that effort/cost).
M. K. Shen
------------------------------
Subject: Re: Crypto Speeds...
From: John <[EMAIL PROTECTED]>
Date: Thu, 24 Feb 2000 09:33:49 -0800
I was looking for a basic framework for the encrypt/decrypt
operations on my 500mhz PC. I have tested 1 million bytes and
got 3000 microseconds. The encryption did 1000x1000. That is it
called the encrypter 1000 times to encrypt 1000 bytes. I am
aware that the calls to the encrypter take some time, but it
shouldn't be much.
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>John wrote:
>> What would be an average or "acceptable" speed for encryption
on
>> a pentium 3 processor at 500mnz?
>
>Well a general question with useless details (why such a
specific
>processor?) results in a general answer. For any operation, if
the
>user waits...
>
><= 0.1s - excellent, no need for optimizations anymore
>0.2..0.3s - good, optimizations not necessary except if this
is the
> response time for really minor operations (for
example,
> inserting a character into a text file, or
displaying
> a menu).
>0.5..1s - okay if the operation is nontrivial (loading a
large
> document etc).
>2..5s - okay for longer jobs
>>5s - bad, display something like a progress bar and
inform
> the user (a) whats going on (b) how long he has to
> wait (c) the computer isn't crashed, but is doing
> something
>
>In other words, what do you want to know ? There is symmetric
>encryption, and there is asymmetric encryption. For each class,
>there are many different algorithms, where the faster ones are
>often less secure and the slower ones are sometimes more
>secure. If you use GnuPG or OpenSSL you will have very good
>performance, near the best you can get, except if you really
>compare them with full assembly implementations.
>
>
* 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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Compression in the Real World
Date: Thu, 24 Feb 2000 18:42:55 +0100
John Savard wrote:
>
> I have no doubt that a compressor specialized to compressing text,
> however, could achieve somewhat better results than current
> commonly-used compression programs.
Indeed, I think that there is some prospect to develop a good
specialized compressor for Word documents with its special formating
informations. But it certainly can't compress to an shorter output
than the compression of the pure text characters that are in the
document (the content of the document, without the formatting
informations).
M. K. Shen
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Largest known prime
Date: Thu, 24 Feb 2000 18:43:03 +0100
I learned that a young man in France, named Joel Armengaud, has
found the currently largest known prime 2^1398269 - 1. Does
anyone know of more details?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Implementation of Crypto on DSP
Date: Thu, 24 Feb 2000 17:28:29 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > >
> > > Given that all this stuff exists in portable C, and you can get
decent
> > > C compilers these days, you could just run the code through a
> > compiler.
> > > DES might benefit from hand-tuning; the rest probably not all that
> > much.
> > > (As I recall, there's even a GCC for TI, don't know if it's 100%
done
> > > yet.)
> > >
> >
> > I am surprised that there is not much benefit in hand optimisation.
10
> > years ago it was a rule of thumb that a good assembler program would
get
> > you speed benefits of 5 or more.... Things must have really
> > changed....Are C compilers that good..? All they all the same
> > quality...or some more super optimised then others..
> >
> > But I must point out, that maybe the case for perhaps a
Uni-processor
> > SISD machine, but with pipleline and multi-architecture DSP's..I
would
> > suggest that hand optimisation plays a very significant gain...
> > Vectorising compilesr have not reached the staet of the art of
ordinary
> > optimizing compilers.
>
> Good points. I don't know about the factor of 5, that sounds
plausible
> for low quality PC class C compilers of a few years ago but not
> necessarily for others; high grade optimizing compilers have existed
> for quite some time. That includes vectorizing etc. -- ask Cray...
>
Cray has been in this business a long time...Yes they have very
efficient vectorising compilers..
But most of the DSP and chip manufacturers support MS C++, GNU...dont
know if you classify this as a low grade PC compiler.
> Nevertheless, it is true and will remain true that the very best
> assembly
> language programmers can out-code any compiler. That's true simply
> because
> the programmer can know more about the nature of the problem than you
> can
> express in the programming language, so the programmer can do
> optimizations
> the compiler cannot make because the compiler cannot be told they are
> valid.
>
> Note I said "the very best...programmers". Chances are by now a good
> compiler
> will outperform an average skill assembly programmer. And the bar is
> going
> up over time, as the properties of processors become more complex.
For
> example,
> it was claimed that you can't justify assembly language programming
for
> RISC machines, especially machines like the Alpha. That's not true, I
> have
> the test cases to prove that, but it certainly is the case you have to
> study
> hard and know a lot to beat the best compilers.
Would be interested in more info if you have any. Again, companies like
DEC and Cray have put in alot of effort in their compiler technology.
>
> > We have done some hand calculations for 3DES on an SIMD machine,
and it
> > turns out that the bottleneck in the algorithm is the Table lookup.
The
> > excl OR runs super fast ( few orders of magnitude faster then table
> > lookup)...
>
> So read Shamir's papers on how to do DES fast, in particular the
> observation
> that you can convert the S-box lookups into sequences of boolean
> operations.
That sounds interesting. Any references? IS this approach generalised
to Block ciphers in general... they pretty much all have S-Box designs
...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Implementation of Crypto on DSP
Date: Thu, 24 Feb 2000 17:31:36 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> >
> > I am surprised that there is not much benefit in hand optimisation.
> > ....Are C compilers that good..?
> >
>
> Don't expect too much out of compiler optimization for crypto
> algorithms.
>
> Here is a representative example: for RSA decryption or signature, the
> optimization strategy starts from (a) the Montgomery multiplication
> algorithm
> and (b) the chinese remainder theorem (otherwise, you position your
> product
> out of the market performance-wise). The Montgomery algorithm (a)
> benefits
> nicely from a 16X16->40 bits MAC (multiply-accumulate) operation found
> on DSPs, but
> such a construct is not part of "portable C". For the chinese
remainder
> theorem (b),
> some newer DSPs can do two such MACs (sustained) every instruction
> cycle, which is
> great for the chinese remainder theorem implementation. The C
optimizer
> *might*
> not know beforehand of the chinese remainder theorem, so you'll never
> get the
> sustained MIPS rate without explicitly coding the chinese remainder
> theorem for the
> specific DSP instruction set.
Thats very interesting. Any other special tricks for DH..we use DH
mainly...and for 3DES/other Block Ciphers?..would be interesting to try
them out.
>
> - Thierry
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.security,soc.culture.nordic,soc.culture.europe,soc.culture.soviet,soc.culture.russian,talk.politics.european-union,soc.culture.china
Subject: This person, Markku-Juhani O. Saarinen, recently attacked me on the
Date: Thu, 24 Feb 2000 17:40:34 GMT
This person attacked me. His name is Markku-Juhani O. Saarinen
<[EMAIL PROTECTED]> University of Jyv�skyl�, Finland. He told me that I can
not use my name, when I post on the USENET, and then started the
information attack without any cause. I can email all his emails to you
and any other people around the world. I can identify his business
relations and companies and I can provide all this information to you.
You can also find all his business contacts.
I am sure you can find him.
My best regards,
Markku
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 24 Feb 2000 10:49:28 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> "Douglas A. Gwyn" schrieb:
> >
> > Runu Knips wrote:
> > > "Douglas A. Gwyn" schrieb:
> > > Okay, this might have changed, but at least when I've learned
> > > C (many years ago), I read in my K&R CHAR_BIT (number of bits
> > > in a character, defined in limits.h) must be at least 7 bit.
> >
> > CHAR_BIT and <limits.h> didn't exist for 1st Ed. of K&R;
>
> Of course, my K&R is a later edition AFTER the ISO standard
> was written.
I suspect that would be news to both Brian Kernighan and Dennis
Ritchie. Dennis was recently asked about a third edition of the
book, but didn't say anything definite about there being plans TO
write it, not to mention it already having been written. The second
edition was written during the standardization process, NOT after the
standard was written.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Transmitting ciphered data
Date: 24 Feb 2000 17:36:12 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
)Markus Eiber wrote:
)>
)> Hi there,
)> I am looking for some aspects on how ciphering data might influence the
)> efficiency of transmission systems.
)> Are there any references on this topic?
)
)Don't know about references.
)
)Two observations:
)
)1. Any compression algorithms in the transmission system (such as the
)compression now standard in all dialup modems) become entirely useless.
)So your actual throughput goes down to the base wire rate (53 kb/s for
)the latest modems) rather than the 2x to 4x gain you can get at least
)for
)text data with compression.
[snip]
Unless one compresses before encryption, in which case all of that is
regained.
--
----
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: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 24 Feb 2000 10:54:30 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> How long should this discussion continue ? CHAR_BIT is AT LEAST 7,
> so UCHAR_MAX is AT LEAST 127 != 255. Thats what my K&R says.
Please be so kind as to tell us exactly what printing and which
edition of the book you're talking about: if there's really a version
that contained this egregious error, I'm quite certain Dennis Ritchie
would like to know about it so he can post a correction on his web
page of errata.
There's no room for question that IF there's a version of the book
containing this information that it's absolutely nothing but an error
in that specific version of the book.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 24 Feb 2000 10:24:47 -0700
This seems fantastic!!
But how does one interconnect these systems and how does one get specific
software to play on these systems?
Are there assemblers or compilers available to the general public.
JK
Clockwork <[EMAIL PROTECTED]> wrote in message
news:Yl3t4.1220$[EMAIL PROTECTED]...
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Mike Rosing wrote:
> > >
> >
> > > machines and building a supercomputer from those. At only $200 the
128
> > > bit machines are pretty cheap for what they do, and I totally agree
> >
> > Most PCs today have only 32 bit registers. I guess that this jump to
> > 128 bits probably can more than compensate for the slower processor
> > speed (if any), resulting in substantial benefits especially in doing
> > multi-precision arithemetic operations. So this appears to be
> > indeed an interesting project.
> >
> > M. K. Shen
>
> Amen :)
>
>
------------------------------
From: "Rick Heylen" <[EMAIL PROTECTED]>
Subject: Re: Largest known prime
Date: 24 Feb 2000 17:59:46 GMT
Old news I'm afraid. The current largest known prime is probably
2^6972593-1
See http://www.mersenne.org/status.htm
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> I learned that a young man in France, named Joel Armengaud, has
> found the currently largest known prime 2^1398269 - 1
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.security,soc.culture.nordic,soc.culture.europe,soc.culture.soviet,soc.culture.russian,talk.politics.european-union,soc.culture.china
Subject: Re: This person, Markku-Juhani O. Saarinen, recently attacked me on the
Date: Thu, 24 Feb 2000 18:01:29 GMT
Actually, he claims to be the security expert or something, but I learned
that he actually was not really.
Best regards,
Markku
"Markku J. Saarelainen" wrote:
> This person attacked me. His name is Markku-Juhani O. Saarinen
> <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland. He told me that I can
> not use my name, when I post on the USENET, and then started the
> information attack without any cause. I can email all his emails to you
> and any other people around the world. I can identify his business
> relations and companies and I can provide all this information to you.
> You can also find all his business contacts.
>
> I am sure you can find him.
>
> My best regards,
>
> Markku
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Thu, 24 Feb 2000 11:16:15 -0700
In article <[EMAIL PROTECTED]>, eric-no-spam-for-
[EMAIL PROTECTED] says...
[ ... ]
> Jerry Coffin <[EMAIL PROTECTED]> writes:
> > You're right -- in fact, I doubt any but the most ignorant politicos
> > and such who've looked at it think anything being contemplated will
> > really stop DoS attacks. There's still some hope and help available
> > from cryptography in general though: if every packet is signed,
> > tracking down the originator of a packet becomes a lot easier...
>
> That only will help if the compromised systems keep logs of the originators
> of packets that they receive. And of course, the first thing the people
> that compromise those systems will do (if they are smart, or if the person
> who wrote the tools they use is smart) will be to delete such logs.
A DoS attack does NOT give you access to logs, etc., on the system
you're attacking. In fact, the very Denial Of Service you're making
happen means that (among other things) it will be difficult, if not
impossible, for anybody to access anything on the system you're
attacking: that's the whole point (and the whole effect) of the
attack.
> Given that we're talking about machines that aren't very well secured today,
> it's unlikely that they will have fancy logging of all packet originator
> signatures in the future.
That depends: they lack security today mostly because they lack much
motivation for security. Every time they're attacked, it increases
the motivation. When the motivation toward security becomes greater
than the time, effort, etc., required to deploy it, they'll start to
worry about security.
> Besides, if a major site such as Yahoo started requiring the request
> originators to provide authenticated requests, don't you suppose that a
> lot of people would switch to a competing site that didn't?
I doubt it. Chances are it'll be less a matter of requiring
authentication than simply starting to track the information as it
becomes available. Right now, they could do quite a bit more than
they do to identify the person originating a request, but they don't
bother because they don't care. When/if they start to care more,
they'll bother more as well.
In addition, most such authentication is likely to originate from the
user more as a result of an OS upgrade than because the user decides
to do it. Right now the VAST majority of users have virtually NO
clue of how TCP/IP works, and when IPv8 (or whatever) comes into use,
the percentages are likely to be considerably lower still.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Assistance is needed :)
Date: Thu, 24 Feb 2000 12:27:27 -0600
Nemo psj wrote:
>
> Hello all this is my first time posting here so i hope i dont sound silly.
> Alright here we go, I need to find some source for RC4(good source not from
> the planetsourcecode.com site) or any other yet un cracked encryption
> algorythm. The reason is that i have made over the past 8 months a what i
> belive to be a really solid and good encryption algy. The password in the algy
If it's so good and solid, why don't you describe the algorithm
directly?
Patience, persistence, truth,
Dr. mike
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Enigma
Date: Thu, 24 Feb 2000 11:25:41 -0700
DJohn37050 wrote:
>
> Check out the NIST AES submission.
> Don Johnson
He did say CAST-128.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Largest known prime
Date: Thu, 24 Feb 2000 13:42:09 +0000
On 24 Feb 2000 17:59:46 GMT, "Rick Heylen" <[EMAIL PROTECTED]>
wrote:
>Old news I'm afraid. The current largest known prime is probably
>2^6972593-1
>See http://www.mersenne.org/status.htm
And that's probably the largest, not probably prime. :) Mersenne Primes
have a very simple primality proof, it just takes a long time to do it.
Still, easier than trying all possible factors up to (2^6972593-1)^.5
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
** 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
******************************
