Cryptography-Digest Digest #226, Volume #9 Fri, 12 Mar 99 12:13:03 EST
Contents:
Re: Security of ASPSESSIONID (Christine Liang)
Re: prob. of a given subsequence in a sequence (Tom Thomson)
Re: prob. of a given subsequence in a sequence (Peter L. Montgomery)
Re: How to PROPERLY implement CFB8 for DES? (Fabrice Noilhan)
RC4 file encryptor (please take a look) ([EMAIL PROTECTED])
Re: Crypto transmission in noisy ambient (Mike Playle)
RSA-examples ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mok-Kong Shen)
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: Crypto transmission in noisy ambient ("Trevor Jackson, III")
Seeking an Algorithm ! (Information Mechanincs)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: Seeking an Algorithm ! ("Sam Simpson")
CD Cipher (R. Knauer)
Re: Seeking an Algorithm ! (Sundial Services)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Re: PGP source code documentation (Sundial Services)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christine Liang)
Crossposted-To: microsoft.public.inetserver.iis
Subject: Re: Security of ASPSESSIONID
Date: 12 Mar 1999 09:27:36 GMT
Yes! I have the same concern.
Please give us some info.
Thanks a lot.
Christine
[EMAIL PROTECTED] wrote:
: IIS generates a session id cookie for applications that (may) need them. The
: MSDN library in the article "ASP Session ID Encryption and Session Security"
: contains an overview of how they are generated, but is sadly lacking in
: detail. Does any one have more detail on this. I would like to understand how
: unpredictable this cookie is? Or better yet an analysis of how secure or
: insecure it is. Is the answer different for those of us stuck with export
: crypto?
: Thanks,
: F.
: -----------== Posted via Deja News, The Discussion Network ==----------
: http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Tom Thomson)
Subject: Re: prob. of a given subsequence in a sequence
Date: Fri, 12 Mar 99 10:42:34 GMT
In article <7c8p2s$aup$[EMAIL PROTECTED]>, "Gustavo" <[EMAIL PROTECTED]>
wrote:
>Hi everyone.
>I would like to know how to compute the probability
>that a given subsequence of length S is part of a
>larger random sequence of length L.
>It seems that the probability depends on the sub-
>sequence (maybe on its autocorrelation properties?)
>but I have not been able to find the relation yet.
>Thank you very much for any help.
>Gustavo
If you mean something reasonable by "random sequence of length L" this is a
very easy thing to compute, and doesn't depend on any properties of S apart
from its length.
However, it depends what you mean by "subsequence"; for example is (111) a
subsequence of (10101)?
Assuming that you mean a set of adjacent consecutive values (so that (111) is
not a subsequence of (10101)) there are L+1-S subsequences of length S in the
longer sequence, and each of these has probability x^-S of being the shorter
sequence (if each sequence element can take on x different values). So the
probability that at least one of them is the shorter sequence is
1- (1-x^-S)^(L+1-S)
------------------------------
From: [EMAIL PROTECTED] (Peter L. Montgomery)
Subject: Re: prob. of a given subsequence in a sequence
Date: Fri, 12 Mar 1999 11:12:30 GMT
In article <7car2q$[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Tom Thomson) writes:
>In article <7c8p2s$aup$[EMAIL PROTECTED]>, "Gustavo" <[EMAIL PROTECTED]>
>wrote:
>>I would like to know how to compute the probability
>>that a given subsequence of length S is part of a
>>larger random sequence of length L.
>>It seems that the probability depends on the sub-
>>sequence (maybe on its autocorrelation properties?)
>>but I have not been able to find the relation yet.
>If you mean something reasonable by "random sequence of length L" this is a
>very easy thing to compute, and doesn't depend on any properties of S apart
>from its length.
The probability does vary with the first sequence.
The sequence 111 of length 3 is included within three sequences
(1110, 1111, 0111) of length 4. The sequence 101 of length 3 is included
within four sequences (1010, 1011, 0101, 1101) of length 4.
Note 111 appears twice in 1111.
--
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: How to PROPERLY implement CFB8 for DES?
Date: 12 Mar 1999 11:26:48 GMT
According to Augustin Volker <[EMAIL PROTECTED]>:
> Hi! I have a DES algorithm working properly in ECB mode. Now I
> wrote CFB mode and compared it to the one Sun implements in the
> Java Cryptographic Extension 1.2 beta2. The problem is, that there
> are differences. First of all, when I do padding in CFB8 mode, I
> always pad 1 byte. Sun seems to pad 1 to 8 bytes. Then, the output
> is different. Can anyone give a detailed description on how to
> implement CFB8 using a working DES cipher which has a function,
> say encryptBlock(byte[] input, int inputOffset, byte[] output, int
> outputOffset, length)? (length should be DES blocksize in this case).
See Change #2 of FIPS PUB 81 (1996 May 31), NIST. It should be available
from http://www.nist.gov
Fabrice
------------------------------
From: [EMAIL PROTECTED]
Subject: RC4 file encryptor (please take a look)
Date: Fri, 12 Mar 1999 11:50:59 GMT
I use RC4 as the base, then I use a passphrase as a private key, and mouse
movements for the public key. It's compiled with Micro-C but I included a
binary for x86 platforms.
Basically I want to have people evaluate the effectiveness of the public_key
portion.
Thanks,
Tom
RC4E: http://members.tripod.com/~tomstdenis/rc4e.zip
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: moc.lis@elyalp (Mike Playle)
Subject: Re: Crypto transmission in noisy ambient
Date: Fri, 12 Mar 1999 13:35:09 GMT
Reply-To: moc.lis@elyalp <- Reverse if replying by Email!
On Thu, 11 Mar 1999 22:01:28 -0200, "F. Arndt" <[EMAIL PROTECTED]>
wrote:
>A low-power but strongly encrypted (RSA or ElGamal) exchange in the
>presence of noise AND interference, such as often prevails in wireless
>comm, would seem to be problematical.
Why not use the "confusion sequence" from a stream cipher as the
"spread code" for a spread-spectrum wireless link? This would be
hard to receive correctly (or even detect!) without the key but
shouldn't increase the BER...
any thoughts?
------------------------------
From: [EMAIL PROTECTED]
Subject: RSA-examples
Date: Fri, 12 Mar 1999 13:31:29 GMT
Hello,
The update of my RSA examples implemented as MS Access
data base(354Kb.ZIP) contains 36 tables. There is
following name convention. A table with the name 'tab_P_Q_M'
represents a modulus, where P and Q are prime multiplier of
the modulus and M is the period.
If (n,e) is a key and p is the period then (n,e+k*p) are keys
with the same en/decryption. A period can be found as follows.
Let n=11*13 be a modulus. 11-1= 2*5. 13-1=2*2*3.
The period of 11*13 is 5*2*2*3=60.
A period is responsible for all different key pairs. This is why
tables with the name ‘PGP_M’, where M is a period, contain all
possible pairs of exponents, which can be used for en/decryption.
Pairs, which contain different exponents, represent asymmetric
encryption. There are pairs, which contain equal exponents.
Such exponent represent symmetric encryption. For example.
Suppose your modulus is 11*13. The name of the correspondent
table is ‘tab_11_13_60’. While period is 60 you can find all
possible key pairs in the table ‘PGP_60’.
The examples can be used for learning more about RSA encryption
and checking your RSA implementation.
You can download examples from:
www.online.de/home/aernst/RSA.html
My own encryption, implemented as stream and block cipher, with
detailed algorithm description, freeware executables, Delphi 4
source code you can find at
www.online.de/home/aernst
Best regards
Alex
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Fri, 12 Mar 1999 16:01:39 +0100
R. Knauer wrote:
>
> There is nothing in the specification of the TRNG that says it must be
> run continuously. It can be stopped for diagnostic evaluation anytime
> - especially when the output has the characteristic of a severly
> pathological condition, namely a grounded or floating output.
>
> ................
>
> The authors of the book "Stream Ciphers and Number Theory" discuss
> additive mixing schemes and point out their vulnerablilty. They go on
> to recommend other mixing schemes to prevent such vulnerabilities.
> Thus, a sequence of all 0s would not expose any cleartext message if
> the mixing is cryptographically strong - the cryptanalyst would have
> no reason to know that the keystream was composed of a run of 0s.
I am afraid there is a problem with the above two paragraphs. If one
applies, say, the FIPS test in diagnostic evaluation then a sequence
of all 0s certainly fails. Are you suggesting stop using the generator
or using the sequence nonetheless?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Fri, 12 Mar 1999 15:19:25 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 12 Mar 1999 16:01:39 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> There is nothing in the specification of the TRNG that says it must be
>> run continuously. It can be stopped for diagnostic evaluation anytime
>> - especially when the output has the characteristic of a severly
>> pathological condition, namely a grounded or floating output.
>> The authors of the book "Stream Ciphers and Number Theory" discuss
>> additive mixing schemes and point out their vulnerablilty. They go on
>> to recommend other mixing schemes to prevent such vulnerabilities.
>> Thus, a sequence of all 0s would not expose any cleartext message if
>> the mixing is cryptographically strong - the cryptanalyst would have
>> no reason to know that the keystream was composed of a run of 0s.
>I am afraid there is a problem with the above two paragraphs. If one
>applies, say, the FIPS test in diagnostic evaluation then a sequence
>of all 0s certainly fails.
What do you mean by "fails"? Statistical tests are only useful as
diagnostic warnings, not as means of characterizing the proper
operation of a properly designed TRNG.
Once alerted to a potential problem, the TRNG must be tested
internally, like any piece of scientific equipment.
> Are you suggesting stop using the generator
>or using the sequence nonetheless?
Of course, you would have to stop the TRNG if you were going to run
internal diagnostic tests on its subsystem. But you can buffer the
suspect output for subsequent use if it happens that the TRNG was not
malfunctioning.
What is so wrong about a run? As long as it is not too long, what harm
can it have? I am assuming that the stream cipher is constructed by
some kind of strong mixing algorithm that prevents plaintext attacks -
the Simple OTP is not suitable since its additive mixing algorithm
(the XOR operation) exposes plaintext with a null key, and exposes the
key itself if the plaintext is known. If the OTP is created from a
stong mixing algorithm, how is the cryptanalyst ever going to know
that there was a run in the key?
Statistical testing, which can only test for some vague notion of the
*appearance* of what is supposed to be randomness in the limit of
large numbers, causes all sorts of conceptual difficulties - and that
thwarts design efforts for strong cryptosystems.
There is a notion called "good + bad = good" which is discussed in
that book "Stream Ciphers and Number Theory" I have cited many times
here. I believe I will start a new thread on that topic, since it
seems that if that principle is correct, some interesting things can
be done in crypto might otherwise be considered bad practice.
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
Date: Fri, 12 Mar 1999 10:30:20 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Crypto transmission in noisy ambient
F. Arndt wrote:
>
> A low-power but strongly encrypted (RSA or ElGamal) exchange in the
> presence of noise AND interference, such as often prevails in wireless
> comm, would seem to be problematical. The conventional approach of
> retransmitting until check-sums or CRC are satisfied is probably
> standard operating procedure, but are there clever ways of making the
> process distinctly more efficient for a given bit error rate (BER)?
You can use Error Correcting Codes (ECC) at the expense of increasing
your packet size by log2(oldpacketsize)+K bits where K is related to the
number of bits errors per packet that you want to dectect and possibly
corect.
------------------------------
From: Information Mechanincs <[EMAIL PROTECTED]>
Subject: Seeking an Algorithm !
Date: Fri, 12 Mar 1999 15:39:15 GMT
Hi,
I'm wondering if anyone knows of a crypto algorithm that meets the
following requirements.
1) Ciphertext size = plaintext size
2) Works for streaming data and local files
3) Supports random access
4) Is a known, well-analyzed, robust system.
5) Is unencumbered by patent/licensing restrictions.
Am I dreaming ? If so, can I get 3 or 4 out of 5 ?
Thanks,
Gord 8-)>
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 12 Mar 1999 10:42:33 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
>>
>
>> What you are discussing is "algorithmic complexity randomness" of the
>> Kolmogorov-Chaitin variety, which is unsuitable for use in crypto. I
>> am not saying that you intended it to serve as a specification for
>> crypto-grade randomness, I am merely pointing out that it is
>> unsuitable because it excludes regular sequences which are allowed in
>> the specification of a (crypto-grade) TRNG.
>
>Apart of the fact that there is no algorithm to determine the
>Kolmogorov complexity, I think there is an additional difficulty.
>From programming one knows that different programs can do the
>same job but can be with widely differing efficiency. Suppose
>there is a shortest program to compute a given sequence and
>there is another program twice as long but with an efficiency
>of several orders of magnitude higher. It appears not obvious then
>why the length of the shortest program can be a suitable measure of
>complexity.
Well, in a security context, the efficiency of the program is
directly related to how much computational effort -- in terms of
time and money -- will be required to re-create a given sequence.
Unless for some reason you are willing to postulate a limit on the
amount of time that the opponent has at his disposal, the efficiency
of the program is irrelevant.
-kitten
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Seeking an Algorithm !
Date: Fri, 12 Mar 1999 16:28:30 -0000
(IIRC) The stream cipher SEAL fulfils 1,2,3,4 but is patented by IBM.
Any other reasonable stream cipher (or a block cipher in CFB) should
fulfil most of the conditions, apart from 3.
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
Information Mechanincs wrote in message
<[EMAIL PROTECTED]>...
>Hi,
> I'm wondering if anyone knows of a crypto algorithm that meets
the
>following requirements.
>
>1) Ciphertext size = plaintext size
>2) Works for streaming data and local files
>3) Supports random access
>4) Is a known, well-analyzed, robust system.
>5) Is unencumbered by patent/licensing restrictions.
>
>Am I dreaming ? If so, can I get 3 or 4 out of 5 ?
>
>Thanks,
> Gord 8-)>
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: CD Cipher
Date: Fri, 12 Mar 1999 15:58:29 GMT
Reply-To: [EMAIL PROTECTED]
I refer you to Sec. 2.1.5 (p. 18) of the book "Stream Ciphers and
Number Theory".
In that section, the authors propose a system which combines the best
of stream ciphers and block ciphers, and prevents traditional attacks
on those cipher methods. The even go so far as to say that because
this Cooperatively Distributed Cipher (CD Cipher) is strong, that one
can use relatively week keystreams and relatively weak block
encryption methods. IOW, "good + bad = good".
The basic idea is that there are multiple block cipher keys Ki, where
i enumerates them. The main keystream K is used to select which Ki to
use on a given block of plaintext P. Thus the entire key is (K, {Ki}).
According to the authors, this is the best of two worlds, since it
prevents both block cipher attacks and stream cipher attacks. As they
point out, block cipher attacks work because they use only one key,
which is no longer the case here. Stream cipher attacks work because
of additive mixing, which is no longer the case here.
The simplest implementation is for i = 0, 1 - that is, there are two
disctinct keys for block encryption present. Then the bits of the main
keystream K act as selectors for which Ki to use for a given block of
plaintext.
If I read all this correctly, then one could presumably use a weak
main keystream generator and a weak block encryption method to form
the basis of a strong system. IOW, the only keys that need to be sent
along a secure channel are the seedkey for the main keystream
generator and the two keys for block encryption. If one used a 128 bit
seedkey for the main PRNG and two DES block encryption keys, then the
total key for the system would be only 240 bits.
To make this system even stronger one could use two completely
different block encrytion methods with different block sizes, such
that the block sizes are not commensurate. That way the attacker will
not know the block boundaries in the ciphertext.
Your considered comments, please.
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
Date: Fri, 12 Mar 1999 09:38:17 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Seeking an Algorithm !
Information Mechanincs wrote:
>
> Hi,
> I'm wondering if anyone knows of a crypto algorithm that meets the
> following requirements.
>
> 1) Ciphertext size = plaintext size
> 2) Works for streaming data and local files
> 3) Supports random access
> 4) Is a known, well-analyzed, robust system.
> 5) Is unencumbered by patent/licensing restrictions.
>
> Am I dreaming ? If so, can I get 3 or 4 out of 5 ?
It seems to me that this is more a question of how an algorithm might be
applied in the application rather than the choice of algorithm itself.
As for applications, one that comes to mind as being similar is the
Scramdisk or PGPdisk applications which allow you to store data into an
encrypted logical volume.
The security requirements of the app should be considered too. Do you
need military-grade, by-gawd-never (we think?) security or do you simply
need something that's fast?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Fri, 12 Mar 1999 16:22:43 +0100
R. Knauer wrote:
>
> What you are discussing is "algorithmic complexity randomness" of the
> Kolmogorov-Chaitin variety, which is unsuitable for use in crypto. I
> am not saying that you intended it to serve as a specification for
> crypto-grade randomness, I am merely pointing out that it is
> unsuitable because it excludes regular sequences which are allowed in
> the specification of a (crypto-grade) TRNG.
Apart of the fact that there is no algorithm to determine the
Kolmogorov complexity, I think there is an additional difficulty.
>From programming one knows that different programs can do the
same job but can be with widely differing efficiency. Suppose
there is a shortest program to compute a given sequence and
there is another program twice as long but with an efficiency
of several orders of magnitude higher. It appears not obvious then
why the length of the shortest program can be a suitable measure of
complexity.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 12 Mar 1999 12:01:36 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>>
>
>> >Apart of the fact that there is no algorithm to determine the
>> >Kolmogorov complexity, I think there is an additional difficulty.
>> >From programming one knows that different programs can do the
>> >same job but can be with widely differing efficiency. Suppose
>> >there is a shortest program to compute a given sequence and
>> >there is another program twice as long but with an efficiency
>> >of several orders of magnitude higher. It appears not obvious then
>> >why the length of the shortest program can be a suitable measure of
>> >complexity.
>>
>> Well, in a security context, the efficiency of the program is
>> directly related to how much computational effort -- in terms of
>> time and money -- will be required to re-create a given sequence.
>> Unless for some reason you are willing to postulate a limit on the
>> amount of time that the opponent has at his disposal, the efficiency
>> of the program is irrelevant.
>
>I suppose that computational cost is a relevant practical issue.
But one the other hand, if you assume a large amount of time available,
for example, in an off-line attack, then it doesn't make sense to
be worried about the efficiency of the generator and the size of
the generator is a reasonable measure of complexity.
-kitten
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Fri, 12 Mar 1999 17:49:03 +0100
Patrick Juola wrote:
>
> >Apart of the fact that there is no algorithm to determine the
> >Kolmogorov complexity, I think there is an additional difficulty.
> >From programming one knows that different programs can do the
> >same job but can be with widely differing efficiency. Suppose
> >there is a shortest program to compute a given sequence and
> >there is another program twice as long but with an efficiency
> >of several orders of magnitude higher. It appears not obvious then
> >why the length of the shortest program can be a suitable measure of
> >complexity.
>
> Well, in a security context, the efficiency of the program is
> directly related to how much computational effort -- in terms of
> time and money -- will be required to re-create a given sequence.
> Unless for some reason you are willing to postulate a limit on the
> amount of time that the opponent has at his disposal, the efficiency
> of the program is irrelevant.
I suppose that computational cost is a relevant practical issue. No
one of this world has or will have infinite resources. At least
certain real-life systems are considered secure (yet) because the
amount of resources for cracking them are currently infeasible.
M. K. Shen
------------------------------
Date: Fri, 12 Mar 1999 09:28:58 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: PGP source code documentation
[EMAIL PROTECTED] wrote:
> I would to know if it possible to get the documentation of PGP source code.
> Actually I am looking the PGP source code and it is not really easy to
> understand.
That's probably the understatement of the century. There are many
web-pages that are more-or-less devoted to PGP and to the various
cryptographic algorithms that it employs. (Try a search on "PGP" with
Yahoo and you'll see what I mean.)
Any cryptographic algorithm involves (a) fancy bit-twiddling; and (b)
enough of (a) to warrant the use of 'clever' coding ... which usually
means 'practically unreadable, but fast.'
But there is a considerable amount of publicly-available material and
examples on the specific ciphers.
------------------------------
** 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
******************************
