Cryptography-Digest Digest #204, Volume #9 Mon, 8 Mar 99 22:13:04 EST
Contents:
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: DIE HARD and Crypto Grade RNGs. (Jim Gillogly)
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Re: DIE HARD and Crypto Grade RNGs. (Jim Gillogly)
Re: Symmetric vs. public/private ([EMAIL PROTECTED])
Re: Symmetric vs. public/private (Sundial Services)
Modular Multipliers (BORIS KAZAK)
Re: Scramdisk lockups, more test data (Jeff Millar)
Re: Looking for encryption algorithm (Scott Fluhrer)
Re: DIE HARD and Crypto Grade RNGs. (Jim Gillogly)
Does/Can multiple XORing of the Plain/Cipher text improve security? ("Rats")
Re: My Algorithm ("Rats")
Re: RC5 and RC6 code (free code) + update ([EMAIL PROTECTED])
Re: My Algorithm ("Rats")
Re: Improving POP3/IMAP CRAM authentication (Alan DeKok)
Re: RC5 and RC6 code (free code) + update (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 08 Mar 1999 22:59:15 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 17:44:06 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Repeating this statement does not make it true.
And repeating your statement does not make my statement invalid.
>Please cease.
By now you know better than ask that.
Why don't you prove that statistical tests are more than mere
diagnostic warnings of possible problems.
Prove to us that you can devise a sufficient suite of tests that can
pass the SOG Challenge.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 08 Mar 1999 14:21:34 -0800
R. Knauer wrote:
> Champernowne's number and the digit expansion of pi both pass
> statistical tests for randomness. Yet the processes that generate them
> have zero entopy.
I just did a quick check on Champernowne's number, and it fails an
obvious statistical test: it compresses nicely. If you'd like to
check my implementation, here are the first few bytes:
6e 5d e2 6a f3 7b e1 19 4e 95 b5 f1 9d 6f 9d f7
If ch(n) represents a truncated Champernowne number out to the
point where n is expanded into binary and tacked on, then the
file of ch(100,000) is 196K bytes, and is compressed with gzip by 4.2%.
ch(1,000,000) is 2.4M bytes, and is compressed by 11.0%.
ch(10,000,000) is 28M bytes, and is compressed by 14.8%.
ch(100,000,000) is 320M bytes, and is compressed by 36.7%.
This should be expected, since adjacent numbers of reasonable
size will share most of their bits, and a gzip-like pattern
matcher will notice it.
In the limit I'd expect very good compression.
--
Jim Gillogly
Highday, 16 Rethe S.R. 1999, 22:02
12.19.6.0.1, 9 Imix 14 Kayab, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Tue, 09 Mar 1999 00:36:55 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 16:22:43 -0800, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>> You must use base 10. That is the only base that Champernowne's number
>> is known to be normal in the Borel sense.
>OK. Define ch10(n) to be the start of the base 10 Champernowne number
>ending with the decimal expansion of n. Using standard gzip,
OK, then try that with an expansion of pi (to any base).
Bet it won't compress worth squat.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 08 Mar 1999 16:55:39 -0800
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
> OK, then try that with an expansion of pi (to any base).
> Bet it won't compress worth squat.
Very likely -- I'm not tempted. Does this mean we now agree
Champernowne's Number is not a relevant counterexample for the
usefulness (or not) of statistical techniques in testing
[T|P]RNG sequences?
--
Jim Gillogly
Sterday, 17 Rethe S.R. 1999, 00:52
12.19.6.0.2, 10 Ik 15 Kayab, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Symmetric vs. public/private
Date: Tue, 09 Mar 1999 00:47:39 GMT
> I currently have the need to incorporate encryption
> into an application. I've been doing a lot of reading
> and still can't come up with an answer as to whether
> to use the public/private key method or a symmetric
> approach. Assuming I have no requirement to conform
> to the public/private key method, what will I gain/lose
> using that approach? The symmetric approach looks good
> because of speed, licensing issues, and I like the fact
> that I don't have to have a key server in the middle of
> all of this. On the other hand there are key distribution
> issues with the symmetric approach which become awkward
> because I have a requirement that more than 2 people
> could be sharing a key. I would really appreciate some
> "real world" input on this. I would also appreciate any
> pointers to papers that discuss the pros and cons.
> Thanks for any input.
>
> Billy
Well you would use public key methods if people you don't know will send you
email or messages. If this is prearranged use symetric (private) methods as
they are faster. 2 people sharing keys? Out of say 2 to the power of 64
keys? I don't think so.
Not to toot my horn, but if you want sample code I wrote copies of Ronald L.
Rivest's RC5 and RC6 in C. They are fully customizable (16/32/64 bit words),
number of rounds and key size.
They are at:
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Mon, 08 Mar 1999 18:13:16 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Symmetric vs. public/private
Billy Cole wrote:
>
> I currently have the need to incorporate encryption
> into an application. I've been doing a lot of reading
> and still can't come up with an answer as to whether
> to use the public/private key method or a symmetric
> approach. Assuming I have no requirement to conform
> to the public/private key method, what will I gain/lose
> using that approach? The symmetric approach looks good
> because of speed, licensing issues, and I like the fact
> that I don't have to have a key server in the middle of
> all of this. On the other hand there are key distribution
> issues with the symmetric approach which become awkward
> because I have a requirement that more than 2 people
> could be sharing a key. I would really appreciate some
> "real world" input on this. I would also appreciate any
> pointers to papers that discuss the pros and cons.
> Thanks for any input.
Encryption is very well-suited to protecting data from the "casual
interloper" who might otherwise glean information by direct inspection
of the application files or databases.
But encryption is less-effective as the core of your application-login
mechanism, where you identify the user and confirm his right to use the
application and the extent to which he may do so. It is less-effective,
that is, IF you tie the key that he presents as his credentials, with
the key that is used by the application to unlock the stored
information. My point is that the two keys do not have to be the same.
Two users could enter separate userid/password combinations, have them
validated by the computer, and receive the use of a cipher-key that is,
and remains, totally unknown to them both! This cipher key, never
revealed to them, both enables them to get access to the information and
(by its secrecy) assures that they cannot subvert the protection because
they don't know how.
Obviously, the design and requirement of the application itself are
totally key to all of this: in the right situation this works great.
In the wrong situation it's entirely inappropriate.
------------------------------
From: BORIS KAZAK <[EMAIL PROTECTED]>
Subject: Modular Multipliers
Date: 8 Mar 1999 23:06:39 GMT
Reply-To: [EMAIL PROTECTED]
Here I have some questions for the gurus of this forum.
Modular multiplication is a well known way to imitate
S-boxes with a big number of input and output bits. For example,
IDEA uses multiplication (mod 2^16+1) with the key-dependent
multipliers. Similar routines can be easily implemented for
multiplication (mod 2^32+1) and even (mod 2^64+1). The common
objection that these two last modules are composite, can be
overcome by choosing the multipliers so that these will be
relatively prime to the modulus under consideration.
Now the questions are:
1. What can be said about the properties of the S-box
defined by this modular multiplication? Is it bijective, is it
in any way linear, how does it propagate differences?
(All this without looking at the particular multiplier,
since we assume the multiplier to be key-dependent)
2. Are there any "weak" or "biased" multipliers (excluding
the obvious case of trivial multipliers which are their own
multiplicative inverses)?
If there are, how can one spot these in order to avoid them
being used for an S-box?
3. Why not use the modular multiplication as a combining
operation in a Feistel-like cipher instead of usual XOR?
It is easily invertible, at the expense of using the direct
multipliers for encryption and their multiplicative inverses
for decryption. Anyway, if one reverses the order of subkeys,
why not pick the decryption multiplier from an adjacent table?
4. It is obvious that modular multiplication by itself is
a closed group, since
A*M1*M2*M3 (mod N) = A*M4 (mod N)
where M4 = M1*M2*M3 (mod N)
Can these group properties be destroyed by intermediate XOR-ing
with some key-generated numbers (mixing operations from different
arithmetic groups)?
Thanks in advance for responses BNK
------------------------------
From: [EMAIL PROTECTED] (Jeff Millar)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Scramdisk lockups, more test data
Date: Tue, 09 Mar 1999 01:31:12 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Aman) wrote:
>On Sun, 07 Mar 1999 02:44:02 GMT, [EMAIL PROTECTED] (Jeff Millar)
>wrote:
>
>>I booted W98 into safe mode to try scramdisk in a simpler environment.
>>The mount command worked to the extent that one of the folders changed
>>it's icon...I've not gotten that far before. But, at the first click
>>on the folder, the machine locked up hard.
>>
>>looking for ideas....
>>
>
>Are you using Scramdisk version 2.02G ?
>
>Have you installed freeware ENHANCED IDE drivers on your machine ?
>There has been reported instances of very rare problems with these...
>
>Aman.
Bad news. After upgrading to directx 6.1, swapping around graphics
cards, uninstalling and reinstalling some networking, and generally
not touching anything related to disks... Scramdisk now works. So
that's end of my debugging efforts.
In answer to you questions... yes v2.02g, no enhanced ide stuff.
BTW, I really like the product, it works very smoothly, now.
jeff
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Looking for encryption algorithm
Date: Tue, 09 Mar 1999 01:35:34 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (kufan) wrote, in part:
>
>> Does anyone know any kind of encryption algorithm that
>>using 2 or more keys to encrypt and using 1 key to decrypt,
>>and the encryption speed will be as fast as symmetric
>>encrypt algorithm?
>
>It isn't clear exactly what you are looking for.
>
>Do you mean this:
>
>an algorithm, such that the authorized decryptor can decrypt messages with
>his key,
>
>which are enciphered in two or more different encrypting keys
>
>such that a person knowing one of those encrypting keys cannot derive the
>other encrypting keys, or easily test two encrypting keys for equivalence?
>
>Or do you mean something a bit less difficult and complicated?
Actually, if that's all he wants, then it's pretty trivial if you don't
mind an encryptor having the ability to decrypt his own messages [1]:
1. Pick a symmetric encryption algorithm (for example, DES)
2. Choose N random DES keys k1, ..., kn
3. Give encryptor x DES key kx
4. Give the decryptor all the DES keys
5. When an encryptor x encrypts a message, he encrypts it with his DES
key, and sends that, along with who he is (so the decryptor knows
which DES key to use)
[1] And, if you insist on the restriction that an encryptor cannot decrypt
his own messages, then you are insisting on a trap-door method with
added restrictions. And, I don't know of any trap-door method that is
as fast as a good symmetric cipher
--
poncho
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 08 Mar 1999 17:51:39 -0800
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
> OK, then try that with an expansion of pi (to any base).
> Bet it won't compress worth squat.
Well, OK, just to test our intuitions and my compression
estimates I went ahead and did it for 1,254,540 decimal
places. Gzip compressed it by 52.9% (my "random" samples
gave 53.0% each), and my 3|4-bit Huffman code compressed
it by 57.505% (vs. my theoretical estimate of 57.5%).
As expected, pi in decimal isn't compressible this way,
despite being completely expressible in a single Greek letter.
--
Jim Gillogly
Sterday, 17 Rethe S.R. 1999, 01:47
12.19.6.0.2, 10 Ik 15 Kayab, Second Lord of Night
------------------------------
From: "Rats" <[EMAIL PROTECTED]>
Subject: Does/Can multiple XORing of the Plain/Cipher text improve security?
Date: Tue, 9 Mar 1999 15:01:51 +1300
Situation:
Key1 -> PRNG -> PRN stream -> XOR with Plain Text -> Cipher Text 1
Key2 -> PRNG -> PRN stream -> XOR with Cipher Text 1 -> Cipher Text 2
Key3 -> PRNG -> PRN stream -> XOR with Cipher Text 2 -> Cipher Text 3
.
.
.
KeyN -> PRNG -> PRN stream -> XOR with Cipher TextN-1 -> Cipher Text N
Now my question here is can this type of system be used to improve security.
Thanks in advance.
Rats
P.S.
Please don't bag me if this is a stupid question!
------------------------------
From: "Rats" <[EMAIL PROTECTED]>
Subject: Re: My Algorithm
Date: Tue, 9 Mar 1999 15:09:39 +1300
Hey give the guy a break!
He is atleast giving it a go!
Good on ya mate. Nothing wrong in taking pride in ones work.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC5 and RC6 code (free code) + update
Date: Tue, 09 Mar 1999 01:55:50 GMT
I will check with the parent company. Thanks for your info.
What is the point of publishing an algorithm if you won't let anyone use it?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Rats" <[EMAIL PROTECTED]>
Subject: Re: My Algorithm
Date: Tue, 9 Mar 1999 15:10:55 +1300
Instead of making source code available, why don't you write out the
algorithm in pseudo code or something like that. It makes easier reading.
Cheers
Rats
[EMAIL PROTECTED] wrote in message
<7bos33$oh2$[EMAIL PROTECTED]>...
>Would this group be more responsive to analyzing my algorithm if I provided
a
>small paper on it? And why I think it is strong? If so I could write a
small
>paper on it. Describing the algorithm, and why I think it's resistant to
some
>attacks (ciphertext-only, plain/cipher text, chosen-ciphertext).
>
>I would really appreciate some analysis. I think it's somewhere between a
>stream coder and a OTP. I am new to encryption, I really don't know a
whole
>lot. But would like to learn. I think so far my algorithm is strong
because
>it's value/position and plaintext dependant coding. As long as the key is
>well chosen (LSB of audio input for example) and distributed carefully (i.e
>one a floppy disk).
>
>If you can read 'C' code it's at:
http://members.tripod.com/~tomstdenis/e.c
>
>Tell me what you think (good or bad).
>
>Thanks,
>Tom
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Alan DeKok)
Subject: Re: Improving POP3/IMAP CRAM authentication
Date: Mon, 08 Mar 1999 23:30:03 GMT
In article <7btpnk$oe9$[EMAIL PROTECTED]>,
Solar Designer <[EMAIL PROTECTED]> wrote:
> I've been reading the relatively recent RFCs on POP3 and IMAP protocol
> extensions designed to support more secure authentication methods. What
> I was looking for is a simple method (no public key crypto) that would
> still always be better than plaintext authentication.
They do exist. The problem is finding them, and telling people
about them.
> After a bit of thinking I came up with the approach I'm including below.
> The reasons I'm posting it are -- (1) to make sure I am not missing some
> obvious (or not very obvious) attack, and (2) to find out whether I have
> invented the wheel (and there's already a standard C/R protocol that
> achieves all the same goals), or not.
There's almost always something similar in the literature. One of
the ones I like is:
http://www.sevenlocks.com/papers/authent/bird1.txt
But it's may be too complicated for POP3 && IMAP.
> stored at the server:
> hash = H(H(password))
> the client needs to know:
> H(password) (or the password, if entered manually each time)
> session:
> S: challenge = unique()
> C: response = H(H(H(password)), challenge) ^ H(password)
> S: if (H(H(hash, challenge) ^ response) == hash) auth_ok
The hash at the server is plaintext equivalent: use salts.
My suggestion:
S = Salt
P = password
R = random number
Stored by the server as the 'password' (ala 'crypt' and /etc/passwd)
H_S = H(S+P)
Sent by the server to the client on a connection:
S,R
Calculated by the client, and sent to the server:
H(R + H(R + H(S + P)))
Calculated by the server:
H(R + H(R + H_S) = H(R + H(R + H(S + P))) from the client.
However, this protocol has problems, most notably it's vulnerable to
spoofing by a man in the middle. What would be better is the
following, which is lifted from Figure 27 of the paper, with
modifications for this situation.
Client Server
N1
(1) ----------------------->
S, N2, MAC(N1, N2, N1 XOR B)
(2) <-----------------------
MAC(N1, N2)
(3) ----------------------->
where MAC(M) = H(H_S + H(H_S + M)), with S and H_S as above, N1 and
N2 are 64-bit random numbers, and B is the IP address of the server.
Using H_S protects from server comprimise, hopefully at least as
much as crypt() now does. Using the 3-pass non-symmetric protocol
protects agains man in the middle attacks, and others.
See 'Shneier, B., "Applied Cryptography, 2nd Ed."', p. 458, and RFC
2107 for information on MAC's.
Alan DeKok.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: RC5 and RC6 code (free code) + update
Date: Mon, 08 Mar 1999 18:57:12 -0800
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> I will check with the parent company. Thanks for your info.
> What is the point of publishing an algorithm if you won't let anyone use it?
They're happy for people to use the algorithm. However, they're in
business to make money, and figure that since they invented this thing
they're entitled to a profit from the sweat of their skull, so they
license it. They publish it so that people can see how clean and tidy
the structure is and can evaluate its suitability for their applications.
All seems consistent to me. However, if there are free alternatives that
have similar perceived strength and tidiness, the market is limited to
companies with specific needs... like the need to buy from a Known Name.
--
Jim Gillogly
Sterday, 17 Rethe S.R. 1999, 02:53
12.19.6.0.2, 10 Ik 15 Kayab, Second Lord of Night
------------------------------
** 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
******************************
