Cryptography-Digest Digest #204, Volume #12 Tue, 11 Jul 00 14:13:01 EDT
Contents:
Re: Base Encryption FAQ (immune from plain-text attacks)) (Mack)
Re: Proposal of some processor instructions for cryptographical applications (Jayant
Shukla)
Re: Steganographic encryption system (Rex Stewart)
Re: hijacking? (Mike Rosing)
Re: cray and time needed to attack (Bob Silverman)
Re: Proposal of some processor instructions for cryptographical (James Cownie)
Re: Public/Private Key crypting ("Joseph Ashwood")
Re: NTRU PKC ("Joseph Ashwood")
Re: Proposal of some processor instructions for cryptographical applications
(Michael Dales)
Posting downside up (Re: Steganographic encryption system) (Tim Haynes)
Re: Steganographic encryption system ("Joseph Ashwood")
Re: Proposal of some processor instructions for cryptographical applications
("Joseph Ashwood")
Re: cray and time needed to attack ([EMAIL PROTECTED])
Re: Proposal of some processor instructions for cryptographical applications
(Sander Vesik)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Base Encryption FAQ (immune from plain-text attacks))
Date: 11 Jul 2000 17:10:02 GMT
>In addition, base encryption is immune to plain-text-attacks.
>Because multiple algorithms can generate a plain-text, plain
>text attacks are useless against Base Encryption.
>
Only with some algorithms. Other algorithms
will be weak against chosen plaintext. RC6, TWOFISH,
and IDEA would be strong.
>plug-and-play cypher engines with it. Simply plug in twofish,
>RC6, IDEA, as an augmentative step in the algorithm! Make one
>up yourself and use it like another operator!
>
If you are going to use RC6, IDEA or TWOFISH
why would you need base encryption?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 11 Jul 2000 16:46:59 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>Jayant Shukla wrote:
>> The AES candidates are not too _tiny_. In fact, the fully pipelined
>> version of the AES candidates could not be fitted on Xilinx XC4000
>> FPGA. The NSA paper shows that even the most efficient implementation
>> of these algorithms in hardware takes up > 23 mm^2 of silicon.
>> Don't even ask about the fully pipelined versions ( ~1000 mm^2).
>Sounds to me like somebody screwed up. The TMS320C6201 versions
>were something like 1KB each on average.
The C62xx DSPs are not small. The DSP implementation of the
algorithms may be 1KB, but those 1KB of instructions need
a lot of silicon to implement. The numbers that I am quoting
are from AES3 papers.
regards,
Jayant
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 17:05:18 GMT
> [message order normalised]
>
> >> phil hunt wrote:
> >> > I am thinking of developing a steganographic encryption system
that
> >> > will enable a particular cyphertext to be decrypted into two or
more
> >> > different plaintexts, depending on which key is used.
>
> >"jungle" <[EMAIL PROTECTED]> wrote
> >> what is the reason to decrypt into many different plaintext ?
>
> On Tue, 11 Jul 2000 10:48:55 +0800, Chris Severn
<[EMAIL PROTECTED]> wrote:
> >I'd assume it's so that when the FBI comes knocking at your door
demanding
> >you give them the keys to your encrypted data, that you can do just
that.
> >You just give them the key that decrypts it to some non-sensitive
> >information - not the good stuff.
> >
> >Sounds fair to me.
>
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Got it in one. I imagine there's other benefits as well, but not
having
> a background in cryptography, I wouldn't know what they are.
>
> ?order wrong the in posts quote people some do why ,way the By
>
> --
> ***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
> Moore's Law: hardware speed doubles every 18 months
> Gates' Law: software speed halves every 18 months
>
All depends on the software.
The system I use to post here puts you name at the top and mine
at the bottom - so I either move my sig to the top (usually) or
cut and past the "In artical..." line to the correct place down
the message (as in this message).
The system I use at work (MS) keeps pushing the older stuff
to the bottom and adding all new stuff at the top.
As messages are passed between the two systems things get
all fouled up.
I never have found a totally satisfactory solution - and if
anyone does find it, someone probably won't like it. Isn't
diversity a great thing (keeps us on our toes).
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: hijacking?
Date: Tue, 11 Jul 2000 12:14:35 -0500
Tome' wrote:
>
> Someone can explain me what does mean channel hijacking? please
A channel is an established link between 2 computers or routers.
It usually refers to an end to end link over the network, at some
higher level view than just raw hardware.
To "hijack" a channel means you let someone log into a main server,
then you substitute your data for theirs. This can be done at
a router which captures the victims data and passes until the login
is complete, then cuts them off. For plain text transmission this
is a very powerful technique for creating havoc, especially if the
attacker can finish what they want in a few seconds. The victim
just logs in again and thinks the network burped (which happens,
so it's not unusual).
If end to end encryption is used, this is difficult because the
attacker doesn't know the secret key.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Tue, 11 Jul 2000 17:25:35 GMT
In article <8kd99o$3ba$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> >> > Right now, Samsung is working on the Alpha 21464, which will
include
> >> > memory with a cycle time of under .3 ns.
> >>
> >> Perhaps for on-chip cache. What about the 10 to 100 Terabytes
> >> of memory that will be needed to hold the matrix?
> >
> >If it can be built into a cache, it can be done outside the cache as
> >well. Yes, you're likely to incur some slowdown (usually on the
> >order of 10 to 20%) due to extra buffering needed. ... I have VERY
> >carefully said that I was talking about what was theoretically
> >possible with current technology, NOT what was likely to be built or
> >was economically feasible.
>
> Excuse me, but I always heard that electrical signals in a wire
propagate
> at about 1/3 of the speed of light. That means that with that 10-20%
> buffering slowdown, in .3 ns they can travel about 1 inch.
>
> I'd be very interested to know how with current technology, it's even
> theoretically possible to put 10 to 100 terabytes of .3 nsec memory in
> a device no more than 1 inch in radius. If you can go to Intel or IBM
> with a coherent proposal, I'm sure they will make you a rich man ;-).
Now this reply is downright UNFAIR!
Imagine! Confusing Mr. Coffin with facts when he was convinced that
only he was right.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: James Cownie <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 17:41:48 GMT
Paul Koning wrote:
>
> "Douglas A. Gwyn" wrote:
> The reason byte access works efficiently is that system buses have
> byte lane enables so you can selective byte writes *without* the
> absurd overhead of a read/modify/write sequence.
Not if you have ECC, then you have to do a read modify write to recalculate
the ECC. (And any sensible large machine will have at least SECDED nowadays).
-- Jim
James Cownie <[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Public/Private Key crypting
Date: Tue, 11 Jul 2000 10:38:04 -0700
Actually all public key algorithms should do this quite nicely, with a few
caveats. If you want to avoid having the outer encrypt forced to span 2
blocks, you must create the outer key so that it will encrypt a block of the
size of the inner result. For ElGamal this would be doubling the size, for
RSA it simply means choosing slightly larger primes. From there you can
simply treat the first set of encrypted data as binary data that will fit in
a single block.
Joe
<[EMAIL PROTECTED]> wrote in message news:8kepkm$1hbs$[EMAIL PROTECTED]...
> Hello,
>
> I dont have a lot of experience with cyphering, so i am asking here.
> Is there any algorithm, which allows me this:
> -public and private key
> -data==decrypt(decrypt(encrypt(encrypt(data,public_key1),public_key2),
> private_key1), private_key2); !!
>
> i be very thankfull for any comments, mostly for some links to the
algorithm.
>
> Bohdan
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NTRU PKC
Date: Tue, 11 Jul 2000 10:32:05 -0700
Given that I accept that this was a genuine misunderstanding. I was not
referring to NTRU itself as worthless and wasteful, as a matter of fact I
have not yet studied NTRU to make such a determination. However, I was
making a similar statement regarding using cryptography to prevent the
piracy of MP3s, even given perfect cryptography, the benefits can be gotten
around, and an unrestricted MP3 made, making the protection only an
annoyance for legitimate users.
Joe
"Vin McLellan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In a sci.crypt post about SecurID crypto, I twitted Joseph Ashwood
> <[EMAIL PROTECTED]> about the harsh comments someone (with the same name
> and e-mail address) had posted to the Cypherpunks mailing list, on July
> 4th, about the July 3 NY Times "Patents" column on the new NTRU
> public-key crypto patent.
>
> Mr. Ashwood, in reply, denied making those statements and demanded a
> retraction.
>
> Joe: If you have been the victim of an identity theft, you have my
> sympathy and a very sincere apology. If, OTOH, this was just an off the
> cuff response to the NYT article -- perhaps written without bothering to
> look up the patent at issue -- I wouldn't want to make too much of it,
> either.
>
> IMNSHO, only a fraction of the 400 people who posted geek-hysterial
> comments on SlashDot, about Sabra Chartrand's NYT article, had bothered
> to sort the media fluff about encrypted music from the spanking new NTRU
> patent her/his column was based on;-)
>
> Suerte,
> _Vin
>
> ---------------------------
> Monday, on sci.crypt, Vin McLellan <me> wrote:
>
> > > (Elsewhere, Mr. Ashwood recently described the NTRU PKC a piece of
> > > "shit" which doesn't deserve the patent it just received -- a crisp
> > > cryptographic evaluation which I suspect his professional and personal
> > > friends may find opportunity to recall often in the years to come;-)
>
> Joseph Ashwood <[EMAIL PROTECTED]> replied:
>
> > Now we get to the part that is the actual reason I replied. I think you
have
> > mistaken me for someone else. A quick search of www.deja.com helps
assure
> > me, the only occassions where my name and NTRU appear in the same
message is
> > the one I'm replying to, and in one where I state that with finitely
sized
> > keys brute force is always possible, and one reply to my brute force
> > comment. Searching for my name and the word "shit" shows nothing that
was
> > written by me. In fact searching for NTRU and "shit" turns up only your
> > message. If your abilities at journalism are anywhere near you abilities
at
> > writing to newsgroups I'm sure you've heard what I have to say quite
often.
> >
> > Either provide some evidence or I would appreciate a retraction of your
> > statement. However since it would be off-topic for sci.crypt, having it
> > inline of the rather innevitable response your going to make to this
message
> > will be more than suitable.
>
> [The topic of NTRU doesn't seem off-topic for sci.crypt -- and I
> thought my message on C'punks was substantive -- so I am going to
> append, below, a couple of the Cypherpunks posts on this topic.
>
> [The message signed by a Joseph Ashwood <[EMAIL PROTECTED]>, can be found
> in the C'punk archive at:
>
<http://www.inet-one.com/cypherpunks/dir.2000.07.03-2000.07.09/msg00076.html
>
> _Vin]
>
> 1. The original post:
>
> From: "Anonymous" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 03, 2000 12:07 AM
> Subject: New Encryption System Would Protect Digital Music
>
> http://www.nytimes.com/library/tech/00/07/biztech/articles/03pate.html
> >
> > New Encryption System Would Protect Digital Music
> [snip]
>
> -------------------------------
>
> (2) One response, which appeared to be from Mr. Ashwood:
>
> To: [EMAIL PROTECTED]
> From: Joseph Ashwood [[EMAIL PROTECTED]]
> Date: Tue 7/4/00 3:23 AM
> Subject: Re: New Encryption System Would Protect Digital Music
>
> I can't believe someone is stupid enough to believe that this might
> actually even slow someone down. just grab the output of the program
> (aka the input to the sound card), and pipe it into a wav file. Gee,
> that put's us exactly where one would desire to be to create a
> redistributable compressed file. And they were granted a patent on this
> useless shite?
> Joe
>
> -----------------------------
>
> (3) My reply:
>
> From: Vin McLellan [[EMAIL PROTECTED]]
> To: [EMAIL PROTECTED]
> Sent: Tue 7/4/00 11:03 PM
> Subject: RE: New Encryption System for Music (nytimes)
>
> On Cypherpunks, Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>
> > I can't believe someone is stupid enough to believe
> > that this might actually even slow someone down. just
> > grab the output of the program (aka the input to the
> > sound card), and pipe it into a wav file. Gee, that
> > put's us exactly where one would desire to be to
> > create a redistributable compressed file. And they
> > were granted a patent on this useless shit?
>
> Yo, Joey! Check out the forest behind the tree! ;-)
>
> All this bombast about how NTRU might be used, could be used, will be
> used, to protect music and other multimedia is only a reflection of the
> NYT's current obsession (albeit, widely shared) with music and film
> "copyright," and crypto-enhanced intellectual property protection.
>
> A couple of months ago, I saw another article which described NTRU
> wholly in terms of its "broad potential" for enhancing wireless devices
> and applications.
>
> One does not preclude the other, obviously -- but it is unwise for
> tech-savvy observers to let a NYT columnist define too narrow a
> perspective for what is basically an intriguing new public-key
> cryptosystem.
>
> EduPage's paraphrase of the NYT column on NTRU put the newly patented
> cryptosystem in context a lot better than either the Times, or the most
> of the hundred-odd geeks who have commented about the NTRU column on
> Slashdot, C'punks, sci.crypt, and other online forums.
>
> Expanding on the NYT's narrow focus, EduPage noted the obvious:
>
> >> [NTRU's] "public key" encryption...
> >>works for virtually all data transmissions between
> >>computers, cell phones, digital music players, or any
> >>consumer electronic device that has Web access.
>
> What the NTRU patent describes may be the smallest, and perhaps by far
> the fastest, of the 70-odd second-generation public-key crypto
> algorithms
> that have been published or patented. See:
> <http://www.patents.ibm.com/details?&pn=US06081597__>
>
> NTRU claims as much as a two order of magnitude relative increase in
> speed over alternative PKC systems, as well as the advantage of a tiny
> code footprint. See the FAQ by Joe Silverman, one of the three NTRU
> inventors and a prominent ECC scholar:
> <http://www.ntru.com/tech.learning.faq.htm#Why is NTRU fast>.
>
> I've done some consulting for NTRU, so my opinion should be taken with
> a grain of salt, but I've been intrigued by what new applications might
> be possible with PKC keys that can be generated so quickly and so
> cheaply that they can be considered "throw-aways."
>
> I'll leave debate about the relative security of NTRU to
> mathematicians, but suffice to say that NTRU has, for the past couple of
> years, been the subject of extensive study by those who specialize in
> cracking
> this type of structure. Current results seem to be positive. (Where
> potential vulnerabilities have been identified, they have been
> addressable them with some reconfig of the internal parameters: a
> fairly standard
> process for shaking down a new cryptosystem.)
>
> RSA has a twenty-year head start in building trust thru endurance, of
> course; but few cryptographers are gonna dismiss NTRU as a paper tiger
> today. There are market niches that will go to a PKC with the greatest
> speed, smallest size, and lowest power requirements; there are markets
> that will go to the most trusted PKC; and others that will go to some
> PKC which balances
> betwixt. (I expect we will also see more application environments that
> will harness multiple PKCs, to take advantage of their relative
> strengths.)
>
> While NTRU will doubtless be used to secure (probably several
> different) multimedia IP formats -- eventually it will be the consumer
> market, the Congress (at least in the US), and the Courts, which will
> determine how far the owners of copyrighted media will be allowed to
> extend their control, post-sale, over the users' daily use of CDs, DVDs,
> memory sticks, etc.
>
> Today's trends often spur tomorrow's reactions.
>
> While discussing the potential for NTRU for media content control,
> <[EMAIL PROTECTED]> pointed out:
>
> > [1] Consider if Sony (which owns a lot of content
> > producers) were to only release future content on
> > players of their manufacture. Ignore the antitrust
> > fnord) issues for the moment.
>
> I don't know how the anti-trust issues play out, but one of the things
> that the NYT article didn't mention is that Sony -- perhaps the largest
> owner of copyrighted content -- is also a major equity shareholder in
> NTRU Cryptosystems. See "NTRU Announces $11M Funding," at <www.ntru.com>
>
> Sony stepped in with financial support for NTRU's initial development a
> couple of years ago, shortly after the inventors -- three Brown
> University mathematicians -- first published the NTRU cryptosystem and
> filed for a patent. A couple of months ago, Sony greatly expanded it's
> equity position when NTRU went out for VC funds.
>
> The prospect for expanded corporate (or creator) control of copyrighted
> content and media is really a political issue, not a technical issue. I
> think, however, that it would be rash to presume that just
> because an absolute barrier to "unorthodox" use is unlikely -- given
> that content must eventually hit the analogue speaker or screen -- that
> there will not be a variety of more or less burdensome options for
> PKC-enabled restrictions on access to copyrighted content and the reuse
> of media.
>
> Not all controls on consumer praxis seem to be especially irksome,
> especially if they are intended to block commercial contenders rather
> than hassle unorthodox users. One of the earliest RSApkc licensees was
> Atari, which encrypted and digitally signed all Atari game cartridges.
> Users required an Atari console (with an embedded RSA key) to unlock the
> cartridge for play.
>
> Seemed to be very successful, although I can't recall Atari ever
> bragging about it. Actually, it seemed to be a competitive detail that
> the vendor didn't think mere users need be bothered with;-)
>
> Suerte,
> _Vin
>
> "Cryptography is like literacy in the Dark Ages.
> Infinitely potent, for good and ill... yet basically an
> intellectual construct, an idea, which by its nature
> will resist efforts to restrict it to bureaucrats and
> others who deem only themselves worthy of such
> Privilege." _A Thinking Man's Creed for Crypto _vbm
>
> * Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
------------------------------
From: [EMAIL PROTECTED] (Michael Dales)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
applications
Date: 11 Jul 2000 17:14:18 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
>While I vaguely remember to have read about a forthcoming
>architechture that has properties akin to those provided by FPGA, it
>would be desirable that common computers, which are what people
>normally have access to, have enhanced capabilities to do encryption
>processing.
Hmmmm. In your original posting you said you were providing suggestions
for "future processors" - thus what's to stop Processor/FPGA hybrids
becoming common in the future? Do you know something we don't? ;-) The
rate at which acceptance of FPGAs is increasing suggests that
reconfigurable logic will become common place in the not too distant
future.
Adding Field Programmable Logic(FPL) to a processor would be a good way
of solving the problems you outlined - bit swizzling in FPL is very easy
(if you have enough routing resources).
For those interested in this field, here's some links to research
into placing FPL into a microprocessor core:
* PRISC -
http://www.eecs.harvard.edu/hube/publications/publications.html#prisc
* GARP -
http://citeseer.nj.nec.com/hauser97garp.html
* CoMPARE -
http://www.inf.tu-dresden.de/~ss9/works.html
* General field survey -
http://galeb.etf.bg.ac.yu/~bokir/reconf/
* Proteus (my work) -
http://www.dcs.gla.ac.uk/~michael/phd/
This is just a brief list - find more by following the citations.
DES is a popular example application in this field as bit swizzling as done
if the S-boxes, is easily done in FPL.
--
Michael Dales --- email: [EMAIL PROTECTED] --- tel: +44 141 330 6297
Department of Computing Science, University of Glasgow, Glasgow, G12 8QQ
------------------------------
From: [EMAIL PROTECTED] (Tim Haynes)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Posting downside up (Re: Steganographic encryption system)
Date: 11 Jul 2000 18:47:31 +0100
Rex Stewart <[EMAIL PROTECTED]> writes:
> All depends on the software.
People are software? ;(
> The system I use to post here puts you name at the top and mine at the
> bottom - so I either move my sig to the top (usually) or cut and past the
> "In artical..." line to the correct place down the message (as in this
> message).
You have a *very* strange 'system' if it mangles your articles by
default. It would probably pay dividends to remember that people normally
strip anything after the sigsep automatically on followup, if not when
reading as well.
[...]
> I never have found a totally satisfactory solution - and if anyone does
> find it, someone probably won't like it. Isn't diversity a great thing
> (keeps us on our toes).
No, some diversity causes a PITA. There are plenty enough logical reasons
why the right way up is Right(TM): you should get a news-reader[1] that
makes your life easier to post in such a manner that others have no trouble
understanding what you mean, with context from previous articles, so that
they can follow-up with minimal hassle.
(The other way of looking at this is that I will page-down an article
immediately on seeing mostly quoted text on the first page, and if I miss
the new content because you put it at the top, I press 'k' on the way out
so your score goes down. But that's the stick side compared to the above
carrot.)
Around here (says me, noticing cross-posts; this is uk.c.o.l here) we aim
to post the right way up, and fla^H^H^Heducate those who don't.
~Tim
Footnotes:
[1] Why yours is putting in HTTP-related 'User Agent' headers, I just don't
want to know. You might find investigating slrn and Xemacs/Gnus profitable,
though.
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-
| So shine on, harvest moon, | http://piglet.is.dreaming.org/
| Cast your might on the ripening corn | [EMAIL PROTECTED]
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 10:44:20 -0700
Crossposted-To: comp.os.linux.development.apps
> I think I get it now.
>
> You're proposing an algorithm such that if as adversary has a ciphertext
> and a possible key, then the adversary *can* find out whether the keys is
> valid, *but* only by decrypting the whole ciphertext, which is likely to
> take up a lot of CPU time, and thus hamper an adversary who is doing a
> brute-force search on all possible keys.
>
> Right?
Exactly. It just happens to have a particular name, and there are a few
known types, of which OAEP is probably the best known (although not likely
to be the most efficient for your uses).
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Tue, 11 Jul 2000 10:52:24 -0700
Crossposted-To: comp.arch
> the ECC. (And any sensible large machine will have at least SECDED
nowadays).
See, that's where the argument goes wrong. Being continually exposed to the
people who choose those machines, I can tell you several things about them:
1) You don't even want to know how often they choose an IDE based solution
2) They get less sensible when they choose larger machines
3) People are convinced that NT (or Solaris/Linux/Tru64/2000/etc) will
always offer as much power as they need
4) These people still believe in ISA
5) Half of them can't read their own name, let alone the manual
Do you really think they'll bother figuring out that they will really want
some feature that half of them don't even know exists?
Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: cray and time needed to attack
Date: Tue, 11 Jul 2000 17:56:29 GMT
Bob Silverman <[EMAIL PROTECTED]> wrote:
>> I'd be very interested to know how with current technology, it's even
>> theoretically possible to put 10 to 100 terabytes of .3 nsec memory in
>> a device no more than 1 inch in radius. If you can go to Intel or IBM
>> with a coherent proposal, I'm sure they will make you a rich man ;-).
> Imagine! Confusing Mr. Coffin with facts when he was convinced that
> only he was right.
I clearly remember seeing something like this on TV the other day. I
think it was on Star Trek or something. ;)
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 11 Jul 2000 18:01:01 GMT
In comp.arch James Cownie <[EMAIL PROTECTED]> wrote:
> Paul Koning wrote:
>>
>> "Douglas A. Gwyn" wrote:
>> The reason byte access works efficiently is that system buses have
>> byte lane enables so you can selective byte writes *without* the
>> absurd overhead of a read/modify/write sequence.
> Not if you have ECC, then you have to do a read modify write to recalculate
> the ECC. (And any sensible large machine will have at least SECDED nowadays).
Except you do it in the chipset, and the processor still has to only have
byte lane write enables.
> -- Jim
> James Cownie <[EMAIL PROTECTED]>
> Etnus, LLC. +44 117 9071438
> http://www.etnus.com
--
Sander
FLW: "I can banish that demon"
------------------------------
** 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
******************************
