Cryptography-Digest Digest #891, Volume #10 Wed, 12 Jan 00 17:13:02 EST
Contents:
Re: Little "o" in "Big-O" notation (Mike McCarty)
Re: 8-round Blowfish (Albert Yang)
Re: Intel 82802 Random Number Generator (Scott Nelson)
Re: AES & satellite example (David Wagner)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Is SSL really this slow? (Greg)
Re: LSFR (Scott Nelson)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Xcott Craver)
Re: Modular Inverse with RSA ([EMAIL PROTECTED])
Re: Wagner et Al. ("John E. Kuslich")
Re: Intel 82802 Random Number Generator (Guy Macon)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Guy Macon)
Re: AES & satellite example (Jerry Coffin)
Re: Cryptanalysis ("Douglas A. Gwyn")
Re: Wagner et Al. (Guy Macon)
Re: Wagner et Al. ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Little "o" in "Big-O" notation
Date: 12 Jan 2000 20:00:29 GMT
In article <8591f5$u8v$[EMAIL PROTECTED]>,
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
)
)Jeff Moser <[EMAIL PROTECTED]> wrote in message
)news:858nb6$bdo$[EMAIL PROTECTED]...
)> What exactly does the little "o" in "Big-Oh" notation mean? For example, I
)> know that o(1) becomes negiligible as the integer approaches infinity. I'm
)> uncertain on how to define it.
)
)o(f(x)) = g(x) is true iff:
[snip]
One of the rules for use of o(.) and O(.) is that neither of them is
permitted to appear on the left hand side of an equal sign.
Mike
--
----
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: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: 8-round Blowfish
Date: Wed, 12 Jan 2000 20:26:17 GMT
Blowfish was designed with 16 rounds for a reason, in Bruce's head,
probably a decent margain of safety was added in there. Additional
rounds don't solve the problem if there are weaknesses in the overall
design of the algorithm. I'm not saying blowfish has design weaknesses,
just saying that adding rounds don't help if it does. We can't really
know how secure it is, it will gain more and more confidence as the
analysis for it continues and it holds up. DES has had more eyeballs on
it than any other algorithm. So I trust it in the sense that people
have looked at it and studied it, and know that there are no backdoors
or huge flaws.
Is Blowfish more secure that DES? Only time will tell. From a math
point of view, yes. But who's to say that someone won't come out with a
Blowfish cracker tomorrow?
Albert
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Intel 82802 Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jan 2000 20:34:40 GMT
On 11 Jan 2000 11:22:08 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>(The correct name of the chip in question is the Intel 82802 Firmware Hub.
>The Intel 810 chipset contains a 82802, but so do the 820 and the 840, and
>Intel will doubtless use this chip in future chipsets.)
>
>>Scott Nelson wrote:
>>
>>>Bradley Yearwood wrote:
>>>
>>>> ... which appears to indicate a worst-case rate of
>>>>random byte production of around 222 bytes/sec.
>>>>
>>>Actually, the worst case is infinite,
>>>but the _average_ is claimed to be 75Kbits per second.
>>>The odds against having to wait 4.5ms are extreme,
>>>thus the recommendation that if you have to wait longer
>>>than that, you should give up and assume there's a problem.
>
>Cryptography Research, Inc. has a paper showing the internals.
>
>[ ftp://download.intel.com/design/security/rng/CRIwp.pdf ]
>
>I was right about there being a state machine, but not about it
>doing SHA1 (most of the docs don't make it clear that the SHA1
>is to be done in software, but the it's there if you look hard).
>The state machine contains (along with the cell programming logic)
>a Von Neumann corrector with the following truth table:
>
>zero followed by zero equals no output
>zero followed by one equals one
>one followed by zero equals zero
>one followed by one equals no output.
>
>Clearly a long string of all ones or all zeros is possible but not
>probable, which makes long delays possible but not probable.
>
>Some of the docs imply an 8 bit buffer, but this paper says that
>the buffer is 32 bits fed by a 75Kbps (average) bit stream. It's an
>interesting security question whether the OS or application should
>have a FIFO buffer of this stream that might be read by an attacker.
>
>The Von Neumann corrector outputs an average of one output bit
>for every 6 input bits. I believe that a true random input
>stream would have a 4:1 ratio, not 6:1. I am a crypto newbie but a
>electronics engineering expert, and given the method described, a
>corrolation between sucessive bits before the Von Neumann corrector
>doesn't suprise me.
>
An unbiased input stream would have a 2:1 ratio.
If it were an unfair coin, 6:1 implies a 2:8 ratio
of heads to tails. However, it's not an independent stream.
The input bits to the Von Nuemann rejector are correlated.
Correlation can range anywhere from a minor annoyance
to a major problem.
On the minor annoyance end, we're told that the output
even after correction has a slight bias. If that's the
only problem, then one could use the bits as is for
a key. The keyspace would be reduced, but not significantly.
On the major annoyance end, the "sameness" correlation could
be specific to the tested device. Some devices might
have a "not the same" correlation, and only reject 1/3 of the
pairs, instead of passing 1/3. These devices would produce bits
at twice the rate, but the bits would have a bias of about .6
Using the bits directly would reduce keyspace dramatically.
I note the CRI claims that an oscillating state (which would
produce an output of 10101010...) is theoretically possible,
but unlikely. I wonder how likely a semi-broken state of
_mostly_ 10101... is.
>I was glad to see that Intel is *not* using the thermal noise of
>a resistor as a source for the raw bits, but is rather using the
>difference between two such resistors. Matching of resistor
>characteristics on a single die tends to be very good, and external
>electromagnetic fields are (imperfectly) rejected. The small
>physical size of an onchip solution also helps by making the
>effective loop area of the internal parts small, which makes
>them poor antennas.
>
Well, it looks good on paper.
It's probably even a good trade-off. However,
theoretically there's more entropy without it.
It does improve the noise to signal ratio,
but at the expense of reducing the absolute noise.
>Could one of you fellows who know more about crypto take a look
>at the way Intel suggests doing the SHA1 and comment on it?
>It seems that you could write a device driver to get at the output
>of the chip and then use whatever method you choose.
>
There are a couple of problems with the software layer.
They don't collect enough entropy between mixes to
really protect the bits, and the internal state is
used directly. In theory, an active attack can
recover the entire internal state of the RNG,
at a cost of about 2^32 SHA1 hashes.
Since the speed of generation is probably
unacceptably slow anyway, it's unlikely that
software would use the bits directly, so these
problems are unlikely to really be problems.
These problems are discussed in more detail
on the Yarrow home page.
( http://www.counterpane.com/yarrow.html )
>[ ftp://download.intel.com/design/security/rng/CRIwp.pdf ]
I think my favorite line in that paper is
"Similar RNG designs using independent oscillators
are well known." Yes they're well known.
They have a well known history of being a lot worse
than the designer originally thought.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: AES & satellite example
Date: 12 Jan 2000 12:32:44 -0800
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <85h5qo$si6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > I was thinking that this might help a lot. The special algorithms
> > used for code uploading will be used only very rarely, and are not
> > performance-intensive, so they could be (e.g.) 1000 rounds of Triple-DES,
> > if you like.
>
> Unfortunately, 1000 rounds of triple-DES isn't any more provably
> secure than what we started with. In fact, it might even be less
> secure for all we really know.
Agreed. I'm not claiming that 1000 rounds of Triple DES is provably
secure; it's clearly not. The point is that it's probably secure --
or, at least, it's more likely to be secure than the bulk data encryption
cipher you use which was designed to run at ultra-high speed (potentially
at the cost of security). Thus, you can expect that even if you need
to replace the bulk cipher, the 1000 rounds of Triple DES might still
remain secure.
Anyway, here you say it's not provably secure; later you say that
provable security is irrelevant, because it requires a far-fetched
scenario to be of any importance. Which is it?
> The whole basic notion is fundamentally flawed in any case: as was
> stated to start with, the extra storage for multiple algorithms is
> insignificant as long as you're dealing with a software
> implementation.
Hmm. Storage doesn't help if you want to be able to switch to
an algorithm chosen after the satellite has been launched into space.
Remember, this is about switching ciphers *after deployment*.
> If you use something like a one-time-pad, you might be able
> to argue that it would be secure, but this has yet another problem:
> you have to include something like ROM to hold the pad. That ROM has
> to be as large as all the code you'll ever attempt to transmit. If
> you're going to include a ROM large enough to hold, say, 5 different
> algorithms, why not just put 5 algorithms in the ROM?
Well, maybe 20 years from now, when we know more about algorithm
design and analysis, we might want to change the deployed cipher to
the latest and greatest design (Thirteen-fish?).
Remember, one-time pad keys can be pre-arranged, many years before
the communication takes place. So your argument misses the point:
yes, the new cipher might be small enough that we could have fit it
in ROM if it were available when the satellite was launched, but in
some cases, we might want to change to a cipher that was not available
(or adequately trusted) at launch time.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Wed, 12 Jan 2000 21:50:07 +0100
Tim Tyler wrote:
>
> :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> :> : I am not quite sure whether one couldn't even attempt to 'define'
> :> : the 1-1 problem away with a 'convention'. That is, if on compression
> :> : the last code symbol does not fill to a byte boundary, then the
> :> : software has to do filling with bits that do not form a valid code
> :> : symbol and it is 'required' by convention that the filling is
> :> : to be random, say dependent on the system clock. [...]
> :>
> :> This is pretty much the same technique as John Savard proposed.
> :>
> :> It works to the extent that you can generate genuinely random bits.
> :> If your bits are not completely random then you still have problems.
> :>
> :> You also wind up with a non-deterministic compressor. The system
> :> fails to exploit the range of the compressor to itsgreatest possible
> :> extent. It is no longer portable to embedded environments with no
> :> obvious reliable source of genuinely random noise available.
>
> : No.
>
> Yes.
My 'No' was intended to negate your 'no longer portable', not
'non-deterministic'. Tell me in what sense the software is not
portable? Can it not be run or what? It compresses and decompresses,
always neglecting the 'meaning' of the filling bits. If it runs
on 'non-embedded' systems o.k., why should it not run on an 'embedded'
one? What is your definition of an 'embedded system'?
>
> : Whether the software on two runs of compression put in the
> : same bunch of (supposedly) random bits is of no significance.
>
> It makes little difference to security - if the padding is genuinely
> random. But it may not be of *no* significance overall. For example it
> prevents the end user from checking whether two files deccompress to
> identical results by using the "diff" program on the compressed files.
> Very few things are of no significance at all.
I mean the 'significance' in the context which Scott raised with
his 1-1 concept. In that context the difference is of no significance,
because it tells the analyst nothing (and in fact
it tells him nothing for the very reason that there are very
often differences.) Besides, did you actually mean 'compress'
insteaed of 'decompress' in your last but one sentence above?
(Decompressing is by construction o.k.! Only the compressed files
may be different due to the different filling bits. If you want
to check whether two compressed files have the same 'content',
decompress these and then apply the 'diff'.)
>
> As a sample security concern, compressing the file and encrypting it
> will no longer produce the same result.
>
> This means if the file gets lost and you have not stored a local copy you
> may wany to recompress and reencrypt, using the original key.
Normally
> this will involve few security problems, as eavsdroppers gain little
> additional information from the identical cyphertext. However a "random"
> compressor ending gives them two files, encrypted with the same key, with
> a few bits of plaintext differing between them.
If you have a 1-1 compressor and 'the file gets lost and you have
not stored a copy', what do you do? You have to do the same amount
of work, don't you? What is the 'plaintext' of 'a few bits of
plaintext differing ...' above? Isn't that what you called 'plaintext'
random? So what kind of information the analyst possibly could
get from that random stuff? Could you give some detailed description
of how he could exploit such random 'plaintexts'?
> This may give the attacker information about - for example - the block
> size being used, which he did not have from the original message alone.
What do you mean by 'block size' here? In the context of Scott, if
the analyst uses a wrong key, then the number of characters obtained
on decompression (the undecodable last bits are discarded anyway
in my proposal) is in general different from the number of characters
of the correct plaintext in the first place, even if a 1-1 compressor
is used. So how is he going to derive the block size? Could you
please explain that? Thanks.
M. K. Shen
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Is SSL really this slow?
Date: Wed, 12 Jan 2000 20:55:28 GMT
In the process of integrating SSL into some software that uses
sockets, I was surprised to see more than a 10 fold decrease in
speed. At this time, my testing is allowing all traffic to be
encrypted. Most of it does not need to be, but it is impossible
for our software to distinguish between standard marshaling packet
information and any confidential data that is embedded in the
packets, since we are approaching this integration at a low level.
So my question is this: If I were to transmit 250k across a wire
and it took about one second, is it reasonable to assume that
SSL can slow this transmission down to require 10 seconds? Or
is this too slow that I am most likely doing something wrong?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: LSFR
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jan 2000 21:17:02 GMT
On Wed, 12 Jan 2000 Mike Rosing <[EMAIL PROTECTED]> wrote:
>Michael Darling wrote:
>>
>> We wish to use an LSFR to generate a time stamp for an electronic component
>> we are designing.
>>
>> The idea is to use a very simple 2 tap LSFR which is 49 bits long with taps
>> at bit 9 and bit 0.
>> This would provide us a nice non-repeating sequence which we could use to
>> uniquely identify each stamp.
>>
Minor quibble. The sequence repeats after 2^49-1 steps.
>> Now then: We want to say when each stamp occurred, i.e. map each output to
>> its location in the sequence.
>>
>> In other words we want to get an output and say that it is output 'n' in the
>> sequence.
>>
>> Obviously, we don't want to run through the sequence in software and match
>> the output we got from the
>> hardware - as this could take some time :)
>>
>> Are we being naive to expect that we can do this, or is there a method that
>> we don't know about?
>
>First off, it has to be a 3 tap sequence, without the most significant
>bit you only have a 2^9-1 (=511) repeat pattern, if x^9 + 1 is prime.
>(It can't be, but I'll leave the proof to you.)
If x=1, then x^9+1 is prime.
He's obviously running the shifter in the opposite direction.
It would be more conventional to say he's using 0, 40 and 49.
Which does produce a maximal length sequence. (So does
{0,22,49}, {0,27,49}, {0,15,49}, {0,34,49}, {0,12,49},
{0,37,49}, and {0,9,49} )
It's fairly easy to calculate what the state will be after N shifts.
Going the other way is less obvious, but clearly possible.
If nothing else, you can construct a massive table and get it
in a single lookup. You can trade off calculation size
for table size - store every 2^24th entry and check the
next 2^24 states against the table.
Warning! Shameless plug for my lfsr program -
ftp://helsbreth.org/pub/helsbret/random/lfsr.exe
and the C source to it.
ftp://helsbreth.org/pub/helsbret/random/lfsr_src.zip
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 12 Jan 2000 21:10:40 GMT
Mike McCarty <[EMAIL PROTECTED]> wrote:
>Tony T. Warnock <[EMAIL PROTECTED]> wrote:
>)
>)There is no English word with gh at the beginning of a sylable that has the
>)f sound. There is only one word with o as a short i. There are no words in
>
>This is dialectally dependent. For example, "persimmon" is in some
>American english dialects pronounced "persimmin".
It's hard to distinguish with vowels that short (in the time
domain,) but lots of words ending "on" are pronounced "in"
by some people. "Bacon" is another example. Mmmm, Bacon!
-Scott
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Modular Inverse with RSA
Date: Wed, 12 Jan 2000 21:17:46 GMT
> Hum.... Is it possible that more than one private key exist???? I can
> see that the integers 4239, 7459, 10 679, 17 119, 20 339, 23 559, and
> maybe others satisfy the "ed mod Phi(n) = 1" relation.
>
> Frank
Yes, it is possible, but if you do "d mod Phi(n)" you will find that
they are all going to be 1019, so in effect they are the same key.
For the poster of the original message:
I was trying to figure out that same problem and found this alogrithm
but I don't remember where:
Extended-Euclid(a,b)
if b=0
then return(a,1,0)
(d',x',y')=E-E(b,a mod b)
(d,x,y) = (d',y',x'-(a/b)y')
return(d,x,y)
what this alogrithm will give you is ax+by=d, if d is +/-1 then the key
exists, otherwise it should be 0.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Wed, 12 Jan 2000 14:32:59 -0700
I found an interesting article today.
http://www.phrack.com/search.phtml?view&article=p55-5
hmmm....
So how secure IS NT??????
JK
Guy Macon wrote:
>
> In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (lordcow77) wrote:
> >
> >On a properly administered Windows NT system, to say nothing of *nixes,
> >a trojan will not have the access rights neccesary to modify system
> >files, access files which the ACLs forbid, enter the memory space of
> >another process, or intercept system messages or events not intended
> >for it. It's a pretty difficult task to get a NT system that secure,
> >especially if you have any type of reasonable server install, but it's
> >entirely doable in a day or two (unless you burn disk images onto CD
> ><grin>).
>
> I never managed to get this to work. I can boot from the NT disc
> when my HD is 100% wiped (no MBR, no boot record, nothing but zeros
> everywhere), but I never got NT to boot from the CD. I had the same
> problem trying to get NT to boot from a Jazz drive. I haven't spent
> much time on the problem, so maybe it's simple.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 82802 Random Number Generator
Date: 12 Jan 2000 16:44:33 EST
(Discussing paper at ftp://download.intel.com/design/security/rng/CRIwp.pdf )
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Scott Nelson)
wrote:
>An unbiased input stream would have a 2:1 ratio.
>If it were an unfair coin, 6:1 implies a 2:8 ratio
>of heads to tails. However, it's not an independent stream.
You are correct. I made a mistake when tyuping in the
paragraph.
>The input bits to the Von Nuemann rejector are correlated.
>Correlation can range anywhere from a minor annoyance
>to a major problem.
If (questionable assumption!) the *only* bias was an adjacent
bit correlation of the input bits to the Von Nuemann rejector,
the output bits would be unbiased. The nature of the method
used (Fast & slow phase locked loops with disturbance from
thermal noise source) is to have a strong adjacent bit
correlation that is in thery perfectly correctable by a Von
Nuemann rejector. (This does NOT imply that there aren't
plenty of other kinds of bias in there that are not so easy
to correct!).
>On the minor annoyance end, we're told that the output
>even after correction has a slight bias. If that's the
>only problem, then one could use the bits as is for
>a key. The keyspace would be reduced, but not significantly.
It's interesting that, just as you can't prove that something
is random, you can't prove very small biases. Consider a series
of perfect coin tosses. The oft stated theory is that such a
series would approach a head/tail ratio of exactly 0.5 as the
number of tosses increases. So let's say that I do four flips
and get H H T H. I now have two more heads than tails. If
I start my long series of flips at this point, would it not
in theory aproach a head/tail ratio of exactly 0.5 plus two
additional heads as the number of tosses increases? But I am
still running my original experiment, which predicts no such
bias! Excuse me... My brain just exploded. Good thing that I
don't need it to post in newsgroups...
>On the major annoyance end, the "sameness" correlation could
>be specific to the tested device. Some devices might
>have a "not the same" correlation, and only reject 1/3 of the
>pairs, instead of passing 1/3. These devices would produce bits
>at twice the rate, but the bits would have a bias of about .6
>Using the bits directly would reduce keyspace dramatically.
>
>I note the CRI claims that an oscillating state (which would
>produce an output of 10101010...) is theoretically possible,
>but unlikely. I wonder how likely a semi-broken state of
>_mostly_ 10101... is.
I thought that they said that such a state would pass the corrector
without offering an opinion as to the likelyhood, which is a question
for solid stae physycists, not crypto experts.
In the larger sense, if your RNG cannot produce very long strings
of 1111..., 0000.... 101010.... etc. then it is by definition biased.
A true RNG just might output the complete works of Mark Twain someday.
>
>>I was glad to see that Intel is *not* using the thermal noise of
>>a resistor as a source for the raw bits, but is rather using the
>>difference between two such resistors. Matching of resistor
>>characteristics on a single die tends to be very good, and external
>>electromagnetic fields are (imperfectly) rejected. The small
>>physical size of an onchip solution also helps by making the
>>effective loop area of the internal parts small, which makes
>>them poor antennas.
>>
>Well, it looks good on paper.
>It's probably even a good trade-off. However,
>theoretically there's more entropy without it.
>It does improve the noise to signal ratio,
>but at the expense of reducing the absolute noise.
I don't understand the reasoning behind this. Could you
explain further? Wait a minute... I see you posted a URL.
ignore any questions that are answered there. I will read
it today.
>( http://www.counterpane.com/yarrow.html )
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 12 Jan 2000 16:54:52 EST
In article <85iqkg$bmv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Xcott Craver)
wrote:
> It's hard to distinguish with vowels that short (in the time
> domain,) but lots of words ending "on" are pronounced "in"
> by some people. "Bacon" is another example. Mmmm, Bacon!
I pronounce my name Guy (as in Eye) Macon (as in Make Un-well).
I get a lot of variations along the "in" "on" "un" spectrum.
People have trouble writing it down correctly when I say it on
the phone. What prouounciation would be better? I have had
some success with GEE (G as in Good, EE as in Free) MAH-SEE-ON
(MA as in Matter, SEE as in Seeing, ON as in On/Off). (French)
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Wed, 12 Jan 2000 14:58:20 -0700
In article <85iodc$8ll$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Anyway, here you say it's not provably secure; later you say that
> provable security is irrelevant, because it requires a far-fetched
> scenario to be of any importance. Which is it?
I'm saying that this isn't provably secure, isn't really even a whole
lot more likely to be secure than the other possibilities, and even if
it was, I'm not convinced that it would do a lot of good anyway.
[ ... ]
> Remember, one-time pad keys can be pre-arranged, many years before
> the communication takes place. So your argument misses the point:
> yes, the new cipher might be small enough that we could have fit it
> in ROM if it were available when the satellite was launched, but in
> some cases, we might want to change to a cipher that was not available
> (or adequately trusted) at launch time.
This is not a point I missed. In fact, it's one I addressed directly.
You'd want to do this if you had reason to believe that all the
ciphers you could include at launch time were at least somewhat likely
to be broken. I'm convinced that this possibility is so remote that
there's nothing to be gained by trying to design against it.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis
Date: Wed, 12 Jan 2000 21:59:17 GMT
Todd Smith wrote:
> Does anyone know of a newsgroup or mailing list that deals only with
> cryptanalysis, specifically the paper-and-pencil kind?
I'm not aware of one on line, but the American Cryptogram Association
(publisher of The Cryptogram) has a Web site.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 12 Jan 2000 17:00:07 EST
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Burma120) wrote:
>
>In article <85gumj$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Guy Macon) wrote:
>> I never managed to get this to work. I can boot from the NT disc
>> when my HD is 100% wiped (no MBR, no boot record, nothing but zeros
>> everywhere), but I never got NT to boot from the CD. I had the
>> same problem trying to get NT to boot from a Jazz drive. I haven't
>> spent much time on the problem, so maybe it's simple.
>
>We have a group of many identical machines all running Windows NT
>Workstation. Certain users have an amazing ability to screw up their
>computers because idiotic policies allow the head of a department to
>have local administrator permissions at all of the computers in his or
>her group. We took an identical machine and installed a base
>configuration that is updated and patched. Using customized software,
>we create images (byte for byte, sector for sector) that we burn on to
>currently three CDs. We boot from these CDs and the extractor handles
>the details of clearing out the previous disk and transferring the disk
>image to the hard drive. Next, the program generate new randomized IDs
>for each computer that it is installed to so that NT works correctly.
>Quite a pain to setup, but infinitely better than going around with a
>binder filled with CDs in hand.
I did the same. There is a MS knowledge base article that explains
it very well. You can also make it one CD that gets a base system up
and then updates from the network.
Alas, for the kind of protection against trojans I was hoping for,
the executables that make up NT should run from a CD-ROM (so they
cannot be modified by any program). That I have not been able to do.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Wed, 12 Jan 2000 22:03:17 GMT
"John E. Kuslich" wrote:
> So how secure IS NT??????
Windows NT 4.0 has less severe security problems than Windows 98,
not that that is saying much. It can be configured to be fairly
secure (relative to most OSes in general use), but usually isn't.
------------------------------
** 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
******************************
