Cryptography-Digest Digest #862, Volume #10 Fri, 7 Jan 00 14:13:01 EST
Contents:
Re: Wagner et Al. ("John E. Kuslich")
Re: Truly random bistream (Scott Nelson)
Large Numbers Beginner Question ("Alexander J. Fanti")
Re: Large Numbers Beginner Question (John Savard)
Re: frequency analysis with homophones (Mok-Kong Shen)
Re: OLD RLE TO NEW BIJECTIVE RLE (Tim Tyler)
Re: Please Comment: Modified Enigma (Mok-Kong Shen)
Re: Large Numbers Beginner Question (Mok-Kong Shen)
Re: Why the Cryptonomicon in Cryptonomicon? (John Savard)
REDOC: First use: key dependent S-BOXES ("karl malbrain")
Re: Identifier anonymization (Mike Rosing)
Re: Large Numbers Beginner Question (Doug Stell)
Re: Large Numbers Beginner Question (David A Molnar)
Re: Blowfish ("karl malbrain")
Re: Wagner et Al. (Guy Macon)
----------------------------------------------------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Fri, 07 Jan 2000 09:21:06 -0700
NT is known to be secure when power is off, all drives and memory are
removed and battery acid is poured on the motherboard. It's just that NT
is hard to use in this configuration. :-))
Sorry for the sarcasm but I think there is merit on both sides of this
arguement.
On the one hand, physical security and perhaps some hardware
modifications can drastically increase NT security.
On the other hand, in most settings, where draconian security measures
cannot be employed and computers must allow ordinary users debugging
rights, and access to disk etc. there are significant vulnerabilities
and they are not widely appreciated because most high level language
programmers do not unserstand how a computer works!!
Page locking means that the virtual memory system is prohibited from
swapping data in RAM to the swap file on disk. The memory is still
available to a rogue program that knows how to gain conrol of the
processor from the operating system and have it's way with it. It does
not help that memory is wiped soon after keys are used. While the keys
are in use, they are just laying around in memory and exposed to an
attacker who has gained access to your computer. The program author cn
employ obfucatory techniques but a determines hacker will always win in
that event.
Under NT, a process may be started in such a manner that the process
inherits the security attributes of the calling process or user. This
means that if a program can be executed it can also be called by another
rogue process and executed. Under the latter case, the calling process
has complete access to the memory space of the called process.
This means that if an attacker somehow gains access to a computer, he
could install software that changes the name of PeekBoo (or any other
code) and replaces PeekBoo with a calling process that calls the now
re-named PeekBoo. When the ersats PeekBoo is started, the user sees
PeekBoo come up and apparently operate as normal. However, PeekBoo is
now under the control of the attacker's code which (say) uses a special
key instead of the normal PeekBoo key without informing the user. Or,
perhaps the PeekBoo program now just whistles Dixie!!
Whatever.
A couple of years ago, CRAK Software wrote a little program to read and
record the passphrase used by PGP just as a demo to show that it could
be done inspite of the fact that PGP used a non standard method of
reading the passphrase edit box. Apparently PGP's authors were aware
that the standard password edit box used under Windows is easy to read
by anyone who has the Winsite tool or Revelation tool etc. They used
some special code to input the text from the edit box but this text is
easily read by hooking the WM_GETTEXT message to the special edit box.
The passphrase also has to eventually lay itself down in memory where it
could also be read.
There is very little software can do to protect itself from anyone who
can gain access to your computer either by physical means or by the
network through BackOrfice and similar trojans.
Resistance is futile...at least as far as crypto software on the PC is
concerned.
JK htp://www.crak.com
Guy Macon wrote:
>
> In article <uzQjtsMW$GA.253@cpmsnbbsa02>, [EMAIL PROTECTED] (Joseph Ashwood)
>wrote:
> >
> >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
>
> It would help a great deal if you would argue against what is actually
> being claimed. Try "the memory space is not accessable UNDER NT UNLESS
> THE ADMINISTRATOR ACCOUNT TURNS ON THAT ABILITY FOR YOUR CLASS OF USER".
>
> First of all, were you using NT? NT has better security than 95/98.
> Second, were you logged on as Administrator? If you were logged on
> as an ordinary user, your debugging attempt would have failed.
>
> Under Administrative Tools --> User Manager --> Policies --> User Rights
> with "Advanced User Rights" clicked, you will find the list of which
> users can debug programs.
>
> NT has good enough security to get a C3 rating in non-networked mode.
> Alas, the default configuration isn't all that secure, but once you
> lock things down properly, it is very secure indeed.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Truly random bistream
Reply-To: [EMAIL PROTECTED]
Date: Fri, 07 Jan 2000 16:31:51 GMT
On Fri, 07 Jan 2000 08:04:15 -0700, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>Once you have used the bits, they are not random anymore.
Please define "random"
------------------------------
From: "Alexander J. Fanti" <[EMAIL PROTECTED]>
Subject: Large Numbers Beginner Question
Date: Fri, 07 Jan 2000 16:46:10 GMT
Hi all,
I'm a newbie... so I'll be brief, any help would be appreciated...
I'm interested in public key cryptography. I've read that I'll need to
deal with large numbers (ie 256 bit numbers (2^256)). My compiler only
supports integers up to 64 bits (and they're signed!).
What do I do?
Is there some computer math book I need to read to learn how to generate
512 bit random numbers and primes? Do people writing these routines for
Intel processors use specail compilers?
Thanks,
Alex
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Large Numbers Beginner Question
Date: Fri, 07 Jan 2000 10:21:37 GMT
"Alexander J. Fanti" <[EMAIL PROTECTED]> wrote, in part:
>Do people writing these routines for
>Intel processors use specail compilers?
No, although there are special languages, such as UBASIC, that have
long-precision arithmetic built in.
Essentially, routines are written that use the arithmetic methods you
learned in grade school, with the built-in 32-bit or 64-bit arithmetic
of the computer substituting for the "times table". There are fancier
methods of multi-precision arithmetic (i.e. Schonhage-Strassen
multiplication), but they're generally only used for numbers much
bigger even than those used for public-key ciphers.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Fri, 07 Jan 2000 18:38:53 +0100
r.e.s. wrote:
>
> 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.
If I understand correctly, you assume that a set of ciphertext
characters are homophones of A, another set are homophones of B, etc.
and you sum the frequencies of these groups and obtain a distribution
that fairly agrees with a certain distribution you deem to be
representative of the plaintext and want to know whether that
assumption is correct. I don't think you can do that. For there
wouldn't be much practically detectable difference if, for example,
you exchange one of the assumed homophones of A with one of E. After
all, the particular piece of plaintext involved may have a frequency
distribution fairly deviated from the representative distribution
so that much reliance on any 'exact' computation is illusory.
Note that, while the normal use of homopnone substitutions attempts to
achieve a uniform distribution, one can also use homophones to
deceive the analyst. Just for illustration purpose, suppose you have a
plaintext alphabet consisting of the digits 0-9, and you have a uniform
distribution of these (for instance the digits are fairly random),
you could attempt to map that to A-Z (or a permutation of these) in
such a way that the distribution more or less parallels to one of
natural languages, thus disguising the digit origin of your plaintext.
>From this viewpoint, one once again sees that your question above
cannot be answered in the affirmative with 'any' certainty.
>
> : 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.
As I commented, that is a very unusual way of doing homophone
substitutions. A normal homophone substitution attempts to obtain
(in the ideal case) a ciphertext frequency distribution that is uniform
so that the analyst has big difficulties to identify which homophones
correspond to which which plaintext characters. It follows that
for English your J has to depend on the plaintext character and not
a constant.
If you, in addition, employ 'polyalphabetic' homophonic substitutions
(a possibility that seems generally not explicitly mentioned in
the literatures, cf. also a recent thread initiated by me) with
a sufficiently large substitution table, then the frequency
distribution would be practically further (much) improved
(not only the distribution for sigle characters but also that for
digrams etc.).
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OLD RLE TO NEW BIJECTIVE RLE
Reply-To: [EMAIL PROTECTED]
Date: Fri, 7 Jan 2000 17:43:56 GMT
John Savard <[EMAIL PROTECTED]> wrote:
[snip]
: (For myself, while I too think removing certain reduncancies from
: compression have their uses, I quarrel with any attempt to emphasize
: one-to-one purity at the expense of bias. [...]
Bias in the resulting compressed file is certainly important.
Which is /more/ important depends partly on the relative sizes of the bias
caused by lack of elimination of redundancies in the plaintext, and the
bias introduced by a lack of 1-1 compression.
Some non-1-1 compressors seem to be able to allow files to be rejected
on the basis of the first few bytes of the file. These include
some compressors that build and use dictionaries, and many of those where
there is a sliding window onto previous compressed text. Early sections
of the file can contain "impossible" references to previous bytes before
the start of the file.
There are a number of problems of this kind that mean that failure to
get close to the 1-1 property can reduce the time taken to work
through they keyspace pretty dramatically, when compared to doing
frequency analysis on a partly decrypted file to see if it has the
same sort of biases a compressed file would exhibit.
There will be cases where failure to remove biases present in the
plaintext is the more important factor.
Pretty much everybody already understands that a poor compression ratio
fails to offer the full advantages of compression, though. It is the 1-1
property that people seem to underestimate the importance of.
: That was the flaw in his Huffman proposal.)
There was no flaw in his Huffman proposal AFAICS. He completely and
finally solved the Huffman file-ending problem for byte aligned files.
If you want to object that he then went on to use his Huffman symbols
in a sub-optimal manner and subsequently did not get quite as good a
compression ratio out of his Huffman encoding as would have been
theoretically possible, that would be fair enough - but his Huffman
symbol stream itself now appears to be perfect.
I expect that was his main design goal, and it seems to me to be a
significant accomplishment.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
DISTRIBUTE VIA COMINT CHANNELS ONLY.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Please Comment: Modified Enigma
Date: Fri, 07 Jan 2000 18:58:24 +0100
[EMAIL PROTECTED] wrote:
>
> Regarding the PalmPilot-Argument: If you are *super-paranoid* you may
> fear the electromagnetic emanations of your 'Pilot being monitored..
> I guess our friends at NSA already looked at supra-cooled antennas and
> SQUIDs... And please do not dream the dream of LCD drivers being
> undetectable.
That's why in another thread I conjectured a probable renascence
of (silent, or with non-specific noises) mechanical crypto devices
for use as one component of an encryption system. In particular, I
suppose these could be well integrated into input/output devices.
With people nor working hard exploiting emissions, this might open
a profitable line of commercial products.
M. K. Shen
======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Large Numbers Beginner Question
Date: Fri, 07 Jan 2000 19:06:58 +0100
Alexander J. Fanti wrote:
>
> I'm interested in public key cryptography. I've read that I'll need to
> deal with large numbers (ie 256 bit numbers (2^256)). My compiler only
> supports integers up to 64 bits (and they're signed!).
>
> What do I do?
There are packages in C, Fortran and other languages for doing
large integer or real arithmetics. If one doesn't pose hard
requirements on efficiency, a computer algebra system also provides
that facility. (Some of these are free.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why the Cryptonomicon in Cryptonomicon?
Date: Fri, 07 Jan 2000 11:34:21 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>On Tue, 04 Jan 2000 07:15:16 GMT, [EMAIL PROTECTED]
>(John Savard) wrote:
>>The inconsistent handling of trademarks
>And speaking of fictional things in the book, Qwghlm seems to be what
>the Hebrides would be, had they been inhabited not by Scotsmen with
>some admixture of Norwegian ancestry, but instead by Manxmen or by
>members of a similar people.
However, Manx _is_ a Gaelic language. Its last native speaker died in
the 1970s, but the language has been revived. And Britain would not
have used Manx codetalkers, because even in 1933, it was (mistakenly)
believed that only one native speaker of Manx survived.
So Qwghlm is the Hebrides, inhabited by mad, Basque-speaking, Manxmen!
It doesn't appear, though, even if one is allowed to use the word
"Qwghlm", that it is possible to compose an English sentence using all
26 letters of the alphabet exactly once...
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: REDOC: First use: key dependent S-BOXES
Date: Fri, 7 Jan 2000 10:44:34 -0800
The basic method for REDOC III was to take, say, a 128-bit input block and
select bit-by-bit a pre-computed, key-dependent 127-bit S-BOX value (each
with a zero in the selection bit position) for XOR with the block.
Encryption went from left to right, bits 0 - 127, and decryption went from
right to left, ending by selecting bit 0.
The only thing wrong with REDOC III was that it needed to go around the
block more than once, and its S-BOXES needed to stay 127 bits wide at each
selection position.
It seems to me that BLOWFISH, and other key-dependent S-BOX authors, should
be giving credit to Michael Wood for using his invention. Karl M
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Identifier anonymization
Date: Fri, 07 Jan 2000 12:48:02 -0600
Al Wang wrote:
>
> I've been thinking more about my problem and I had a thought: would I
> be able to use some public-key algorithm as an anonymizer by promptly
> destroying (or securing) the private key? This would allow me to
> "anonymize" the identifier by encrypting it with the public key, but
> would provide no way of decrypting it.
>
> Would anyone be able to recommend an algorithm for this purpose? It
> seems that this model would have to defend well against both
> known-plaintext and chosen-plaintext attacks. Does this mean RSA
> would not be such a good solution?
That's essentially the same thing as the keyed hash suggested
before. If you pick a secret key that only you know, and
attach it to the 9 digits, then hash the combination, you'll
have what you want. Standard hash algorithms are 20 bytes,
so that's too long. Keep only the last 10 or 12 characters
from the hash and you should be OK.
In pseudo-code:
s = secret key data
d = 9 digit data
h = hash( s || d) (d concatenated with s)
output = h[5],h[4],h[3],h[2],h[1],h[0] converted to hex
(i.e. h[i] = high nibble, low nibble in
ascii)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Large Numbers Beginner Question
Date: Fri, 07 Jan 2000 18:38:07 GMT
On Fri, 07 Jan 2000 16:46:10 GMT, "Alexander J. Fanti"
<[EMAIL PROTECTED]> wrote:
>Hi all,
>
>I'm a newbie... so I'll be brief, any help would be appreciated...
>
>I'm interested in public key cryptography. I've read that I'll need to
>deal with large numbers (ie 256 bit numbers (2^256)). My compiler only
>supports integers up to 64 bits (and they're signed!).
As you discovered, most compilers support doing math in floating point
or on the byte, word, long and double precision levels. While this is
sufficient for most applications, the numbers used in public key
cryptography are much larger and are generally done using arrays of
whatever is natural for the computer and compiler or the
communications channel. Most often byte arrays are passed on the
communications channel, MSB first. I have what claims to be the
world's fastest implementation of DSA in C and it uses arrays of
unsigned longs, least significant long first.
We generally consider the numbers used in public key cryptography to
be non-negative.
>What do I do?
>Is there some computer math book I need to read...
A good place to start for the general math of public key cryptography
is the Handbook of Applied Cryptography. It is available on line and
contains a good chapter on efficient implementations, Chapter 14. The
URL is: http://cacr.math.uwaterloo.ca/hac/
Then look at some sample code, which is readily available.
>...to learn how to generate
>512 bit random numbers and primes?
Generating random and pseudo-random numbers is both an art and, often,
an application of the general math. Primality testing is also a
complex function that uses the general math.
> Do people writing these routines for
>Intel processors use specail compilers?
Not generally. However, they often use either a custom or a
generalized large number math library, which supplies the functions of
interest.There are a number of these available to look at.
John Savard offered some good points on this question.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Large Numbers Beginner Question
Date: 7 Jan 2000 18:44:36 GMT
Alexander J. Fanti <[EMAIL PROTECTED]> wrote:
> I'm interested in public key cryptography. I've read that I'll need to
> deal with large numbers (ie 256 bit numbers (2^256)). My compiler only
> supports integers up to 64 bits (and they're signed!).
> What do I do?
Find a "bignum" package. The GnuMP library is one such package (check any
GNU site). Another is NTL (http://www.shoup.net/). Two others are MIRACL
and PARI. If you search for "bignum" or "multiprecision
integer package", you'll find many software libraries which implement
large integers. These typically provide a new data type which can be
manipulated much like a regular int or long...except it holds an
arbitrarily large number of bits.
I've worked a bit with GnuMP and NTL. NTL will do more "for you"; it has
native routines for fast modexp and modmult, for instance. The downside is
that the programming interface has occasional quirks. GnuMP, on the other
hand, provides only "the basics", but it's usually clear how to use them.
Thanks,
-David Molnar
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Blowfish
Date: Fri, 7 Jan 2000 11:05:03 -0800
r.e.s. <[EMAIL PROTECTED]> wrote in message
news:853unb$r21$[EMAIL PROTECTED]...
> Since you might browse into this out of curiosity as I did,
> I think the following is worth mentioning.
>
> My AV software (McAfee) reports that the file
> boblowfish1-1.zip
> at
> ftp://ftp.replay.com/pub/replay/pub/crypto/LIBS/blowfish/
> contains a virus called "Orifice2K.plugin".
> (Today, 1/6/00, I notified the webmaster at the ftp site.)
This does NOT mean there actually is a virus. I have the same problem with
McAfee claiming my install program is a virus. The problem comes from the
SIGNATURE method for virus detection. Karl M
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 07 Jan 2000 14:08:31 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John E. Kuslich) wrote:
>On the other hand, in most settings, where draconian security measures
>cannot be employed and computers must allow ordinary users debugging
>rights, and access to disk etc. there are significant vulnerabilities
>and they are not widely appreciated because most high level language
>programmers do not unserstand how a computer works!!
I, on the other hand, not only understand machine language, but also the
microdode instructions that are at a lower level than machine language.
Why do you believe that "computers must allow ordinary users debugging
rights and access to disk"? A normal NT installation does not give
ordinary users debugging rights. or access to certain portions of the
disk (and you can add your crypto directory to the portions that
ordinary users cannot access).
>Page locking means that the virtual memory system is prohibited from
>swapping data in RAM to the swap file on disk. The memory is still
>available to a rogue program that knows how to gain conrol of the
>processor from the operating system and have it's way with it. It does
>not help that memory is wiped soon after keys are used. While the keys
>are in use, they are just laying around in memory and exposed to an
>attacker who has gained access to your computer. The program author cn
>employ obfucatory techniques but a determines hacker will always win in
>that event.
The reason the swap file is so important compared to the memory is that
I can set up an NT box in such a way that you cannot get NT to run and
allow access to memory, but I cannot stop you from booting to another
OS and accessing the swap file. Information on disks needs more
protection than information in RAM. If you study NT security you will
learn that I am right on this point.
>Under NT, a process may be started in such a manner that the process
>inherits the security attributes of the calling process or user. This
>means that if a program can be executed it can also be called by another
>rogue process and executed. Under the latter case, the calling process
>has complete access to the memory space of the called process.
Under NT, there are things that no user or process is allowed to do.
If you have physical access you can defeat all of NT's security
(or Linux's or your AS/400'a, etc.) Without physical access or
Administrator rights, there are a lot more things that you can't do.
That's why I disconnect the LAN cable and cycle the power before
logging on to a server as Administrator, and why I set up the servers
to only allow administrators to logon via the console.
>This means that if an attacker somehow gains access to a computer,
Then all bets are off, and all computers and operating systems are
vulnerable. If you don't have physical security you don't have security.
>There is very little software can do to protect itself from anyone who
>can gain access to your computer either by physical means
Agreed 100%.
> or by the network through BackOrfice and similar trojans.
A properly secured and administered NT installation is highly
resistant to having trojans installed.
>Resistance is futile...at least as far as crypto software on the PC is
>concerned.
Here is where we part company. The argument that imperfections in
a scheme make the scheme not worth doing is a fallacy. It's like
saying that a car thief can break into my car with a slimjim and
hotwire it, so I might as well leave the doors open, the key in the
ignition, and the engine running. Even easy to defeat security
measures are often worth doing.
------------------------------
** 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
******************************
