Cryptography-Digest Digest #319, Volume #10 Mon, 27 Sep 99 17:13:03 EDT
Contents:
Re: Schrodinger's Cat and *really* good compression (John Savard)
Re: frequency of prime numbers? ("karl malbrain")
Re: Increasing password security dramatically without making it harder to
remember ("Gary")
Re: simple algorithm for hardware device? (Enterrottacher Andreas)
Re: Schrodinger's Cat and *really* good compression ("Tony T. Warnock")
Re: Example of a one way function? ("Trevor Jackson, III")
Re: NEMA, Swiss cipher machine (John Savard)
Re: simple algorithm for hardware device? ("Trevor Jackson, III")
Re: Electronic envelopes (DJohn37050)
Re: Increasing password security dramatically without making it harder to remember
(Johnny Bravo)
Re: Example of a one way function? (Patrick Juola)
SNAKE: RATTLER (Peter Gunn)
Re: Schrodinger's Cat and *really* good compression (John Savard)
Re: simple algorithm for hardware device? (Paul Rubin)
Re: Requirement for Uniqueness in Decryption Keys (Patrick Juola)
Meeting BXA req. for online dist? (Richard Hyde)
Electronic envelopes (Mok-Kong Shen)
EFS (Bill Lynch)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Schrodinger's Cat and *really* good compression
Date: Mon, 27 Sep 1999 19:01:08 GMT
Alan Braggins <[EMAIL PROTECTED]> wrote, in part:
>One explanation I've seen is that the cat is just as good an observer
>and causes a collapse inside the box, but leaves the box as whole in a
>superposition. Then when the box is opened there is another collapse,
>but the cat/box/experimenter system is still in a superposition. Then
>when the lab door is opened and someone else asks "How's the cat?"
>there is another collapse. Then when the paper is published there is
>another collapse for each reader who previously didn't know what state
>the cat was in, and so on, ad infinitum.
Actually, opening the lab door won't cause a collapse; that collapse
will have happened beforehand, unless the lab was *very* well
insulated.
However, the idea that the cat prevents the radioactive atom from
being in a superposed state - from the cat's viewpoint - but the
system of cat plus atom can still be superposed is _almost_ not even
an interpretation. It *is* true that any system in a superposition of
states will be in a superposition of *plausible* states, and the
cat-alive state will have an undecayed atom, not a superposed one, and
the cat-dead state will have a decayed atom, not a superposed one.
The thing is, though, that instead of the wave function of the
particle collapsing, the superposition has instead spread to the cat
from a "cosmic" viewpoint; the collapse seen by the cat is an illusion
brought on by the cat's viewpoint while being subjected to
superposition. Hmm...
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Mon, 27 Sep 1999 11:30:41 -0700
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Trevor Jackson, III" wrote:
> > Sure they can. In this context "proved" does not mean "show to be true"
it means
> > "truth value resolved", which applies to both possible truth values.
>
> No wonder I didn't understand what you were saying.
> You should have used the standard term "decidability";
> "proof" means a valid derivation.
PROOF is grounded in the (ancient?) MASTER-APPRENTICE relationship, long
before the distribution of knowledge from TIMBUKTU ever occured. The MASTER
grants that his APPRENTICE owns the ability to practice the craft as a
JOURNEYMAN. Hence, Trevor's notation of `value resolved' is most fitting.
Karl M
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp
Subject: Re: Increasing password security dramatically without making it harder to
remember
Date: Mon, 27 Sep 1999 19:39:30 +0100
A weak key is hashed and then that hash hashed and so on and so on.
On the average machine say it took 10 seconds and then the result was used
as the password.
Is this analogous to key stretching?
------------------------------
From: Enterrottacher Andreas <[EMAIL PROTECTED]>
Subject: Re: simple algorithm for hardware device?
Date: Mon, 27 Sep 1999 20:07:59 +0100
Luigi Funes schrieb:
>
> Hi all! I wonder if someone can help me!
>
> I'm building a high speed hardware encryption/decryption
> device working on a data stream of 16 bit words.
> Data coming in variable size packets at 40 Mword/sec
> and every word must be encrypted almost immediately, more
> exactly the delay between the input and output of a every
> word must be < 5 nS.
> With this timing requirements and using low-cost FPGAs,
> I belive it's impossible to implement strong algorithms
> doing more than one round. Of course, for this
> application a weak algorithm breakable in few hours by a
> Pentium is good enough. :-)
I don't think it is neccessary to use a weak algorithm only
because of these limitations.
> I already succesfully tested a prototipe, using a trivial
> algorithm XORing data and a LFSR, but now I have to
> implement something of better.
> Note the algorithm can be kept secret, because it's
> hidden inside the FPGA, but a enemy could steal the
> device, setup any key and encrypt and analyze any data.
> Besides, the enemy knows the plain texts of many
> encrypted data.
> Someone can suggest me an algorithm for this device?
> ...
The simplest solution I know would be the alternating
stop-and-go-generator. You'll need three LFSRs:
One is used to chose which of the two others will be clocked.
The output of the other ones (the one that is clocked and
the one that holds the output of the last sound) is XORed
to get the next bit in the keystream.
You'll have to shift two registers per bit.
As long as all three LFSRs are large enough, the tab sequence
is complex enough and no key is used twice this cipher should
be secure.
There are lots of other constructions using LFSRs that
provide good security (A5 would be another good choice).
I wouldn't rely on a secret algorithm. To provide better
security you could use a number of different tab sequences
as part of the key, but expect the attacker to be able to
get all possible tab sequences.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Schrodinger's Cat and *really* good compression
Date: Mon, 27 Sep 1999 12:35:23 -0600
Reply-To: [EMAIL PROTECTED]
"Erwin," said Frau Schroedinger, "What did you do to the cat; it looks
half dead."
------------------------------
Date: Mon, 27 Sep 1999 14:34:51 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Example of a one way function?
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> >Boris Kolar <[EMAIL PROTECTED]> wrote:
> >: Roger Carbol <[EMAIL PROTECTED]> wrote in message
> >:> I. Michael Mandelberg <[EMAIL PROTECTED]> wrote:
> >
> >:> > Can someone point me to a one-way-function that is typically used
> >:> > for encryption?
> >:>
> >:> Multiplication.
> >
> >: Of course multiplication is a one-way function, but It's not a very
> >: conveniant one.
> >
> >Multiplication is a one-way function? I'd have thought it was
> >generally eminently reversible.
>
> Well, it's the basis of RSA encryption. I have two numbers p,q
> and (quickly) derive n, their product.
>
> You have n, and you take tremendous amounts of time to derive p and
> q.
>
> A one-way function doesn't mean the function isn't reversible, just
> that it takes much more time to compute in one direction than in
> the other.
How then would you characterize a compsite with more than two factors? It
would appear to be impossible to decide how to allocate the factors into a
multiplcand and multiplier without some other constraint.
This sense of impossibility appears to be absolute when compared to the
problem of decomposing a large binary prime. Theoretical impossibility
(one-way-ness) vs practical impossibility.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEMA, Swiss cipher machine
Date: Mon, 27 Sep 1999 18:51:28 GMT
[EMAIL PROTECTED] (Frode Weierud) wrote, in part:
>The NEMA machine is a mechanical cipher machine based on the Enigma and it
>was manufactured by the Swiss company Zellweger AG. This machine would not
>reveal its key as easily, :-)
And it wasn't made with microchips, but with rotors and wires, so
there was no room to hide anything inside of it. Its operation could
be easily validated.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Mon, 27 Sep 1999 14:46:16 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: simple algorithm for hardware device?
The simplest answer is brute force. Any encryption can be expressed as
a transform function and that transform function can be represented as a
table. A code book. Just use the plain text as the index (memory
address) into the table of code words. For decryption use a second,
inverse table. You'll need a megabit for each table.
It's the fastest possible solution.
There is _no_ encryption algorithm with a fixed key < ~ 1 megabit that
cannot be represented by such a code table. Fill the table by running
97-DES if you want. It's not more secure.
Problem is that a plaintext attack reveals part of the table. This
represents a weakness characteristic of the 16-bit block size. Any
algorithm with that size block will have that problem that an attacker
can easily build up a copy of the code book if they ever have access to
any plaintext.
To defeat plaintext attacks use a technique such as Dynamic Subsitution
to update the code table every time it is used (one slot updated per
access).
If you have the opportunity to supply extra key data you could use a One
Time Pad, but that requires _lots_ of key data, and careful out-of-band
syncronization of key usage.
Luigi Funes wrote:
> Hi all! I wonder if someone can help me!
>
> I'm building a high speed hardware encryption/decryption
> device working on a data stream of 16 bit words.
> Data coming in variable size packets at 40 Mword/sec
> and every word must be encrypted almost immediately, more
> exactly the delay between the input and output of a every
> word must be < 5 nS.
> With this timing requirements and using low-cost FPGAs,
> I belive it's impossible to implement strong algorithms
> doing more than one round. Of course, for this
> application a weak algorithm breakable in few hours by a
> Pentium is good enough. :-)
> I already succesfully tested a prototipe, using a trivial
> algorithm XORing data and a LFSR, but now I have to
> implement something of better.
> Note the algorithm can be kept secret, because it's
> hidden inside the FPGA, but a enemy could steal the
> device, setup any key and encrypt and analyze any data.
> Besides, the enemy knows the plain texts of many
> encrypted data.
> Someone can suggest me an algorithm for this device?
> I'll appreciate any comment too. Thanks!
>
> Luigi
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Electronic envelopes
Date: 27 Sep 1999 19:47:33 GMT
There is a crypto time capsule, as follows: Create an ECC public key of a
certain size without ANYONE knowing the private key, then use the public key to
encrypt the message. To recover the data means breaking the public key to
recover the private key, which is known to take an expected number of
operations. This is not super fine tuned as to time.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: alt.security.pgp,comp.security.pgp
Subject: Re: Increasing password security dramatically without making it harder to
remember
Date: Mon, 27 Sep 1999 15:44:21 GMT
On Mon, 27 Sep 1999 19:39:30 +0100, "Gary" <[EMAIL PROTECTED]> wrote:
>A weak key is hashed and then that hash hashed and so on and so on.
>On the average machine say it took 10 seconds and then the result was used
>as the password.
>Is this analogous to key stretching?
But if the attacker knew what the code was that hashed the key, it would be
useless. It might slightly reduce the number of keys to be tried per second,
but all the attacker would do is input the keys into the hasher before trying
them. And keeping the hashing operation secret isn't going to help, security
through obscurity is the worst way of doing things. No one needs to trust
closed-source crypto because there are so many open-source equivalents out there
to choose from.
A weak key is going to stay a weak key, no matter what you do to it. It is
easier to choose a strong key in the first place. If you need to memorize a
bunch of strong keys for a number of applications, use one stronger key to
protect all the others in something like PasswordSafe or in a ScramDisk File.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Example of a one way function?
Date: 27 Sep 1999 15:47:36 -0400
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>> In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>> >Boris Kolar <[EMAIL PROTECTED]> wrote:
>> >: Roger Carbol <[EMAIL PROTECTED]> wrote in message
>> >:> I. Michael Mandelberg <[EMAIL PROTECTED]> wrote:
>> >
>> >:> > Can someone point me to a one-way-function that is typically used
>> >:> > for encryption?
>> >:>
>> >:> Multiplication.
>> >
>> >: Of course multiplication is a one-way function, but It's not a very
>> >: conveniant one.
>> >
>> >Multiplication is a one-way function? I'd have thought it was
>> >generally eminently reversible.
>>
>> Well, it's the basis of RSA encryption. I have two numbers p,q
>> and (quickly) derive n, their product.
>>
>> You have n, and you take tremendous amounts of time to derive p and
>> q.
>>
>> A one-way function doesn't mean the function isn't reversible, just
>> that it takes much more time to compute in one direction than in
>> the other.
>
>How then would you characterize a compsite with more than two factors?
Um, as "a number with three or more prime factors." Hell, if you
want to play games, I can simply point out that you have no idea how
many ones I multiplied in to get the number sitting in front of you.
I'm not sure what this has to do with the question asked, however.
Mr. Mandelberg asked for a one-way function used in encryption; it
was pointed out that multiplication is used for such a purpose
in RSA encryption.
>This sense of impossibility appears to be absolute when compared to the
>problem of decomposing a large binary prime. Theoretical impossibility
>(one-way-ness) vs practical impossibility.
But on the other hand, this sort of theoretical one-way-ness is almost
never used in encryption, aside from the XOR or equivalent step in the
one-time pad. The standard use of the term "one-way function" -- here
I'll quote Schneier as one of the standard texts (p. 29) -- is a
function that "[is] relatively easy to computer, but *significantly
harder* [Ed: emphasis added] to reverse. That is, given x it is easy to
compute f(x), but given f(x) it is hard to compute x. In this context,
'hard' is defined as something like: It would take millions of years to
compute x from f(x), even if all the computers in the world were assigned
to the problem." It's not necessary that a function be formally irreversible,
merely impractical to reverse -- and multipliation qualifies handily.
-kitten
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: SNAKE: RATTLER
Date: Mon, 27 Sep 1999 20:45:41 +0100
Just in case anyone is interested :-) Ive added the
source and WIN32 binaries of an example of a
SNAKE Key Exchange to the SNAKE web page...
http://www.smdp.freeserve.co.uk/snake.html
It is a simple 'inside out' port redirector which
allows external access to services inside a firewall
which only allows outgoing TCP/IP connections.
It will not function through proxies and only forwards
a single port.
The crypto spec is as follows...
Version: 0.1 (initial alpha), source code provided.
SNAKE: 3 part 512bit, suitable for max shared key size of ~70bits
HASH: RIPEMD-160, suitable for max shared key size of ~80bits
Encryption: 56bit, 16 Round, ECB mode, XTEA, (exportable)
PRNG: Hash of user input + 64bit counter
OS: WIN32, Solaris
Not much in the way of docs, but it does seem to be reasonably
functional.
ttfn
PG. (remove NOSPAM blocker from email to reply direct)
PS Im away for a few days... cya'll soon.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Schrodinger's Cat and *really* good compression
Date: Mon, 27 Sep 1999 18:55:47 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>The issue
>is not whether the experiment could be performed; it could.
Actually, however, the box has to be *very* well-insulated in order
for the cat not to be inadvertently observed. Maintaining the
coherence of such superposed states is extremely difficult.
In fact, since a cat is big enough to have a detectable gravitational
pull, and no insulator for gravity is known - after all, it bends the
fabric of space itself - and so there may be a *fundamental*
impssibility involved; at least this is what Roger Penrose has
suggested.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: simple algorithm for hardware device?
Date: 27 Sep 1999 20:06:37 GMT
In article <7so1v9$hk3$[EMAIL PROTECTED]>,
Luigi Funes <[EMAIL PROTECTED]> wrote:
>Hi all! I wonder if someone can help me!
>
>I'm building a high speed hardware encryption/decryption
>device working on a data stream of 16 bit words.
>Data coming in variable size packets at 40 Mword/sec
>and every word must be encrypted almost immediately, more
>exactly the delay between the input and output of a every
>word must be < 5 nS.
>With this timing requirements and using low-cost FPGAs,
>I belive it's impossible to implement strong algorithms
>doing more than one round. Of course, for this
>application a weak algorithm breakable in few hours by a
>Pentium is good enough. :-)
Take a look at the Pike stream cipher in Applied Cryptography 2nd ed.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Requirement for Uniqueness in Decryption Keys
Date: 27 Sep 1999 16:13:59 -0400
In article <8E4E88373rcarbol@news>, Roger Carbol <[EMAIL PROTECTED]> wrote:
>In section 1.4 of the Handbook of Applied Cryptography
>( http://www.cacr.math.uwaterloo.ca/hac/about/chap1.pdf )
>at about the top of page 13 of Chapter 1, there is the
>statement (rendered here without mathematical symbols:
>
>
>An encryption scheme consists of a set of encryption
>transformations and a corresponding set of decryption
>transformations with the property that for each e there
>is a unique key d such that
>[d decrypts the message that e encrypted.]
>
>
>I don't understand the requirement for d, the decryption
>key, to be unique, although I can clearly see why it
>might be a good idea.
>
>
>Is it, in fact, a rigourous requirement for d to be unique?
>Or may the set of decryption keys be larger than the set
>of encryption keys, in a general sense?
I don't think it's a strict requirement; the Caesar cypher is
still well-defined, even for offsets over 26 letters.
-kitten
------------------------------
From: Richard Hyde <[EMAIL PROTECTED]>
Subject: Meeting BXA req. for online dist?
Date: 27 Sep 1999 19:49:01 GMT
Is there a website somewhere that describes tips and techniques one
can use to meet BXA's requirements for distributing >56 bit software
on line?
The BXA docs are deliberately obscure and an exhaustive search has
so far failed to turn up anything concrete.
Many thanks
Rick
--
Include "wombat" in Subject line of mail sent to me [to override spamgard]
==========================================================================
| Richard Hyde | [EMAIL PROTECTED] | This space intentionally left blank |
==========================================================================
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Electronic envelopes
Date: Mon, 27 Sep 1999 19:29:38 +0200
[Note: Owing to a technical issue, you might receive a duplicated
copy of this post. My apology for your inconvenience.]
I like to know whether it is possible (and how) to realize an
electronic envelope in the following sense: It is not possible by
anyone else than the sender to get the contents of the envelope
before a predetermined time point without that act of manipulation
be known. In other words, one deposits an envelope containing
secrets at a notary who opens it at a certain time point and
announces the contents. The envelope is to be opened exactly at
that time point and not before. No trust on the notary is assumed.
The act of opening should hence prove that it is indeed done at the
prescribed time point. With such a mechanism one could deposit
copies at several notaries at different geographical locations and
the secrets will then be disclosed simultaenously at these places
(within the error tolerance of the radio clock signal transmission,
of course). After deposition of the envelope, no further interaction
between the sender and the notary is assumed to be available.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Bill Lynch <[EMAIL PROTECTED]>
Subject: EFS
Date: Mon, 27 Sep 1999 15:00:40 -0500
Hello,
Does anyone have an info on Microsoft's Encrypted File System (in
Win2000)? I've heard mixed comments about it. My guess is that it will
be the subject of many attacks and I'm sure people will post cracks for
it.
MS has this to say on their website:
Local: Protect data on your computer's hard drive. The Encrypting File
System (EFS), part of the Windows NT File System, encrypts each file
with a randomly generated key. The encryption and decryption processes
are transparent to the user. Even though your work is protected by EFS,
when it's doing its job it doesn't distract you from doing yours.
Is there any other better technical overviews of this product?
regards,
--Bill Lynch
------------------------------
** 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
******************************
