Cryptography-Digest Digest #550, Volume #11 Sat, 15 Apr 00 02:13:01 EDT
Contents:
Re: BlowWire ("Trevor L. Jackson, III")
Number 37, same format output as 36 (wtshaw)
Re: $100 Code Challenge (Tom St Denis)
CLOSE Encryption ("MeneLaus")
Re: CryptoBag Source (update) (Tom St Denis)
Re: Help decrypt message exercise (Frederic Limouzin)
Re: ? Backdoor in Microsoft web server ? (Tim Tyler)
Re: ? Backdoor in Microsoft web server ? ("David C. Oshel")
Re: Biggest Public-key Cryptography Crack Ever (David Hopwood)
Open Public Key ([EMAIL PROTECTED])
Re: BlowWire ("Spleen Splitter")
Re: BlowWire ("Spleen Splitter")
Re: BlowWire ("Spleen Splitter")
Re: Open Public Key (Tom St Denis)
Re: BlowWire (Tom St Denis)
Re: BlowWire ("Spleen Splitter")
Re: Open Public Key ([EMAIL PROTECTED])
Re: ___IDEA (updated info.) (kctang)
Re: Regulation of Investigatory Powers Bill (Your Name)
Re: new Echelon article ("Stou Sandalski")
Re: OAP-L3: Answer me these? ("Bo Johnson")
Re: Open Public Key (Bill Unruh)
Re: Biggest Public-key Cryptography Crack Ever (Scott Contini)
----------------------------------------------------------------------------
Date: Fri, 14 Apr 2000 19:00:51 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: BlowWire
[EMAIL PROTECTED] wrote:
> In article <F1zJ4.3613$[EMAIL PROTECTED]>,
> "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]> wrote:
>
> > I'm interested in the general mapping of algorithms to hardware. The
> random
> > tides swung to Blowfish. I don't care how big it is. The more gates
> the
> > example burns the better as far as I'm concerned, as long as the
> objective
> > is met.
>
> That "mapping" is really a redesign process, and the reason
> why design engineers get paid well. You use the general-purpose
> (e.g., "C") implementation as a reference. Add lots of printfs.
> Watch the halves swap. Zero the subkeys and watch it.
>
> If you want to burn gates but not spend transistors on RAM, do IDEA.
> Use lots of multipliers, and go ahead, unroll a few stages. Or do an
> RSA accelerator. Commerce servers need them badly.
>
> > > I think it would be much more interesting and useful to build a
> FULLY
> > > pipelined version of triple-DES, with separate S-boxes at each of
> all
> > > 48 rounds, so it's a completely asynchronous circuit (no clocking)
> whose
> > > speed is limited only by the gate and lookup delays through the
> pipeline.
> >
> > Ok. This can be good, too. I'll go look for the code. Not sure
> about that
> > asynchronous stuff, tho. Dynamic logic is getting somewhat out of
> favor as
> > we go below 100nm.
>
> Really?
>
> Paul's async idea is interesting because self-timed design is
> interesting, though largely confined to research, but unrolling DES is
> not very challenging by itself.
Asynchronous designs may be out of favor (I wouldn't know; not my field), but
they have been used effectively. There's a robustness advantage because you
can get maximum throughput without inserting artificial delays (wait states)
necessary to maintain synchronicity. DEC used this in their busses to great
advantage. Fast devices are not affected by the presence of slow devices, and
slower (cheap) devices don't have to meet artificially high performance
standards in order to be useful.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Number 37, same format output as 36
Date: Fri, 14 Apr 2000 16:18:51 -0600
Several base translation algorithms have outout in base 78, which could be
expressed in a number of ways. I chose composite characters, which are in
the form of letters in one of three forms, <a>, (a), or [a], referenced as
diamond, circle, or square A.
Banas used 77 character input, no digits allowed and certain other
characters omitted, and an intermediate base of 26. The latest is Lima,
which uses an intermediate base of 12, and transposition of those doits.
It does not use substitution at the intermediate stage like Banas, but
uses the same 26 character output substitution scheme used in Banas. In
short, Lima has less key structure than Banas. Lima has these default
keys:
Sub(Li): abcdefghijklmnopqrstuvwxyz
Trans(Li): abcdefg hijklmn opqrstu
I have said that I will forego ciphertext examples in these relative
application what have like appearing output. Two are done of the five
applications. One way of looking at these composite characters is that
each represents a letter-trit pair.
If normal 26 letter ciphertext was impressed with trits in this manner of
Banas and Lima, two forms of encryption might be mixed, with either or
both being significant. It could be that any number of other algorithms
might have ciphertext be falsely classed as being kin to the Banas
Family. The trit aspect could be stripped and send some other way,
perhaps as additional letters....lots of options for deception.
--
Doubt until you have proof, then doubt frequently. Descartes
%/^): [|]"! ?=)@~ ;)[]* :@\@} *#~}> ,=+)! .($`\
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: $100 Code Challenge
Date: Fri, 14 Apr 2000 23:03:16 GMT
[EMAIL PROTECTED] wrote:
>
> The following is a message encoded using a new routine I have designed.
> The text is a written message in English. In order to test just how
> strong the encryption is, I have posted it here for anyone interested
> to try to crack it. The first person to successfully crack it will get
> $100. Seriously, $100, no kidding. Instructions for contacting me are
> included in the encrypted text. If the code is not broken by June 31,
> 2000, then the contest is over. If the code is broken, I will post that
> news here so you won't waste your time for nothing. Also note, the
> winner will be required to explain how the code was broken as well as
> provide exact text of encoded message. Good luck.
The correct solution of course being "I should have posted the source to
my algorithm so people could pick and poke in awe at my amazing math
ability, instead I posted random garbage as ciphertext and expect
people to treat me with a tad of intelligence."
Did I win?
Tom
------------------------------
From: "MeneLaus" <[EMAIL PROTECTED]>
Subject: CLOSE Encryption
Date: Sat, 15 Apr 2000 00:12:48 +0100
CLOSE is a new algorithm written by Chaos Legion,
If you are a cryptoanalyzer then come visit our site and evaluate it
for us. If you spot any weaknesses then post them on the CL Web Board
not here.
the site is...
http://members.xoom.com/menelaus_/
or
http://www.shaun-howe.8m.com/
Thanks, i'll return the favour some day if you ever need something testing.
MeneLaus
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CryptoBag Source (update)
Date: Fri, 14 Apr 2000 23:18:17 GMT
Whoops I have to put blowfish back to using PI as the sbox
initializer... Sorry about that.
Tom St Denis wrote:
>
> Yet another WIP (work-in-progress) copy of CB is available from my
> website at
>
> http://24.42.86.123/cb_106b.zip
>
> It includes a fix in the RC6 key schedule, a fix in the RSA
> import/export routines, hmm a new RNG using SHA in counter mode, and the
> ciphers now use a better way to load blocks.
>
> Things todo:
>
> 1. Take into account big_endian when loading blocks for the symmetric
> ciphers.
>
> 2. Similar for the hashes.
>
> 3. Similar for the RSA routines that use 'int' here and there.
>
> Any comments please post. This is for software developpers, it's
> entirely free and the source is all there. So if you like using it, or
> want to see changes please let me know.
>
> Tom
------------------------------
From: Frederic Limouzin <[EMAIL PROTECTED]>
Subject: Re: Help decrypt message exercise
Date: Tue, 11 Apr 2000 17:58:09 -0400
> [EMAIL PROTECTED] wrote:
> > williams Stallings' (cryptography and network security)
> > exercises. I am stalled in exercise 2.4 that gives you
>
> > Any help would be appreciated,
>
> > 53��+305))6*;4826)4�.)4�);806*;48+8�60))85;;]8*;:�*8+83
> > (88)5*+;46(;88*96*?;8)*�(;485);5*+2:*�(;4956*2(5*-4)8�8*
> > ;4069285);)6+8)4��;1(�9;48081;8:8�1;48+85;4)485+528806*81
> > (�9;48;(88;4(�?34;48)4�;161;:188;�?;
Remindes me something ... oh yeah : Read "the gold bug" from E.A.Poe
.... :)
-- Fred
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Apr 2000 23:22:53 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote:
: I did a "strings" on [dvwssr.dll], and among other things it says:
: !seineew era sreenigne epacsteN
Check out the subtle method that was used to make sure the string was
not human-readable! ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: "David C. Oshel" <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Date: Fri, 14 Apr 2000 19:24:12 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Jim Gillogly <[EMAIL PROTECTED]> wrote:
>
> : I did a "strings" on [dvwssr.dll], and among other things it says:
>
> : !seineew era sreenigne epacsteN
>
> Check out the subtle method that was used to make sure the string was
> not human-readable! ;-)
Depends. If the code is assembler sometimes you store a string backwards
for efficiency. Extremely old technique -- you pop the characters off the
stack from just below your return address, so first out is N, last out is !
--
David C. Oshel mailto:[EMAIL PROTECTED]
Cedar Rapids, Iowa http://pobox.com/~dcoshel
``Tension, apprehension, and dissension have begun!" - Duffy Wyg&, in Alfred
Bester's _The Demolished Man_
------------------------------
Date: Sat, 15 Apr 2000 00:50:02 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Biggest Public-key Cryptography Crack Ever
=====BEGIN PGP SIGNED MESSAGE=====
Mike Rosing wrote:
> Robert Harley wrote:
[...]
> > Harley remarked "Even so, it was only about one tenth of what should
> > normally be required for a 109-bit curve. That's because Certicom
> > chose a particular curve with some useful properties but we used those
> > same properties to speed up our attack". He went on to say "This
> > underlines the danger in adopting particular curves and the need to
> > pick random ones with no special characteristics. I'm concerned about
> > Koblitz curves and complex-multiplication curves, which some people
> > advocate using in order to avoid the point-counting problem".
>
> So we need another 4 bits.
Another 7 bits (because sqrt(2^7) > 10 > sqrt(2^6)). Also that assumes
there are no further cryptanalytic advances specific to Koblitz or C-M
curves.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOPeNRTkCAxeYt5gVAQFH4gf/VIMtEvZTPvjr9V/yxfNSu3E1gh9oFuxI
KDCVBHAHkd85/7euSlaW+QW7E24z6JhNk+cFbUJzY4y2GiAUpzs1KtG2OyMgM8rj
3rzNCOMQUibDxftJl5u8YyLXQWAqnUZGXNjjBu/B7YDVKLSo59gAh5c8nPSMiKYw
t8iVjAVPLKzk7OvMXO+qX1LVKUwWY2ZjhPwcSv/pxf6p1MflWCXSAhxomduyCpqD
qPEK2thrWZxbRxEV27HHrui3W6QLNQGFX0RGQ5mlbIPqQGyQbzXiSqZUZWyOnC7u
lfRwugjP+WO7+k2Skd/NzIDPEhaMgLwdZ8zLz5jx/cZ2dZOdX2CDsw==
=OXPk
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Open Public Key
Date: Sat, 15 Apr 2000 02:01:13 GMT
I need to exchange secure data between 2 companies.
So, because it is for commercial use, I can't use RSA.
Another important point: I'm in Brasil and I need an algorithm that can
be legally used here. My country doesn't have any restrictions about
importing criptography, but what about US laws??
Anyone knows what can I use in this case?
Thanks in advance
WSM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
From: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
Subject: Re: BlowWire
Date: Sat, 15 Apr 2000 02:18:24 GMT
<[EMAIL PROTECTED]> wrote in message news:8d7j8q$o6b$[EMAIL PROTECTED]...
> In article <HZxJ4.7246$[EMAIL PROTECTED]>,
> "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]> wrote:
>
> >But for layout, I'm looking at making 4 copies of
> the pi
> > table with 4 banks and 4 ports, 4 copies of the keys in 4 port
> register files,
> > and so on, and fun with wires arranging the pipelined rounds in a 2x8
> pattern.
> > So I'm actually looking at 16KB in the pi tables and 4KB in the keys.
>
> No, you don't have it right. You load the pi table into the equal
> sized RAM; then you mix in your key and grind for 521 [sic] iterations.
Yes, I do have this, thank you though. But I'm not sure you quite
see the layout problem I'm referring to, namely the 16 deep pipeline
around the S-boxes. Each S-box has 4 ports from a RAM containing
the munged pi. But I don't want to burn the space for 16 RAMs when
4 4-port RAMs will do.
>
> Mind your bit order; you'll find big and little endian Pi
> out there. Unless you calculate your own :-) In hardware :-) :-)
Not much point to computing pi for each clock cycle in hardware since there's no way
to keep up with a 500Mhz clock. And it's
easier to have 4 Kbit
rom for the reference copy of pi.
>
> > I was just curious to hear about other folks trying to implement such
> things,
> > since software is too slow
>
> And bandwidth is growing too fast
>
> > and FPGAs don't quite make it.
>
> You'd be surprised, and they have a lot of memory these days.
I'm not making a commercial product, but I do want the maximum speed.
>
> Better
> insight into
> > the algorithm helps, too.
>
> You will dream of round functions by the end...
More likely I'll be dreaming of wires...
>
> > Plus, I don't have to worry about how many
> gates
> > I burn on this project.
>
> Workin' for the spooks?
You like black?
cheers,
Spleen Splitter
------------------------------
Reply-To: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
From: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
Subject: Re: BlowWire
Date: Sat, 15 Apr 2000 02:18:25 GMT
<[EMAIL PROTECTED]> wrote in message news:8d7inu$nh1$[EMAIL PROTECTED]...
> In article <8d66ti$7up$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Paul Rubin) wrote:
>
> > It's worse than that. If you look at how the Blowfish key schedule
> > works, you'll see that the pi table is replaced at key initialization.
> > You need 4k bytes of *RAM* at each round, not ROM.
>
> I didn't think Mr. Spleen was going to unroll the loop... if so, he'd
> need 32 32-bit adders...
Yep, that's what I need all right. Plus a ton of xor's. And wires, wires
wires...
>
> And if you have
> > several keys active at the same time, you need another 4k of ram
> > for each of them.
>
> Yep
>
> > Blowfish is designed for software implementation and it's inefficient
> > in hardware. It's not really the right cipher to implement with the
> > methods you're describing.
>
> No, its possible, and its a fascinating challenge. DES is dead.
> AES ain't here, too green, will take twice the hardware resources.
It is the challenge I'm after rather than specifically using a crypto algy
designed for hardware.
>
> IDEA can be done with no memory, but you spend more gates on
> those multipliers. There's a group in .ee that's done an IDEA + RSA
> chip, 25 Mhz, a few years ago. Their cleverness was building
> multipliers that could be used for both. IDEA is key-agile, BTW.
What was the trick? Did they just mux the multipliers?
cheers,
Spleen Splitter
------------------------------
Reply-To: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
From: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
Subject: Re: BlowWire
Date: Sat, 15 Apr 2000 02:18:26 GMT
<[EMAIL PROTECTED]> wrote in message news:8d7i9s$mtk$[EMAIL PROTECTED]...
> In article <3JwJ4.7089$[EMAIL PROTECTED]>,
> "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]> wrote:
> > Greetings:
> >
> > I need something to crank on, so I decided to toy with something I
> fancifully call
> > BlowWire, which is simply a 500MHz or so fully pipelined
> implementation of Blowfish
> > in some modern technology, say 0.18um CMOS.
>
> No one gets 500 Mhz without doing full-custom polygon pushing.
> Damn cpu-hype clock inflation.
I specified 500Mhz because I think its a reasonable goal in 0.18um
technology. There will no polygon pushing since the idea is to make
it quickly. If 0.18um goes down the tubes with performance, I'll
just switch to 0.13um and ask for copper.
>
> >Connecting two of these devices on a
> > cable seems to have enough meat on it to provoke a discussion.
>
> Think parallel, not picoseconds.
>
>
> > I think I can do this in 60Kgates, with my biggest problem being all
>
>
> One third of that, not including RAM and ROM.
I was originally counting the RAMs and ROM, prior to correction on
my use of ROMs by Paul Rubin.
>
> the simultaneous
> > accesses to pi during each clock (what a ROM, what wires!).
>
> A K of 32-bit words is not too bad for a ROM.
The ROMs/RAMs don't bother me. Its the connecting of the wires between
them and the S-boxes that's more fun. I think I have a good pattern
now that is routable. Looks kinda like:
piR00 | piR01| piR10| piR11| piR20| piR21| piR30| piR31|
kR1 | sb15 | sb14 | sb13 | sb12 | sb11 | sb10 | sb09 | sb08 | kR3
kR2 | sb00 | sb01 | sb02 | sb03 | sb04 | sb05 | sb06 | sb07 | kR4
piR02 | piR03| piR12| piR13| piR22| piR23| piR32| piR33|
with all the 32-bit busses flying around, I think the congestion map
for the above is routable.
>
> > Given that I'm only doing Blowfish for fun, I'm fairly certain that
> further enlightenment
> > could be forthcoming on hardware implementations of
> crypto-functions...
>
> Its about 1200 lines of verilog not including the ROM :-)
Luckily I don't have to use Verilog, and its the polygons I want...
cheers,
Spleen Splitter
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Open Public Key
Date: Sat, 15 Apr 2000 02:41:02 GMT
[EMAIL PROTECTED] wrote:
>
> I need to exchange secure data between 2 companies.
> So, because it is for commercial use, I can't use RSA.
> Another important point: I'm in Brasil and I need an algorithm that can
> be legally used here. My country doesn't have any restrictions about
> importing criptography, but what about US laws??
>
> Anyone knows what can I use in this case?
ElGammal or ECC are the certain winners in this case. Although ElGammal
is slightly easier to implement and understand.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: BlowWire
Date: Sat, 15 Apr 2000 02:46:21 GMT
Spleen Splitter wrote:
>
> Greetings:
>
> I need something to crank on, so I decided to toy with something I fancifully call
> BlowWire, which is simply a 500MHz or so fully pipelined implementation of Blowfish
> in some modern technology, say 0.18um CMOS. Connecting two of these devices on a
> cable seems to have enough meat on it to provoke a discussion.
>
> After eating a key in 64 bit hunks of up to 1024 bits, this thing would have a
>latency
> of ~18 clocks, and then treats the incoming 64-bit parallel stream as a block,
>packet,...
> to be encrypted/decrypted.
>
> Software implementations are one thing, but they're slow, and I really don't want to
> use a "yet-another-embedded-cpu" on this particular project (top performance
>required,
> thus the pipeline design, which is more of my interest than say just a wire
>protocol).
> The C code for Blowfish that I've seen, however, has guided my views on implementing
>the
> hardware.
>
> I think I can do this in 60Kgates, with my biggest problem being all the simultaneous
> accesses to pi during each clock (what a ROM, what wires!). I'm looking at things
>like
> how many register files of how many ports, and what sort of ROM in how many copies.
> Each round would presumably be done in a clock, thus leading to the 18 or so clock
> latency to get through the pipe.
>
> Given that I'm only doing Blowfish for fun, I'm fairly certain that further
>enlightenment
> could be forthcoming on hardware implementations of crypto-functions...
Question: Why did you pick Blowfish? I would have looked up another
cipher that is a tad more hardware friendly. If you have the time and
inclination todo this. If you want to at some point sell your design
you had better make it cheap. Try finding a cipher with less ram
requirements, such as IDEA, Rijndael, etc...
Tom
------------------------------
Reply-To: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
From: "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]>
Subject: Re: BlowWire
Date: Sat, 15 Apr 2000 03:19:02 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
>
> Spleen Splitter wrote:
> >
> > Greetings:
> >
> > I need something to crank on, so I decided to toy with something I fancifully call
> > BlowWire, which is simply a 500MHz or so fully pipelined implementation of Blowfish
> > in some modern technology, say 0.18um CMOS. Connecting two of these devices on a
> > cable seems to have enough meat on it to provoke a discussion.
> >
> > After eating a key in 64 bit hunks of up to 1024 bits, this thing would have a
>latency
> > of ~18 clocks, and then treats the incoming 64-bit parallel stream as a block,
>packet,...
> > to be encrypted/decrypted.
> >
> > Software implementations are one thing, but they're slow, and I really don't want
>to
> > use a "yet-another-embedded-cpu" on this particular project (top performance
>required,
> > thus the pipeline design, which is more of my interest than say just a wire
>protocol).
> > The C code for Blowfish that I've seen, however, has guided my views on
>implementing the
> > hardware.
> >
> > I think I can do this in 60Kgates, with my biggest problem being all the
>simultaneous
> > accesses to pi during each clock (what a ROM, what wires!). I'm looking at things
>like
> > how many register files of how many ports, and what sort of ROM in how many copies.
> > Each round would presumably be done in a clock, thus leading to the 18 or so clock
> > latency to get through the pipe.
> >
> > Given that I'm only doing Blowfish for fun, I'm fairly certain that further
>enlightenment
> > could be forthcoming on hardware implementations of crypto-functions...
>
> Question: Why did you pick Blowfish? I would have looked up another
> cipher that is a tad more hardware friendly. If you have the time and
> inclination todo this. If you want to at some point sell your design
> you had better make it cheap. Try finding a cipher with less ram
> requirements, such as IDEA, Rijndael, etc...
I fully kow-tow to your point of view, but Blowfish is the assignment in this
particular endeavour. In particular, I like Blowfish since it is a difficult
realization in hardware when fully pipelined. It is not my concern to sell
the device, but simply how to build it as rapidly as possible in an advanced
CMOS process. I can afford to be somewhat liberal in an implementation if
it achieves the goal.
cheers,
Spleen Splitter
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Open Public Key
Date: Sat, 15 Apr 2000 03:11:27 GMT
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> ElGammal or ECC are the certain winners in this case. Although
ElGammal
> is slightly easier to implement and understand.
>
> Tom
>
How secure are ElGammal and ECC??
Where can I find more information about ElGammal or ECC?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: Re: ___IDEA (updated info.)
Date: Sat, 15 Apr 2000 11:30:59 +0800
==============D87820FFFDDE3C5002AFB614
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Paul Koning wrote:
> That table is VERY out of date.
For IDEA, I found
http://lslwww.epfl.ch/pages/research/theses/haenni/tutorials/idea_ia64/performance.html
Thanks and bye, kctang
==============D87820FFFDDE3C5002AFB614
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Paul Koning wrote:
<blockquote TYPE=CITE>That table is VERY out of date.</blockquote>
<tt>For IDEA, I found</tt><tt></tt>
<p><tt><A
HREF="http://lslwww.epfl.ch/pages/research/theses/haenni/tutorials/idea_ia64/performance.html">http://lslwww.epfl.ch/pages/research/theses/haenni/tutorials/idea_ia64/performance.html</A></tt>
<br><tt></tt> <tt></tt>
<p><tt>Thanks and bye, kctang</tt></html>
==============D87820FFFDDE3C5002AFB614==
------------------------------
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
From: [EMAIL PROTECTED] (Your Name)
Date: Sat, 15 Apr 2000 04:01:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>There's little point, the first time a case comes to the courts, then
>it will fall flat on it's face. If you have encrypted data on your
>hard disk, and refuse to decrypt, the the law says that you can be
>imprisoned.
>
>What this basically means is that they are removing the right of
>indivduals in a criminal court to be tried as innocent until proven
>guilty. This is a breach of at least the European Declaration of
>human rights, and probably the Universal Declaration of Human Rights.
Sounds to me that the policy of giving an inch at time
has failed because the rulers just keep making more laws.
Maybe it is time to stand on principle rather than disguise
encrypted files.
Rich Eramian aka freeman at shore dot net
------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Date: Fri, 14 Apr 2000 21:07:15 -0700
"JimD" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 13 Apr 2000 10:35:23 -0700, "Stou Sandalski" <tangui
> [EMAIL PROTECTED]> wrote:
>
> >
> ><[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
<Snip>
> >and what about
> >that time the british and americans taped that phone cable that was on
the
> >east german side?
>
> That's true as well, but I don't have a reference, although I've seen
> photographs of the tunnel in some book. The Soviets discovered that
> one too as well as the Kamchatka tap.
>
I read it in some mag, they had a thing on the discovery chanel about it...
and they also had a movie about it which is pretty good. What was realy
cool about this is that the cable was filled with compressed nitrogen (?) to
detect breaches of it and they had to go through like airlocks and junk to
get to it. East germany had pretty sick ass spy tech back in the day.. I
heard rumors that they actualy taped every long distance telephone call.
Interesting
Stou
>
> --
> Jim Dunnett.
> dynastic at cwcom.net
>
> Londoner? Vote for Ken!!
------------------------------
From: "Bo Johnson" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 15 Apr 2000 00:08:34 -0400
A. Stephoa wrote:
>Food for thought: What is interesting is that with the hundreds of
>people who have either OAP-L3 or OAR-L3, not one has come to the
>aid of any of the detractors of OAP-L3 theory.
What is more interesting is that not one has come to your defense.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Open Public Key
Date: 15 Apr 2000 04:17:21 GMT
In <8d8ih3$qvb$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>I need to exchange secure data between 2 companies.
>So, because it is for commercial use, I can't use RSA.
Go to www.pgpi.org or to www.gnupg.org
Both are free, (Note that RSA is NOT patented in Brazil so the US patent
is irrelevant)
>Another important point: I'm in Brasil and I need an algorithm that can
>be legally used here. My country doesn't have any restrictions about
>importing criptography, but what about US laws??
Both sites are outside the USA.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Biggest Public-key Cryptography Crack Ever
Date: 15 Apr 2000 04:37:13 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
>Robert Harley wrote:
>>
>> Readers of sci.crypt might be interested in the following press-release.
>>
>> Enjoy!
>
>Congratulations!!
>
>> Harley remarked "Even so, it was only about one tenth of what should
>> normally be required for a 109-bit curve. That's because Certicom
>> chose a particular curve with some useful properties but we used those
>> same properties to speed up our attack". He went on to say "This
>> underlines the danger in adopting particular curves and the need to
>> pick random ones with no special characteristics. I'm concerned about
>> Koblitz curves and complex-multiplication curves, which some people
>> advocate using in order to avoid the point-counting problem".
>
>So we need another 4 bits. The speed advantage is rather significant,
>especially for an 8 bit microcontroller. In other words, we can make
>the cracking task 10 times harder rather easily by simply choosing
>larger field sizes.
>
>My understanding is that *all* curves over a finite field have a
>complex multiplication isogeny. Finding it isn't so simple.
Yes, I think it is correct that all curves over finite fields
have this complex multiplication map, but the worry from Koblitz
curves and curves generated by the complex multiplication method
is that the endomorphism ring is much simpler than the corresponding
one for a curve generated at random. In particular, the class number
is extremely small, which could perhaps lead to a new attack specific
to these curves. Whether that is something to really be worried about
or not is a matter of opinion right now. (similarly, worries about
variants of RSA and other public key cryptosystems exist).
Scott
------------------------------
** 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
******************************
