Cryptography-Digest Digest #873, Volume #11 Sat, 27 May 00 20:13:01 EDT
Contents:
AES times on the Alpha 21164 with Parallel encryption (Kenneth Almquist)
CAST Sboxes -- need help (tomstd)
Re: A Family of Algorithms, Base78Ct (wtshaw)
Re: AES final comment deadline is May 15 (Kenneth Almquist)
Re: Free Software (Richard Heathfield)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (Steve)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (jungle)
Re: Another sci.crypt Cipher (Mark Wooding)
Re: list of prime numbers (Tim Tyler)
Source for SHA-1 and Export Control ("Jamie Nettles")
Re: Another sci.crypt Cipher (tomstd)
Re: Another sci.crypt Cipher (Mark Wooding)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (No User)
Re: Source for SHA-1 and Export Control (tomstd)
Re: Base Encryption: Revolutionary Cypher (Tim Tyler)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (jungle)
Re: Matrix key distribution? (Mark Wooding)
Re: Retail distributors of DES chips? (zapzing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: AES times on the Alpha 21164 with Parallel encryption
Date: Sat, 27 May 2000 20:40:56 GMT
In the discussion on hardware timings of the AES candidates, some
posters have suggested that encryption/decryption speed is not a
particularly useful measure of performance because you can get
more throughput from a slow algorithm by performing multiple
encryptions in parallel. While I'm not totally convinced by this
argument, I did do some back of the envelope calculations of the
time required to encrypt and decrypt two blocks in parallel on
the Alpha 21164.
single double quad
RC6/decrypt 894 628
RC6/encrypt 934 648
Rijndael/128 680 660
Twofish 720 700
Rijndael/192 816 792
Mars/decrypt 902 802
Mars/encrypt 956 802
Rijndael/256 952 924
Serpent 1830 1014 1931
The column labeled "single" gives twice the time to encrypt a single
block, and the column labeled double gives the time to encrypt two
blocks in parallel. Twofish and Rijndael are slightly faster in the
parallel encryption mode because they only load the round keys once
for each block. RC6 is significantly faster because when encrypting
a single block there is a large amount of time where the processor
is stalled waiting for the results of the multiply operation. The
same effect also applies to Mars to a lesser degree. Serpent benefits
the most from parallel encryption because it can store two 32 bit
words in each 64 bit register and operate on them in parallel. It
is not quite twice as fast because additional mask operations are
required on the results of shifts in this mode. Also, 6 cycles are
devoted to packing the 32 bit words into registers. For Serpent, I
also give the time to encrypt four blocks in parallel.
The net result is that if parallel encryption is the benchmark, then
RC6 is the fastest on the Alpha 21164, and the gap between Serpent
and the other algorithms becomes much smaller. I should caution
that I haven't put a lot of work into checking these numbers, so
there could be mistakes here.
Kenneth Almquist
------------------------------
Subject: CAST Sboxes -- need help
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 13:43:14 -0700
I have read several of the CAST papers over and over and over
and over, and I can't seem to grasp how they actually made the
32x32 sboxes (using four 8x32) or how their 'permute' function
works to make bijective sboxes.
Any help?
Tom
* 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: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A Family of Algorithms, Base78Ct
Date: Sat, 27 May 2000 14:21:08 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> Certainly you are right in questioning whether it is worthwhile to add
> all sorts of bells and whistles. I like nevertheless to indicate that adding
> a randomly chosen number is a shifting, i.e. akin to a Vigenere in
> principle.
>
> M. K. Shen
It used top be that having lots of component operations, various
primatives and otherwise, was apt to cause more confusion for code clerks
than they were worth; so it is with hand ciphers. Part of neoclassical
thought is that such confusing layers can now be handled in more or less a
streamlike fashion in a good implementation.
That means that while simplicity is preferred if available, with advances
in computer speed, all sorts of madding algorithms can be considered for
their result alone. Likewise, so much unexpected keyspace can be
incorporated, that on cursive ciphertext appearance alone, the attacker
does not have muchof an idea what traps the designer has included.
--
If a privacy policy is longer that 250 words, it is already
deceptive; the longer the more deceptive.
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: AES final comment deadline is May 15
Date: Sat, 27 May 2000 21:43:38 GMT
> Kenneth Almquist <[EMAIL PROTECTED]> wrote:
>
>> In the NIST implmenetations, the cost of changing a key is small
>> but nonzero for Serpent and Twofish, because some time is required
>> to calculate the subkeys for the first round.
>
> For Twofish, the process which generates the round keys is extremely
> similar to that which processes the data, and the two are mixed after
> extremely similar operations are performed on each. The two can be
> performed in parallel, and the key material is ready at just the right
> time.
I believe that the NSA implementation of Twofish does this. The
reason that there is a cost for changing keys is the initial whitening.
In the NSA implementation, the initial whitening and the first round
are performed during the same clock cycle. The whitening key is used
at the start of this cycle, and thus must be computed in advance, rather
than being computed in parallel with the first round. When the cipher
key is changed, it takes a cycle to compute the initial whitening key.
Encryption cannot begin until the following clock cycle.
Kenneth Almquist
------------------------------
Date: Sat, 27 May 2000 23:06:47 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Free Software
George Peters wrote:
>
> There is a suite of encryption products you should explore. There are
> two file encryption systems, client email ftp and messenging
> applications, and some source code. You can get it at
> www.endecs.com/uenigma.exe. It's a self extracting exe and you simply
> run setup.exe after extracting.
>
> This was the product of a now defunct software company. Some of the
> source code is in Visual Basic and it looks like Borland C++ for others.
>
> Would enjoy your comments about the software...My computer gurus think
> it's pretty good stuff!
With the greatest of respect to you and your gurus, most people here
will be rather cautious about downloading an executable file from an
unknown source. If the URL contained the source code 'in clear', that
would be different.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
37 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (60
to go)
------------------------------
From: [EMAIL PROTECTED] (Steve)
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Sat, 27 May 2000 22:15:07 GMT
On Sat, 27 May 2000 17:38:32 +0100, Joe@Joe's.bar&grill.org
wrote:
>And exactly how are they to defend themselves against the constant
>barrage of lies regarding their software? If they do not defend
>themselves, the lies will become truth in the minds of most.
Every EE thread I've seen for weeks now has been started by EE
spam. The only "lies" I have seen have been EE claims that their
stuff defeats forensic software "costing thousands of dollars",
followed by a consistent refusal to name the software they
tested it against.
Fake controversy calculated to draw attention is all I see in the
EE threads. That, and a couple of people who had their system
registy eaten by an early, buggy version of EE, and a bunch of
people pissed off at EE for spamming.
>Make no mistake about it -- some people are out to deliberately
>destroy this product. EE is not merely indulging themselves in the
>art of spamming. I think they are fighting for their corporate life.
If they are fighting for their corporate lives, it is because
they shoot themselves in the foot every time they fire up a news
reader and say, "oh goody free advertising, that's what
newsgroups are for".
Which reminds me to mention:
Eraser does 99% of the job EE does, for free, without added
system overhead. Just add any files and directories you consider
sensitive to the task list, and choose whether to wipe them on
schedule or on demand. http://www.tolvanen.com/eraser/
Remember, a dollar spent with EE, is a vote for spam in
newsgroups.
>I bought it awhile back and use it everyday. I think it's one the
>most indispensable pieces of software I own.
>
>Did it ever occur to you that maybe some of EE's chief detractors wear
>badges?lll
If you have a real reason to worry about people who wear badges,
you better start worrying about your ISP logging all your
internet traffic, and handing over your archived e-mail
(typically four to six months of it), both of which are routinely
done by most ISPs at the request of any officer of the court.
You should also worry about packet sniffers, keyloggers, remote
administration tools, and BTW check your network and file share
settings.
Evidence Eliminator does not eliminate evidence, it just
overwrites files and clears some registry keys. Any advantage
this might present in defending a criminal case, is more than
outweighed by the psychological impact on the jury of the name
"Evidence Eliminator". If you are counting on it to keep you out
of jail, be afraid. Be very afraid.
:o)
Steve
---Support privacy and freedom of speech with---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP keys: RSA - 0x4912D5E5 DH/DSS - 0xBFCE18A9
Both expire 5/15/01
RSA key available on request
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Sat, 27 May 2000 18:45:54 -0400
very cool post, thanks ...
but the EE spam will be ON again very soon ...
Steve wrote:
>
> On Sat, 27 May 2000 17:38:32 +0100, Joe@Joe's.bar&grill.org
> wrote:
>
> >And exactly how are they to defend themselves against the constant
> >barrage of lies regarding their software? If they do not defend
> >themselves, the lies will become truth in the minds of most.
>
> Every EE thread I've seen for weeks now has been started by EE
> spam. The only "lies" I have seen have been EE claims that their
> stuff defeats forensic software "costing thousands of dollars",
> followed by a consistent refusal to name the software they
> tested it against.
>
> Fake controversy calculated to draw attention is all I see in the
> EE threads. That, and a couple of people who had their system
> registy eaten by an early, buggy version of EE, and a bunch of
> people pissed off at EE for spamming.
>
> >Make no mistake about it -- some people are out to deliberately
> >destroy this product. EE is not merely indulging themselves in the
> >art of spamming. I think they are fighting for their corporate life.
>
> If they are fighting for their corporate lives, it is because
> they shoot themselves in the foot every time they fire up a news
> reader and say, "oh goody free advertising, that's what
> newsgroups are for".
>
> Which reminds me to mention:
>
> Eraser does 99% of the job EE does, for free, without added
> system overhead. Just add any files and directories you consider
> sensitive to the task list, and choose whether to wipe them on
> schedule or on demand. http://www.tolvanen.com/eraser/
>
> Remember, a dollar spent with EE, is a vote for spam in
> newsgroups.
>
> >I bought it awhile back and use it everyday. I think it's one the
> >most indispensable pieces of software I own.
> >
> >Did it ever occur to you that maybe some of EE's chief detractors wear
> >badges?lll
>
> If you have a real reason to worry about people who wear badges,
> you better start worrying about your ISP logging all your
> internet traffic, and handing over your archived e-mail
> (typically four to six months of it), both of which are routinely
> done by most ISPs at the request of any officer of the court.
>
> You should also worry about packet sniffers, keyloggers, remote
> administration tools, and BTW check your network and file share
> settings.
>
> Evidence Eliminator does not eliminate evidence, it just
> overwrites files and clears some registry keys. Any advantage
> this might present in defending a criminal case, is more than
> outweighed by the psychological impact on the jury of the name
> "Evidence Eliminator". If you are counting on it to keep you out
> of jail, be afraid. Be very afraid.
>
> :o)
>
> Steve
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another sci.crypt Cipher
Date: 27 May 2000 22:50:02 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> You mean 2^-62.5?
I do indeed.
Actually, I made a mistake, and cryptanalyzed a subtly different cipher
from your TC1. I basically applied the S-boxes in the wrong order.
Having fixed the problem, I can't find a characteristic for the whole
cipher with probability higher than 2^-66.
That said, there are a number of 13-round characteristics which are
looking dangerous. For example, the three-round iterative
characteristics
0: 00000000 0000000c
1: 0000000c 00000000 (0c[0] -> 0c[0], p = 4/256)
2: 0000000c 0000000c (0c[0] -> 0c[0], p = 4/256)
3: 00000000 0000000c
and
0: 00000000 40000000
1: 40000000 00000000 (40[3] -> 40[3], p = 4/256)
2: 40000000 40000000 (40[3] -> 40[3], p = 4/256)
3: 00000000 40000000
are potentially damaging. Both lead to 13-round characteristics with
probability 2^-54. I suspect that there are a number of ways to bypass
the first round and perform a 2R attack to get past the last two. If
that's not possible, you can add another couple of rounds to the
characteristics to get probabilities of 2^-60. Identifying right pairs
in the final round ought to be fairly straightforward.
David Wagner pointed out to me that looking at differentials rather than
characteristics might be profitable. While there are multiple paths for
some differentials, the others tend to have sufficiently much lower
probabilities as to not be worthwhile.
> The best learning "thing" you could do for me right now is
> explain how you found that differential. I have been scratching
> my head all day about it.
Exhaustive search ;-)
The bit permutation was a good idea. In general, it increases the
number of active S-boxes, as you commented in your analysis. However, I
realized that an output difference with low Hamming weight might only
affect the input to a single S-box in the next round; in particular, an
output difference with only one set bit is sure to have this property.
I wrote a quick program to analyze the S-box and permutation and find
such differences, and then search for characteristics for the entire
cipher, totting up (logs of) the probabilities as it went.
> BTWx2 Thanks for the info, I really want to learn from this.
Note that none of my characteristics used characteristics in your S-box
with maximum probability.
> BTWx3 I designed this cipher so I could break it. So I am not
> disappointed it was broken, just that I didn't do it first.
Keep up the good work.
-- [mdw]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: list of prime numbers
Reply-To: [EMAIL PROTECTED]
Date: Sat, 27 May 2000 22:12:32 GMT
Daniel <[EMAIL PROTECTED]> wrote:
: On Thu, 25 May 2000 21:50:00 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
: I'm trying to understand RSA and want to be able to factor a given
: 'public modulus'. Or try it at least ;-)
: If one has a large number (say 150 digits), what are the ways to try
: and break this up into its factors? Where does one start? [...]
One conventional starting point would be, with the "Classical Methods of
Factorisation" chapter of Hans Riesel's "Prime Numbers and Computer
Methods for Factorisation" book.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: "Jamie Nettles" <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,talk.politics.crypto
Subject: Source for SHA-1 and Export Control
Date: Sat, 27 May 2000 23:10:15 GMT
Where could I find source code for SHA-1 and what's the deal on export?
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 16:08:40 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> You mean 2^-62.5?
>
>I do indeed.
>
>
>Actually, I made a mistake, and cryptanalyzed a subtly
different cipher
>from your TC1. I basically applied the S-boxes in the wrong
order.
>Having fixed the problem, I can't find a characteristic for the
whole
>cipher with probability higher than 2^-66.
You mean you can't find 'better or worse' characteristics? I
would imagine if the probability was higher that you found
*better* chars.
>That said, there are a number of 13-round characteristics which
are
>looking dangerous. For example, the three-round iterative
>characteristics
>
> 0: 00000000 0000000c
> 1: 0000000c 00000000 (0c[0] -> 0c[0], p = 4/256)
> 2: 0000000c 0000000c (0c[0] -> 0c[0], p = 4/256)
> 3: 00000000 0000000c
>
>and
>
> 0: 00000000 40000000
> 1: 40000000 00000000 (40[3] -> 40[3], p = 4/256)
> 2: 40000000 40000000 (40[3] -> 40[3], p = 4/256)
> 3: 00000000 40000000
>
>are potentially damaging. Both lead to 13-round
characteristics with
>probability 2^-54. I suspect that there are a number of ways
to bypass
>the first round and perform a 2R attack to get past the last
two. If
>that's not possible, you can add another couple of rounds to the
>characteristics to get probabilities of 2^-60. Identifying
right pairs
>in the final round ought to be fairly straightforward.
I am missing something, you noted three rounds in the char, but
say it is a 13r char for the entire cipher? How does that
work? Is it just a 3r char repeated thru 13r?
>David Wagner pointed out to me that looking at differentials
rather than
>characteristics might be profitable. While there are multiple
paths for
>some differentials, the others tend to have sufficiently much
lower
>probabilities as to not be worthwhile.
What is the "difference" (excuse the wordage) between a
characteristic and differential?
>> The best learning "thing" you could do for me right now is
>> explain how you found that differential. I have been
scratching
>> my head all day about it.
>
>Exhaustive search ;-)
>
>The bit permutation was a good idea. In general, it increases
the
>number of active S-boxes, as you commented in your analysis.
However, I
>realized that an output difference with low Hamming weight
might only
>affect the input to a single S-box in the next round; in
particular, an
>output difference with only one set bit is sure to have this
property.
>I wrote a quick program to analyze the S-box and permutation
and find
>such differences, and then search for characteristics for the
entire
>cipher, totting up (logs of) the probabilities as it went.
So you basically tried random bit patterns and observed the
output difference?
Here's a question: If I did two convolutions per round say
a = a ^ F(F(b ^ k[...]))
Would the characteristic remain?
Independantly I tried expanding the sboxes so that each of the
four sboxes occur four times in the output (instead of one) in
different bit orders... For example one of the 8x32 sboxes may be
a0a1a2a3a4a5a6a7, a7a5a6a4a1a3a2a0, etc..
Then I xor'ed them together, however I found that there was
still a good input difference (namely (0, 0x00000000c)) with an
output difference prob 1.
I can't figure that out, is it because I am just repeating the
same four sboxes over and over?
>> BTWx2 Thanks for the info, I really want to learn from this.
>
>Note that none of my characteristics used characteristics in
your S-box
>with maximum probability.
The best input-output xor is 8/256 or 2^-5, but your char
(above) has a probability of 2^-6, so it's not the "best" that
could be done.
>> BTWx3 I designed this cipher so I could break it. So I am not
>> disappointed it was broken, just that I didn't do it first.
>
>Keep up the good work.
I shall, and thanks for helping.
Tom
* 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: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another sci.crypt Cipher
Date: 27 May 2000 23:14:45 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Mr. Wooding,
Do we have to be so formal? ;-)
> Can you clear up my confusion?
Yes. It's easy. I made a mistake. (See my follow-up to Tom elsewhere
in the thread.)
-- [mdw]
------------------------------
Date: Sat, 27 May 2000 17:22:54 -0500
From: No User <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Joe@Joe's.bar&grill.org wrote:
> Did it ever occur to you that maybe some of EE's chief detractors wear
> badges?lll
I must admit this makes a great deal of sense.
Do I lose face if I agree with you and retract what I just said?
I think I'd better stick to reading in the future.
------------------------------
Subject: Re: Source for SHA-1 and Export Control
From: tomstd <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,talk.politics.crypto
Date: Sat, 27 May 2000 16:27:25 -0700
In article <rBYX4.2265$[EMAIL PROTECTED]>, "Jamie
Nettles" <[EMAIL PROTECTED]> wrote:
>Where could I find source code for SHA-1 and what's the deal on
export?
Hmm Ask Mike Rosing he has a copy on his website.
And there is no issues, SHA-1 is not a cipher.
Tom
* 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: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Revolutionary Cypher
Reply-To: [EMAIL PROTECTED]
Date: Sat, 27 May 2000 22:36:34 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> You can probably observe avalanche in one base, and not in another -
:> though changing base usually affects diffusion /mainly/ in one direction.
[snip example]
: When one talks about avalanche (without qualification), one commonly
: means the general case, i.e. not restricting to a particular region of bits.
: So if avalanche is observed or not observed in one base (the first with
: the existence and the second with the all quantor) the same must hold
: in the other base (possibly at different intensity, though), I believe.
Wellll, changing base does itself create effects rather reminiscent of
avalanche.
If you change a highly significant digit in base 10, and convert the
original number - and the modified version - to base 11, and compare, the
result may appear to be much like like an avalanche, affecting the
lower digits.
Performing this type of base change "in both directions" (i.e. reversing
the number in between application) might well result in something that
looked like a good avalanche (i.e. flipping any digits affects the entire
result) - but undoing the second base change would reveal the biases
present as a result of the first change of base.
In the end it boils down to what you call an avalanche. Do you allow
structures which show deviations from correct balance of digits in some
bases as not being "genuine" avalanches?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Legalise IT.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Sat, 27 May 2000 19:42:41 -0400
don't rely on assumption ...
use your common sense in estimating what are the minimum requirements for
assessing security product to be able to pass minimum level ...
when it can't pass YOUR minimum level ...
will assumption base on "EE's chief detractors wear badges?" affect the REAL
security evaluation ?
for intelligent person, any criticism is only "criticism" and not bushing of
the product ...
when person is asking question, he likes to find answers, answers that will
make him more secure, when provided answer is not making him feel more secure,
this is the point of reflection ...
No User wrote:
>
> Joe@Joe's.bar&grill.org wrote:
>
> > Did it ever occur to you that maybe some of EE's chief detractors wear
> > badges?lll
>
> I must admit this makes a great deal of sense.
> Do I lose face if I agree with you and retract what I just said?
> I think I'd better stick to reading in the future.
don't feel intimidated by others ...
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Matrix key distribution?
Date: 27 May 2000 23:33:06 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Encryption things? Sort of... Someone recently came up with a cipher
> called "Storin" and posted it to this NG
That would probably have been me. It's a block cipher which uses a
matrix multiplication over the integers mod 2^24 for its nonlinearity
and main diffusion, and some other stuff to clear up loose ends and
improve resistance to attack. It mixes integer arithmetic with XOR in
order to gain security.
> and I recall someone mentioning something called "Hill's algorithm,"
The Hill cipher is a `classical' cipher based around a single
multiplication by a key matrix.
-- [mdw]
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Sat, 27 May 2000 23:51:08 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Even his (Spencer's) conclusion is suspect. Peer review of the
hardware is
> necessary as demonstrated, but it is not sufficient due to the
possibility of
> features hidden in the tools that process the hardware design. I'm
specifically
> referring to capabilities such as the compromise of the Unix login
command that
> was hidden inside the C compiler.
>
> It may be harder to recognize a DES or 3DES core that it is to
recognize login.c,
> but it isn't hard enough to make it impossible in practice. If the
crypto core
> exists in a library of such designs and the library was distributed
with the
> hardware design tools it would not even be difficult.
>
wow, excellent point. How would you know that your
version of "SPICE" (or whatever you use) had not
been tampered with. You could write your own tool,
in *obfuscated* code, but if you were going to do
that, why notjust write your crypto code in
*obfuscated* source code, so that the (presumably
malicious) operating system would not know what
to do with it.
You would still have to do the trial decrypt,
but that sould be on another system in more
obfuscated code. You should also give your
system "trick questions" in the form of stuff
that should *not* decrypt properly. If it
does you know there's a problem.
Needless to mention, you should not have a
hard drive on your system at all, Keep the OS
on a CD, and have huge amounts of RAM and a
JAZ drive, to hold the encrypted "work files".
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
