Cryptography-Digest Digest #858, Volume #10 Fri, 7 Jan 00 00:13:01 EST
Contents:
Re: How to pronounce "Vigenere"? (Thanks to all!) (Michael Groh)
Re: frequency analysis with homophones ("r.e.s.")
Re: frequency analysis with homophones ("r.e.s.")
Re: Wagner et Al. (Steve K)
Re: Please Comment: Modified Enigma (Paul Rubin)
Re: How about this for a "randomly" generated bitstream? (Guy Macon)
OT Re: letter-frequency software (William Rowden)
Re: How to pronounce "Vigenere"? (Guy Macon)
Re: Anagram (Scott Fluhrer)
Re: Truly random bistream (Guy Macon)
Re: RSA encrypt (Scott Fluhrer)
Re: Square? (Scott Fluhrer)
Re: Anagram (William Rowden)
Just a little help please... ("John C.")
Re: Unsafe Advice in Cryptonomicon (Guy Macon)
Re: Wagner et Al. (Guy Macon)
Re: frequency analysis with homophones (Jerry Coffin)
Re: Wagner et Al. (Guy Macon)
Re: Square? ("Joseph Ashwood")
Re: Wagner et Al. ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Groh)
Subject: Re: How to pronounce "Vigenere"? (Thanks to all!)
Date: Thu, 6 Jan 2000 20:36:50 -0500
I got it! "Vee zun aire" seems about right. Thank you all.
- Mike
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> I know this is a silly question, but I don't speak French and I'm giving
> a paper that references the Vigenere cipher. I've never heard this name
> pronounced, having only read about it in many different sources.
>
> Would somebody provide me with the phonetic pronunciation of "Vigenere"
> (as an English-speaking person might pronounce it).
>
> Thanks very much!
>
> - Mike
>
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Thu, 6 Jan 2000 18:11:55 -0800
"David Wagner" <[EMAIL PROTECTED]> wrote ...
: r.e.s. <[EMAIL PROTECTED]> wrote:
: > The context is cryptanalysis of a substitution cipher which we
: > suppose to be "monoalphabetic" and "homophonic".
:
: You might look at digraph statistics.
: (I don't have any experience breaking this type of cipher, but this is
: one of the approaches I'd try if I needed to.)
:
: If s,t are two possible substitutes for the same plaintext letter, then
: the digraphs su and tu should occur with roughly the same frequency, for
: all u. Conversely, if s and t don't represent the same plaintext letter,
: I'd guess these statistics probably will differ considerably.
:
: This suggests defining a `Measure of Similarity' between s and t by
: computing (say) a chi-squared test of similarity for the distributions
: D(u) = Prob[su] and D'(u) = Prob[tu], and then trying to group the
: ciphertext symbols into equivalence classes that maximize the total
: measure of similarity.
:
: An alternative approach, which may be useful here, is to use Hidden Markov
: Models. Let the (hidden) internal states be the set of plaintext symbols,
: with transition probabilities given by the digraph statistics of the
: plaintext source, and then the probability of outputting the ciphertext
: symbol c at state labelled by plaintext letter p is 0 if c can't represent
: p, or 1/n if c is one of the n representatives of p. (The latter
probabilities
: are of course unknown to the cryptanalyst.) The problem is now to
: approximately compute the sequence of internal states corresponding to a
: given ciphertext, and I believe standard Hidden Markov Model algorithms
can
: solve this problem for you.
Thanks for the ideas with respect to digraph distributions --
I'll be reading up on Hidden Markov Model algorithms.
(The question about frequency subtotals (in the admittedly simple scenario)
arose as follows: In some cases these subtotals, divided by the overall
number of ciphertext symbols, seem to agree extraordinarily well with the
ranked p(i) that correspond to the common approximations for the frequency
distribution of English letters. It's then a question of statistics to ask
the degree to which this appearance supports the hypotheses that were made
about the structure of the substitution table.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Thu, 6 Jan 2000 18:34:29 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in ...
: r.e.s. wrote:
: > The context is cryptanalysis of a substitution cipher which we
: > suppose to be "monoalphabetic" and "homophonic". Specifically,
: > for any given letter of plaintext -- suppose there are I different
: > such letters -- any one of J different ciphertext symbols is
: > substituted at random. We envision this as a table-lookup in which
: > row(i) of the table contains the J possible substitutes for letter(i)
: > of the plaintext alphabet, and we suppose the I plaintext letters
: > (rows) occur with probabilities p(i), i=1..I.
I appreciate your following comments, but in the present case
it's not a question of how best to design a substitution table.
Rather, I'm trying to get a handle on why in certain cases the
frequency subtotals (of a cipher of unknown design), divided
by the total number of ciphertext letters, agree so well with
the ranked p(i), these coresponding to the common frequencies
found for English letters (I=26). The question is a statistical one
as to whether the agreement is merely coincidental or is actually
due to the substitution table being as simple as hypothesized.
: Do you mean each of the I letters is mapped to J letters and J
: is a constant?
Right, I mean a fixed IxJ table of J different ciphertext symbols
for each of I different plaintext symbols; that is, IxJ total
ciphertext symbols overall.
: That wouldn't give you a good homophone substitution.
: The higher frequency letters of the I letters should have
: proportionately more substitutes than the low frequency one such
: that the entire set of the output letters have more or less equal
: frequencies. Because of the discrete nature you can't arrange to
: have exact equality of output frequencies. Nor is this necessary
: in practice, since your frequency data are normally obtained from
: some 'representative' text file but you particular piece of message
: to be encrypted may more or less deviate from that in frequencies
: anyway.
:
: To achieve the said 'approximate' equality of output letter
: frequencies is not difficult. It only involves some trial-and-error
: computation work.
:
: If instead of 'monoalphabetic' you employ 'polyalphabetic'
: homophonic substitutions and the number of columns of the
: substitution table is large enough, you might in my humble view
: even relax to some extent the frequency equality requirement of
: each column.
:
: M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Wagner et Al.
Date: Fri, 07 Jan 2000 02:52:05 GMT
On Thu, 06 Jan 2000 14:38:13 -0800, lordcow77
<[EMAIL PROTECTED]> 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>).
Of course we are only talking about "remote access trojans" acquired
by mistake. Some spooky guy could come in physcially with a DOS boot
disk and some batch files & utilities, and ruin your whole day. Visit
one, your whole configuration is determined. Visit two, your whole
security model is compromised. Visits 3 & onward, are via any chosen
newtwork and/or OS hole that was installed during visit two. It ain't
a question of whether it can be done, it is a question of whether
anyone would spend the time & money required.
I think we all aim for "perfect" security as a matter of form, but it
is also important to acknowledge that perfect security is never
actually obtained. If it were, obscurity would be an integral part of
it, and the complete methodology would never be published here or
anywhere else. <grin>
IMO the realistic question is, how does PeekBoo stack up against other
stuff, and especially PGP? Again IMO, PGP can be considered a
baseline, and PeekBoo should be expected to equal or exceed the
security features in the PGP algorithms.
So far the only thing that sounds like an important consideration to
me, is the use of page locked memory. As a beginner, I only think I
know what this means, and I do not know if, or where, PGP and PeekBoo
use it. Is it integral to the distributed source for the actual
ciphers, or can it be made so? Can it be applied to the PeekBoo key
management functions? And can it be applied to the PeekBoo main
window, which supports text editing functions?
I think that these are relevant questions, because the represent
potential security improvements, not only in PeekBoo but elsewhere:
For instance, according to the PGP docs, the only way that PGP
attempts to deal with the swap file leakage issue is by not leaving
sensitive data in memory "any longer than necessary"; evidently PGP
leaves real solutions up to the user. (PGPWin user's guide, pg 209).
A crypto app that does not allow memory to be swapped during any
process that involves key material, and includes an un-swappable text
editor, might seriously annoy some hypothetical forensics team
someday.
;o)
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Please Comment: Modified Enigma
Date: 7 Jan 2000 02:53:41 GMT
In article <851u3v$k85$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> Enigma is a joke to crack for my desktop.
>
>Please note that I DID NOT suggest Enigma with known rotor permutations, but
>the rotor permutation as part of the KEY.
I think even regular Enigma is not so trivial as the person who called
it a joke seems to believe.
>Regarding RC4, I do not think one can practically operate it on paper (think
>about the calculus and the 256 (!) pieces of paper you have to play with :-))
In practice I'd do it with pencil, paper, and an eraser, rather than
moving a lot of little counters around. Also, I'd use fewer cells,
like 9x11 = 99 cells (or if I was paranoid, 15*17=255). That would
make the number of rows and columns coprime to each other, which means
the modular arithmetic could be done separately on each "coordinate",
making it easier to do mentally.
>My scheme would still be complex and timeconsuming ( I do not propose it for
>the battlefield), mainly at the rotor construction time (you must be quite
>precise..), but it would be usable. Instead of playing with 256 pieces of
>paper (RC4) , you just have to rotate the circles..
Yes but you have to still keep doing all these lookups and arithmetic.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How about this for a "randomly" generated bitstream?
Date: 06 Jan 2000 23:00:22 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terje Elde) wrote:
>
>In article <[EMAIL PROTECTED]>, John McDonald, Jr. wrote:
>>Does anyone have thoughts on this? Problems with implementation?
>
>First of all I'd choose something other than music, sound is a excelnt
>source tho, because of the high rate, thus we can afford to shorten it
>down a bit:
>
>Take the LSB of every sample, line them all up, then run a simple check on
>two and two bits at a time:
>
>00 == throw away
>11 == throw away
>10 == keep 1
>01 == keep 0
>
>This ensures that if you get long runs of 0's or 1's or some other such
>thing then it'll be discarded. Then again, if you get long runs of
>0101010... you're in trouble again :)
One problem: an audio recording that is accurate to the LSB sounds
considerably worse than one with 1 LSB of random noise added. Because
of this, it is common to add 1 LSB of random noise. In the old days
this was usually resistor noise, but nowdays it is chaeper to write a
psuedorandom generator program on the DSP chip in your mixing board.
I doubt that the psuedorandom generator programs are at all suitable
for crypto. (At last! My membership in the Audio Engineering Society
finally paid off!)
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: OT Re: letter-frequency software
Date: 7 Jan 2000 04:00:59 GMT
This is off-topic, but I use this frequently for the boring steps in
"pencil and paper" cryptanalysis.
In article <84j93v$d4o$[EMAIL PROTECTED]>,
Bill Unruh <[EMAIL PROTECTED]> wrote:
> Actually, with a bit of work, awk will do fine for reasonable length
> text.
For the text-processing associated with cryptanalysis, I love to use
awk. I find it easier than C, because of its associative arrays, as
you said. I don't know perl yet, though; perhaps it's even better.
> If you want to preserve spaces, replace spaces by some other
> character like *.
You could tell awk to use a different field separator instead.
> Then break up the text into one character per line.
I'd let awk break up the text:
tr -cd 'A-Za-z\n' < document.txt | \
awk '{for(i=1;i<=length($0);i++) f[toupper(substr($0,i,1))]++} \
END{for(j in f) print j, " ", f[j]}' | \
sort -n +1
The first line is optional; it assumes you want only alphabetical
characters. I've also assumed case is not relevant. Replace the "1"
in the "substr" function with "2" and subtract one from "length" for
digrams:
tr -cd 'A-Za-z\n' < document.txt | \
awk '{for(i=1;i<=length($0)-1;i++) f[toupper(substr($0,i,2))]++} \
END{for(j in f) print j, " ", f[j]}' | \
sort -n +1
YMMV with your version of awk. I've used this so often I've made an
awk script (which is much more readable).
>cat document.txt|awk 'BEGIN{N=0} {f[$1]++}END{ for (j in f) print j, " ", f[j]}'|sort
>-n +1
Ah! The ubiquitous unnecessary cat! Try input redirection.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How to pronounce "Vigenere"?
Date: 06 Jan 2000 23:03:39 EST
VIY-AAH-GRUH???
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Anagram
Date: Fri, 07 Jan 2000 04:11:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dan Day) wrote:
>On Tue, 04 Jan 2000 00:33:34 -0600, "John E. Gwyn" <[EMAIL PROTECTED]>
>wrote:
>>at a time, but probably you're just asking for a single random
>>shuffle. That's not hard:
>> input in array string[1..N]
>> for i from 1 to N-1
>> j = random integer in range [i,N]
>> swap string[i] and string[j]
>> output in array string[1..N]
>
>You want "from 1 to N" in that "for" loop, not "N-1".
He got it right.
>
>For a demonstration that your method doesn't give the desired
>results, consider a 100 character string. The only chance
>that string[100] has of being moved out of its original
>location is if any of the first 99 swaps happen to "hit" it
>in the "j = random" line.
>
>The probability of any one pass through the loop "hitting"
>string[100] are 1/100.
Nope: since the random integer is from the range [i,100], the
probability of hitting string[100] is 1/(N-i+1)
> The probability that all 99 passes
>"miss" string[100] are (1-1/100)^99, or 0.3697.
No, it's:
(N-1)/(N-1+1) * (N-2)/(N-2+1) * (N-3)/(N-3+1) * ... * (N-N-1)/(N-(N-1)+1)
which (if you do all the cancelation) just happens to be:
1/N
>
>In other words, your method would leave the final character
>in a 100 character string right where it began 37% of the time.
>Needless to say, a proper shuffle would only have a given character
>end up where it started 1% of the time in a 100 character string.
Funny, that's exactly how often the algorithm in dispute leaves
it.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Truly random bistream
Date: 06 Jan 2000 23:11:58 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>Dave Knapp <[EMAIL PROTECTED]> wrote:
>: (Jim) wrote:
>
>:>Nothing is _absolutely_ random; no clock is _absolutely_ accurate;
>:>nothing can go from one level to another _absolutely_ instantaneously;
>:>etc; etc...
>
>: And there's no such thing as _perfect_ conductivity...
>
>: And there is no fluid with zero viscosity...
>
>: Oops.
>
>You may /think/ these are errors - due to phenomena such as
>superconductivity - but I don't believe it's true.
>
>There's no such thing as _perfect_ conductivity.
(Conductivity being the inverse of resistance)
Yes there is. In fact, there are negative resistances. They need
external sources of energy, of course (Entropy law *not* repealed!)
but they do exist. And negative capacitance is more than a laboratory
curiousity - I have used it in several of my designs to cancel unwanted
capacitance.
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: RSA encrypt
Date: Fri, 07 Jan 2000 04:16:17 GMT
In article <[EMAIL PROTECTED]>,
Frank the root <[EMAIL PROTECTED]> wrote:
>
>
>Paul Schlyter wrote :
>
>> This also show why small exponents (3, 17 or 65537) are popular in the
>> public RSA key: the RSA computation will be much faster for these small
>> exponents.
>
>But, because d ( the secret key ) is obtained from the formula "ed mod
>Phi(n) = 1", doesn't it offer a possibility to evaluate a approximation
>of d? knowning that as much a term is small the other have pretty good
>chances to get bigger?
Well, knowing the value of d to an accuracy of 1% doesn't help you very much...
>
>In addition, it is possible to evaluate a approximation of Phi(n)
>whitout the primes factors of Phi(n)?
There is no known way. BTW: knowledge of Phi(n) allows you to factor n
efficiently.
--
poncho
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Square?
Date: Fri, 07 Jan 2000 04:18:12 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (David Wagner) writes:
>> Instead of Square, I'd suggest considering Rijndael, a successor of
>> Square that has received a good deal of analysis thanks the fact that
>> it is currently one of the five AES candidates.
>>
>> But frankly, I wouldn't suggest using a cipher as new as either Square
>> or Rijndael for production purposes unless it were absolutely necessary.
>> What's wrong with Triple-DES or Blowfish?
>
>For some applications the smaller block size could be a disadvantage.
>Square has a 128-bit blocksize. Rijndael supports blocksizes of 128,
>192, and 256 bits.
I haven't looked at Rijndael in detail, but do you mean "keysizes of 128,
192, and 256 bits"? An AES candidate must support those three keysizes,
but need support a block size of only 128 bits.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: Re: Anagram
Date: 7 Jan 2000 04:16:21 GMT
In article <9Pcc4.390$[EMAIL PROTECTED]>,
Daniel <[EMAIL PROTECTED]> wrote:
> I'm very new to cryptography, so this is probably not a very
> challenging question. Is there some standard or widely known method
> for scrambling the order of the characters in a string given some
> sort of input?
If I understand your question correctly, a transposition cipher will
work for you. A transposition cipher scrambles the order of the
message using some key.
I don't know about "standard" methods, but incomplete columnar
transposition is certainly widely known. Anagramming is a frequent
part of cryptanalysis of such ciphers.
Double transposition with different keys adds some security. Note,
however, that these are historical, pencil-and-paper ciphers, used up
through WWII, and are not terribly secure by today's standards.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
From: "John C." <[EMAIL PROTECTED]>
Subject: Just a little help please...
Date: Thu, 6 Jan 2000 23:10:59 -0500
Hi, I am kinda new to encryption and ciphers and other things like that. I
have been interested in to it in the past but I have never quite been able
to get a grasp on it. Now that I am 15yrs old, I am reading books regarding
quantum computing and quantum phyisics, i was hoping that someone could help
me out for a week or two to get me started into the better methods and or
teach me a few tricks on decrypting encrypted messages or vice vesa. If you
would like you may E-Mail me at [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
.... I have 10 others so if any of these are down I will post another.
Also I am on AIM under Jcp220
Thanks,
JCP219
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Unsafe Advice in Cryptonomicon
Date: 06 Jan 2000 23:20:35 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Steve K) wrote:
>
>On Thu, 06 Jan 2000 06:27:57 GMT, [EMAIL PROTECTED] (Steve K) wrote:
>
>And one more technical quibble from Cryptonomicon, about a computer
>room with an electromagnet in the door frame, that wipes any media
>being carried in or out: OK fine, if the field is strong enough to
>wipe media at the distances involved (typically 1-1/2 feet or so) and
>through the ferrous materials in the housings & etc. And OK fine, if
>the people carrying the stuff out through this field do not notice
>that every piece of ferrous metal that comes close to the frame gets
>yanked out of their hands.
>
>Oops. Heh heh. OK so the first thing they tried to carry out was the
>one thing that really did need wiped.
>
>Clank! "What the-- oh sh*t!"
>
>Plot line saved. Ta daa.
Nobody would design in a DC electromagnet when an AC electromagnet
works so much better. You typical 60 Hz electromagnet makes ferrous
materials wibrate quite noticably, but it may be that a higher
frequency with some spectrum spreading may erase without being noticed.
BTW, unless you are using Mu metal, it takes a LOT of ferrous material
in the housing to do mucfh in the way of shielding.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 06 Jan 2000 23:32:22 EST
In article <8525b8$ort$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>Second, if the values are in memory, they can be hacked out. No matter
>what. I could for example replace the windows system files when you
>are not looking...
No.
You can't.
I work for a CD replicator, and we keep the masters in a vault with
24 hour security (live and electronic). The day's masters that are
to be sent to the Laser Beam Recorders are on a file server, so it's
in the vault as well. The fact that you don't have physical security
does not mean that nobody does.
Even if you had physical access, you can't replace the windows system
files without either getting administrator privileges or opening
the case of the computer. By the time you get past the guard, the
alarm system, the vault door and NT security, your chances of being
undetected are small.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Thu, 6 Jan 2000 21:33:22 -0700
In article <853htn$3vo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Thanks for the ideas with respect to digraph distributions --
> I'll be reading up on Hidden Markov Model algorithms.
For those who care, the January 1996 issue of Dr. Dobbs had a fairly
reasonable write up of dynamic Markov compression, which might at
least be a step in the right general direction...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 06 Jan 2000 23:42:04 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Steve K) wrote:
>
>On Thu, 06 Jan 2000 14:38:13 -0800, lordcow77
><[EMAIL PROTECTED]> 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>).
>
>Of course we are only talking about "remote access trojans" acquired
>by mistake. Some spooky guy could come in physcially with a DOS boot
>disk and some batch files & utilities, and ruin your whole day. Visit
>one, your whole configuration is determined. Visit two, your whole
>security model is compromised. Visits 3 & onward, are via any chosen
>newtwork and/or OS hole that was installed during visit two. It ain't
>a question of whether it can be done, it is a question of whether
>anyone would spend the time & money required.
If you try this on my server, you had better bring along you own
floppy drive and cable (I removed them) and be prepared to defeat
the CMOS setup password (I estimate 3 minutes max for you to do
this - it's not much protection).
I tried making NT run off of a CD, but I never got it to work.
There are hard drives with physical write protection, but I don't
have those either.
BTW, the swap problem is trivial to solve. Use NT Embedded and
don't have a swap file, and put your OS and applications on a
ROM chip. I can't do this because I need a real file server,
but this would be a god way to build a dedicated crypto box.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Square?
Date: Thu, 6 Jan 2000 20:42:14 -0800
> > With that line of thinking I was wondering why you didn't suggest RC4?
> > It's simple, compact and fast....
It's also a trademark, a trade secret (at least officially), and for codes
where the twiddling of a known bit are destructive it can be easily,
predictably and dependably tampered with.
>
> That line of thinking is certainly not wrong. At least before
> AES was started, one read very very often in the literature how very
> extremely valuable it is to use an algorithm that has withstood
> decades of attempted analysis efforts by a large number of
> the best cryptologists. That that seemingly 'unaminous' opinion
> appears to have subjected to some modifications recently is something
> I haven't yet been able to fully comprehend. (Some who voiced that
> opinion are apparently themselves very actively engaged in works to
> replace the time-honoured best algorithms.)
I believe the effort is due to several facts. The most important two (IMHO)
are
A) DES has aged to beyond it's useful time, and Triple-DES has a significant
potential for attacks, it is after all effectively as new as the AES
candidates.
B) We have significantly more knowledge about what makes a cipher strong,
and so have the potential to create a cipher that could go well beyond the
strength of DES, even discounting the difference in keysize.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Thu, 6 Jan 2000 20:53:48 -0800
I find your claim that the memory space is not accessable somewhat suspect.
I for one have used MS VC++'s attach to process option for debugging quite
often, and have for the most part not had it fail, even on programs for
which I did not have source access. This indicates to me that there are
debugger calls in the system which allow access in just exactly the way you
claim cannot be done.
Joseph
------------------------------
** 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
******************************
