Cryptography-Digest Digest #236, Volume #9 Mon, 15 Mar 99 12:13:07 EST
Contents:
Re: Cipher for chat program ("F. Arndt")
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED ("Douglas A. Gwyn")
hash in javascript ("sol")
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED ("Douglas A. Gwyn")
Re: my SHC (dan)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
How "safe" is SafeGuard Easy for WinNT by Utimaco? (Daniel Kinnaer)
Re: Seeking an Algorithm ! (Mok-Kong Shen)
Test vectors for RC4 (Dominik Werder)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Patrick Juola)
Re: pRNG that is "predictable to the left"? (Mok-Kong Shen)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Re: Quantum Computation and Cryptography (Henry Lewsal)
Re: pRNG that is "predictable to the left"? (Mok-Kong Shen)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Doug Stell)
Re: Crypto transmission in noisy ambient (Doug Stell)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "F. Arndt" <[EMAIL PROTECTED]>
Subject: Re: Cipher for chat program
Date: Mon, 15 Mar 1999 09:21:13 -0200
Forgive me for a dumb question: Why must the SERVER encrypt/decrypt?
It would seem only chat CLIENTS need to share a secret key.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 15 Mar 1999 08:43:26 +0100
Patrick Juola wrote:
>
> Because that's the way that Kolmogorov complexity is defined;
> optimization for program size. This particular definition works
> out to have some useful mathematical properties, too, which is why
> Kolmogorov's papers didn't sink without a trace.
One can certainly 'define' something that has interesting mathematical
properties. But we are interested in applications in cryptography
here.
> If you want to define the complexity of a sequence as the minimum amount
> of *time* it takes to output the sequence, defined over all possible
> programs, that's simply a different complexity measure. And, in
> practical terms, pretty useless -- the minimum time is just proportional
> to the length of the string and obtained by a sequence of write()
> calls.
By what arguments did you establish the 'proportionality'? In any
program there are time for input, compute and output. The three
parts may consume entirely different portions of the total processing
time depending on algorithms and also programming skill.
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Mon, 15 Mar 1999 14:31:32 GMT
[EMAIL PROTECTED] wrote:
> ... sometimes I think, given, for example, all the times we hear
> that "Since the one-time-pad is perfect, we don't _need_ anything
> else", or the opposite - that we should all be using RSA and
> Blum-Blum-Shub to the exclusion of conventional symmetric
> techniques (they just look messy, nobody has _proven_ anything
> about them) - that the academic and commercial cryptographic
> communities could perhaps learn from my humble suggestions of how
> one can *use* public-key cryptographic techniques and yet not
> *rely* on their security: use them to avoid relying exclusively
> on other methods of key management, which have their own problems.
Yes, certainly the open crypto community doesn't currently have
ultimate solutions to all our crypto needs. If I were king,
nobody would be allowed to work on creating crypto systems until
after he has cracked several really tough ones.
------------------------------
From: "sol" <[EMAIL PROTECTED]>
Subject: hash in javascript
Date: Mon, 15 Mar 1999 14:02:51 -0000
i do not trust 128 bit ssl as much as i did yesterday ,so i dont realy
want throw passwords accross it now
if i could implament a hash in javascript on the client (proboblay take a
year right) i would pefer to pass that and compare that to a pre hashed one
on the server
davidk
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Mon, 15 Mar 1999 14:34:28 GMT
[EMAIL PROTECTED] wrote:
> I keep having this nagging feeling that Canada, instead of designing its
> own crypto gear, is equipping its military with devices purchased from the
> U.S.. While our two countries are great friends, to me this still seems
> strange.
Canada, Australia, Great Britain, and the United States have long
had a cooperative arrangement in this field. Presumably, if one
country uses systems devised by another, it is to avoid wasteful
duplication of effort.
------------------------------
From: dan <[EMAIL PROTECTED]>
Subject: Re: my SHC
Date: Mon, 15 Mar 1999 14:26:59 GMT
>From your source code: "The goal behind this algorithm is to provide a quick
and secure manner to verify data."
A hash function with 64 bit output would not generally be considered "secure"
because it falls victim to a birthday attack in approximately 2^32 effort. In
other words, you can easily find two files (or messages) that have the same 64
bit hash value, and substitute one for the other.
In fact, since 128 bit hashes fall with 2^64 effort, they are also becoming
questionable. Most "new" hashes have longer output: SHA and RIPE-MD are 160
bits, Tiger is 192 bits, and HAVAL has variable outputs up to 256 bits. (Only
Tiger is really new, and it's optimized for 64-bit processors.)
Also, see the MDx specs for how to pad the message. For instance, to prevent
message extension attacks, include the message length in the hash value.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 15 Mar 1999 09:32:36 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>>
>
>> Because that's the way that Kolmogorov complexity is defined;
>> optimization for program size. This particular definition works
>> out to have some useful mathematical properties, too, which is why
>> Kolmogorov's papers didn't sink without a trace.
>
>One can certainly 'define' something that has interesting mathematical
>properties. But we are interested in applications in cryptography
>here.
So the question isn't whether or not K-complexity is well-defined
or why it has the definition it does. The question is whether or
not it has any direct cryptographic applications. And the answer
is, in general, not many; it's an interesting measure of randomness
for the discussions where randomness is relevant. On the other hand,
almost all cryptographic sequences of interest have a very *low*
Kolmogorov complexity as they are the product of a relatively small
encryption algorithm/program.
>
>> If you want to define the complexity of a sequence as the minimum amount
>> of *time* it takes to output the sequence, defined over all possible
>> programs, that's simply a different complexity measure. And, in
>> practical terms, pretty useless -- the minimum time is just proportional
>> to the length of the string and obtained by a sequence of write()
>> calls.
>
>By what arguments did you establish the 'proportionality'? In any
>program there are time for input, compute and output. The three
>parts may consume entirely different portions of the total processing
>time depending on algorithms and also programming skill.
For a fixed string/sequence, the time required to output that string is
also fixed; the input and computing portions of the time are rather trivially
reduced to zero (or a near-zero constant) by simply coding the program as :
main()
{
printf("...");
}
This will, of course, output any desired string in time proportional
to the length of the string; this is provably optimal for all components.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Daniel Kinnaer)
Subject: How "safe" is SafeGuard Easy for WinNT by Utimaco?
Date: Mon, 15 Mar 1999 14:41:16 GMT
I would like to know how 'good' SafeGuard Easy for WinNT by Utimaco
really is. Is it easy to use, are there any known bugs? Is it really
that safe as it claims to be? Can hackers 'crack' my system if I
would install it on my PC?
All information is deeply appreciated. Thanks
Daniel
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Seeking an Algorithm !
Date: Mon, 15 Mar 1999 15:46:26 +0100
Rich Wales wrote:
>
> Mok-Kong Shen wrote:
>
> > 3) Supports random access
> What does 3) mean?
>
> I suppose "random access" would mean that a relatively small block of
> data could be encrypted or decrypted all by itself, independently of the
> rest of the file.
>
> This usually isn't a good idea in typical applications, because it gives
> the "enemy" more chances to mount a known-plaintext attack. But in an
> encrypted file system, it may make sense to encrypt each disk block all
> by itself -- just as separate blocks in a compressed file system would
> typically be compressed independently of one another.
I don't yet quite catch your point. A disk block is normally fairly
large, depending on OS. If you use a block algorithm of, say, 64 bits
then the disk block size is certainly a multiple of encrption block
size. For stream cipher working on bytes or bits as units the problem
of exact multiples does not exist.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Dominik Werder)
Subject: Test vectors for RC4
Date: Mon, 15 Mar 1999 14:22:24 GMT
Hello!
I search some test vectors for the RC4 algorithm.
And I have a question: How strong is RC4 as encryption algorithm?
(normal RC4, plainbyte XOR pseudo-random-byte)
thanks!
DoMiNik
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: 15 Mar 1999 09:43:21 -0500
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> I keep having this nagging feeling that Canada, instead of designing its
>> own crypto gear, is equipping its military with devices purchased from the
>> U.S.. While our two countries are great friends, to me this still seems
>> strange.
>
>Canada, Australia, Great Britain, and the United States have long
>had a cooperative arrangement in this field. Presumably, if one
>country uses systems devised by another, it is to avoid wasteful
>duplication of effort.
I can also see it being very useful to insure interoperability.
Since 1945 -- possibly since 1918 -- I believe that every war that
the United States has been involved in, so has Canada. On the
same side, generally in fairly close cooperation. As a classic example,
of the five D-Day beaches in Normandy, the Yanks took two and the
Canucks took one. Both were operating under more or less the same
air, naval, and supply situation and had to communicate with the
same set of rear echelon folks.
If everyone uses the same signals gear, everyone only needs to carry
one set of equipment (and one set of spare parts, batteries, &c).
Signals can be sent via the same codes to everyone, which increases
operational security. The only reason it would be a problem would be
if Canada decided to invade the US (or vice versa), which doesn't seem
to be a likely scenario to me. I think we're more likely to see
Quebec invade Newfoundland.
-kitten
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: pRNG that is "predictable to the left"?
Date: Mon, 15 Mar 1999 15:27:51 +0100
Christoph Haenle wrote:
>
>
> I'm looking for a pseudorandom number generator that _is_ predictable
> to the left, but unpredictable to the right. Intuitively, if the
> random number generator produces values x_1, x_2, etc. I want someone
> who knows x_n to be able to recover all previous values, but not the
> next ones. Also, given x_n, any x_i, i<n should be _easily_ computable
> (that is, no backwards-iteration through x_{n-1}, x{n-2}, should be
> needed).
>
> How could I go about? Would the following RSA-based scheme work?
>
> x_1 = {seed}^d mod n
> x_2 = {seed}^(2d) mod n
> x_3 = {seed}^(3d) mod n
> ...
Maybe I misunderstood you entirely, but isn't x_5 = x_2 * X_3 etc?
So you do get plenty of next ones quite easily.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 15 Mar 1999 16:02:20 +0100
Patrick Juola wrote:
> >
> >> If you want to define the complexity of a sequence as the minimum amount
> >> of *time* it takes to output the sequence, defined over all possible
> >> programs, that's simply a different complexity measure. And, in
> >> practical terms, pretty useless -- the minimum time is just proportional
> >> to the length of the string and obtained by a sequence of write()
> >> calls.
> >
> >By what arguments did you establish the 'proportionality'? In any
> >program there are time for input, compute and output. The three
> >parts may consume entirely different portions of the total processing
> >time depending on algorithms and also programming skill.
>
> For a fixed string/sequence, the time required to output that string is
> also fixed; the input and computing portions of the time are rather trivially
> reduced to zero (or a near-zero constant) by simply coding the program as :
>
> main()
> {
> printf("...");
> }
>
> This will, of course, output any desired string in time proportional
> to the length of the string; this is provably optimal for all components.
I thought we were considering a program of the Komolgorov type which
I presume involve some genuine computations and not a program that
is written to directly print the sequence as you indicated.
M. K. Shen
------------------------------
From: Henry Lewsal <[EMAIL PROTECTED]>
Subject: Re: Quantum Computation and Cryptography
Date: Mon, 15 Mar 1999 05:31:46 -1000
R. Knauer wrote:
>
> On 12 Mar 1999 23:44:57 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>
> >Nand gates cannot be reversible. You can create a gate with two output
> >channels which is reversible. But nothing which takes two inputs and
> >produces one output can ever be reversible.
>
> >With a nand gate, you have three input states which go to the same
> >output. Thus you would need the second output to have three possible
> >states-- it could not be a binary output.
>
> What about a Freidken gate?
>
> Bob Knauer
What material is that gate made from? Wishes? Dreams? Hopes?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: pRNG that is "predictable to the left"?
Date: Mon, 15 Mar 1999 16:41:39 +0100
Christoph Haenle wrote:
> Oops, sorry, you're right, should be
>
> x_1 = {seed}^d
> x_2 = {seed}^(d^2)
> x_3 = {seed}^(d^3)
> ...
I still don't quite understand. Would you, for example, detail
how one computes from X_5 the previous values? If the analyst
gets to X_1, what deters him from computing forwards from there?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Mon, 15 Mar 1999 15:25:52 GMT
On 13 Mar 99 20:26:56 GMT, [EMAIL PROTECTED] () wrote:
John,
>The main thing new in the article is the revelation that there was great
>nervousness at the GCHQ about the very thing I've expressed concern in
>some of my early posts: that there could be a mathematical discovery that
>would vitiate the security of RSA, Diffie-Hellman, and other public-key
>ciphers, because they rely on a narrow range of techniques.
This is always a concern in this business, escpecially when going into
uncharted waters and it could still happen today.
>Even more sensitive, the revelation that one wasn't found by 1977 when the
>technique was publicly discovered.
And if one had been or will be found, you probably wouldn't know about
it, unless it was found by an academic type. If the GCHQ or NSA knows
of a hole and the public thinks there is no hole, that is the perfect
position to be in.
>And, because of this concern, I expressed some doubt that, as some books
>have claimed, that the STU-III or other current advanced encryption
>equipment would operate without key material in the manner of a copy of
>PGP.
Devices often have provision for emergency use inder certain tactical
situations. However, the user is well aware of when such provisions
are invoked. I doubt that PGP is a realistic example.
> But I noted that one could still use public-key techniques, even if
>one doesn't fully trust them, as one leg of a 'triad', to use a term from
>nuclear defense terminology. And so, I will summarize a point I tried to
>make in another post some time ago:
>
>Key hidden in hardware - compromised through reverse-engineering of
>captured hardware.
This is a common technique, but the key is zeroized upon tamper.
Therefore, reverse engineering is not that much of an issue, given
good engineering practices. However, such keys are generally not used
for this purpose.
>Key loaded by personnel - vulnerable through suborning of personnel.
This too has been addressed and solved by the big boys. The John
Walkers have been put out of business by technology. The techniques
are called Benign Fill Techniques and are used with Over The Air Rekey
(OTAR).
>Key generated and used via public-key mechanisms - vulnerable through
>mathematical advances.
If history is a good indicator of the future, there isn't much worry
here either.
>If you're handling military secrets, use all three mechanisms - each one
>with a key big enough so that if one of the three keys only remains
>secure, your communications are secure. If the 'big boys' _aren't_ doing
>this, they should start thinking about it.
In the US, all classified traffic must be protected by NSA-provided
techniques (cryptographic and design/implementation) and NSA-approved
equipment. The "big boys" are well beyond this type of thinking and
they really do know how to do it right. Remember that our friends are
also some else's enemies and they know what they are capale of doing
on the other side of the situation.
>I keep having this nagging feeling that Canada, instead of designing its
>own crypto gear, is equipping its military with devices purchased from the
>U.S.. While our two countries are great friends, to me this still seems
>strange.
The US does share a lot with its English-speaking allies. There are 5
countries, called the AUSCANZUKUS.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Crypto transmission in noisy ambient
Date: Mon, 15 Mar 1999 14:59:16 GMT
On Fri, 12 Mar 1999 16:17:50 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, "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. 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)?
Techiques I've seen and used on products that operate on low
bandwidth, high error rate channels are:
1. forward error correction to reduce the need for retransmission
2. large number of short packets that have a higher probability of
getting through
3. an underlying packet retransmission mechanism
4. short keys and messages, a good case for EC
5. very efficient protocols
6. traffic encryption that does not have error extension
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 15 Mar 1999 16:53:41 +0100
Patrick Juola wrote:
>
> So the program I defined above provides an upper bound on the
> Kolmogorov complexity of a string; more formally, it's a theorem
> that K(x) <= |x|. There's also a theorem that, for any reasonable
> definition of randomness, a random string has K-complexity *equal*
> to its length.
This is well-known. But I am still ignorant of why the definition
of Kolmogorov, that is void of any connection to computational cost,
can be a good definition of 'complexity', apart from mathematical
interests that you indicated.
M. K. Shen
------------------------------
** 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
******************************
