Cryptography-Digest Digest #355, Volume #11 Fri, 17 Mar 00 16:13:01 EST
Contents:
KDC + secret key == public key? (James F. Hranicky)
Re: Quantum crypto flawed agains Mallory? ([EMAIL PROTECTED])
Re: 64-bit Permutations (Paul Rubin)
Re: Cellular automata based public key cryptography (James Felling)
Re: new/old encryption technique (JimD)
Re: The Breaking of Cyber Patrol� 4 (Paul Rubin)
Re: Encryption of fax ("Scott K. Lindsay, P.Eng.")
Re: Maybe public key is more secure (Tim Tyler)
Re: how to introduce hs students to cryptography (Jerry Coffin)
Re: 64-bit Permutations (Tim Tyler)
Re: Encryption of fax (Tony L. Svanstrom)
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference (Mok-Kong Shen)
Re: The Breaking of Cyber Patrol� 4 ("seifried")
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (James F. Hranicky)
Subject: KDC + secret key == public key?
Date: 17 Mar 2000 20:12:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
I was goofing around with the gss-sample program in the stock MIT
Kerberos distribution and noticed that the GSSAPI protocol appears
to have support for some kind of signature. I glanced around the net
and really didn't get a handle on how the GSSAPI does this (seemed
to be a rather non-intuitive protocol), but it got me thinking: could
one use a Kerberos variant to get digital signatures and PK encryption
with a symmetric algorithm?
It dawned on me that if you allow user A to ask the KDC to perform
encryption with B's secret key, you essentially have a PK-like
interface for Kerberos. To send an encrypted message to B, I send
the message and B's address to the KDC, and the KDC can return the
message to me encrypted in B's key. To check B's signature in a
message, I take the hash of a messgage from B and B's encrypted hash,
send them to the KDC, then the KDC would tell me whether it was a good
or bad signature.
Upsides :
a Digital signatures/PK encryption can be performed with symmetric
algorithms -- no need to move to X509 for entities currently
using Kerberos
b No need to haul your X509 cert around everywhere you go in
order to sign/PK encrypt
Downsides:
a Only people in the same Kerberos realm can securely encrypt
and verify messages -- anyone outside the realm would have
use plaintext to communicate with the user's KDC.
b Once I change my password, my old signatures are unverifyable
and old messages unencryptable
c I can run crack on the encrypted message I get back in an
attempt to get B's password
One could simply have the KDC track all old keys to verify old signatures,
but the user would have to remember them all to decrypt old messages.
One could modify the protocol to allow for a more permanent symmmetric
key that is encrypted with a passphrase that is changable -- this fixes
downside b and c (key could be arbitrarily long), but eliminates upside
b as well.
One could even have the passphase and Kerberos passwords synced up, so
that user A could access Kerberos services as normal with his password,
but encrypts and signatures would be performed with the big key after
decryption with the normal Kerberos password to avoid password guessing.
Of course, if someone gets ahold of the encrypted key, crack could be
run on that as well, but this is no different than current PK setups.
On the other hand, since the encrypting and verifying take place on the
KDC, perhaps the big key could just live there, giving you back upside
b and removing downsides b and c. To keep in line with the Kerberos
philosophy, messages would also be sent to the KDC for decrypting and
signing, and returned back to the user, preventing the big key from
ever crossing the network at all, while the channel is still encrypted
with the (preferrably 3des or better) session key. Seems that this would
apply to standard PK protocols as well -- the private key lives on the
secure key server, and all cryptographic processing takes place there.
In _Applied Cryptography_, Schneier mentioned that people had been
stumped trying to figure out a protocol where the e-mail address
functioned as your public key. Given that Kerberos is being modified
to be able to lookup KDC information straight from the domain name in
an address, this may make it somewhat more feasible.
For all I know, this has all been hashed out before. I thought it was
interesting that a symmetric key + a KDC seemed to be equivalent
to a public/private keypair.
Thanks for any comments,
- ----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin UF/CISE Department |
| E314D CSE Building Phone (352) 392-1499 |
| [EMAIL PROTECTED] http://www.cise.ufl.edu/~jfh |
- ----------------------------------------------------------------------
- Encryption: its use by criminals is far less -
- frightening than its banishment by governments -
- Vote for Privacy -
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQB1AwUBONKRf3C4g82aLQ6NAQF6IQMAt/cAhHLbqKuTi768KiUYtNibsMv//uly
dG1ae6vMI82AHOvMp5JWnvOHjaREqefZhBE0XZHnDl+MaahxDuU9IVxCcKpnQWqF
EOrTJ95VCKTJMqir8P1eiyDh5l/QEk+C
=kqv7
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Fri, 17 Mar 2000 20:13:23 GMT
In article <8atni6$nhk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > The quantum cryptography itself doesn't attempt to authenticate the
> > communicators.
> >
> > That's partly why there's normally something like a telephone call as
> part
> > of the protocol - so the participants can authenticate one another.
> >
> > *If* Mallory can /also/ intercept this, *and* fake the voices of each
> > participant well enough for fool the other one, the security's lost.
> > Otherwise, Mallory's attack will usually fail. His manipulation of the
> > particles is *extremely* likely to be detected during the telephone
> call.
>
> Maybe it would be practical to exchange a few bits via quantum by
> sending the polaroid types via telephone (and thus authenticate the
> participants in the communication), but for large files it would be
> absoultely impractical to exchange a one-time pad this way!
> This authentication should be done in a standard computer line, so
> it would not be sufficient to exchange the data securely. I know
> quantum crypto have interesting proprieties, but is it practical and
> secure even assuming the proper technology is developed?
>
> Daniel.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
You might want to read the 5 page paper
"Security Aspects of Practical Quantum
Cryptography" which explains the security
issues involved with qubit- based
cryptography:
http://arXiv.org/abs/quant-ph/9911054
This 4 page paper describes a quantum
authentication protocol:
http://arXiv.org/abs/quant-ph/0001046
Mitra has devised a novel method for ensuring
the "absolute security of classical and
quantum keys":
http://arXiv.org/abs/quant-ph/9912074
Assuming a successful physical realization of
this method then I do not see any obvious
weaknesses in it. Perhaps if someone has the
time they could review this paper for any
significant weaknesses.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: 64-bit Permutations
Date: 17 Mar 2000 20:22:02 GMT
In article <8attod$32h$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>I hope you do realize that the look up table for such a permutation would
>have a size of 137438953472 giga byte.
>
>In a previous article, Stephen Houchen <[EMAIL PROTECTED]> writes:
>>Imagine a cipher where you took plaintext in 64-bit blocks.
>>The bits in each block are simply permuted in the same
>>fashion for each block. The key, then would be the bit-
>>mapping.
>>
>>My gut feeling is that this is so simple that it's probably not
>>very hard to break.
>>
>>So cryptanalysts, how would you break it?
>>
>>S
>>[EMAIL PROTECTED]
You're joking, right?
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Fri, 17 Mar 2000 14:20:02 -0600
> <big snip>
Tim Tyler Wrote:
>
> I don't believe that this follows. A 1D CA can still compute functions
> which a TM can never compute.
>
> The problem with the TM is that it can only do one thing at a time.
>
> A system which operates on a 1D line one step at a time is weaker than one
> that processes an infinite number of operations simultaneously, when
> evaluating some functions with infinite numbers of inputs and outputs.
Assume that each CA cell in the (countable) line is exactly equivalent to a TM.
(This is actually NOT true, as the way A CA is constructed a single cell is less
powerful than a TM.
The reason that the halting problem is insoluble by a single TM is due to the fact
that one can always construct a statement that it cannot evaluate.This evolves out
of Cantor's diagonal argument. You can also do this given any N TM's or even a
countably infinite collection of TM's, thus even a countably infinite number of
TM's will NOT beat the halting problem. the (countable) 1D line is less powerful
than or equal to a countably infiniten number of TM's Thus it CANNOT solve the
halting problem. There will always be some string that it cannot evaluate in
finite time.
>
>
> Yes, a 1D CA can simulate an n-dimensional one - but equating a 1D CA
> to a TM is not a valid step.
You are correct, however, I was not equating it to a 1 dimensional CA, I skiped a
step, and it was confusing.
>
>
> :> :> What about the type of calculation I mentioned? A CA can perform these
> :> :> in a finite time, while a Turing machine cannot ever perform them.
>
> : The CA operating on a countable grid will still be vulnerable to a
> : diagonalization argument, which means that it will NOT be capable
> : of resolving the halting problem in finite time.
>
> I agree here.
>
> : If the grid is uncountable then yes the halting problem will fall.
>
>
> I'm not familiar with any "uncountable grid"s.
Maping such would be truly foul, but the real number line is such, as irrational
numbers exist to fill every point.
>
>
> :> :> If one system can do rapidly something that the other cannot /ever/ do,
> :> :> in what sense are they "equivalent in power"?
>
> : In the case of a countable CM they are exactly equivalent. [...]
>
> This is a flat assertion, not an answer to the question. How can they
> possibly be "exactly equivalent" when one can compute something the
> other cannot?
A (countable) CA cannot do anything that a TM cannot. They are equal in power.
An uncountable CA (Yech! Yech!) -- I don't even want to imagine how one would
construct such a monsrosity -- may be more powerful.
>
>
> Ob cryptography: iterating simple atomic operations /can/ produce strength.
> --
> __________
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
> It's been lovely, but I have to scream now.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: new/old encryption technique
Reply-To: JimD
Date: Fri, 17 Mar 2000 20:23:07 GMT
On Fri, 17 Mar 2000 09:17:05 GMT, Samuel Paik <[EMAIL PROTECTED]> wrote:
>Reuben Sumner wrote:
>> You have rediscovered the one time pad.
>
>...
>
>Can we stop calling synchronous stream ciphers "one time pads" please.
Well, they probably are if the cryptovariables are changed before
they start to repeat.
--
Jim Dunnett.
dynastic at cwcom.net
Exiled in Somerset
Right at the heart of England's BSE Industry.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: The Breaking of Cyber Patrol� 4
Date: 17 Mar 2000 20:23:59 GMT
In article <HUnA4.8402$[EMAIL PROTECTED]>,
seifried <[EMAIL PROTECTED]> wrote:
>ftp://ftp.cryptoarchive.net/pub/cryptoarchive/censorware/CyberPatrol/
>
>cp4break.zip
>cp4break.html
Why don't you put these files on an http server instead of an ftp
server. That way people can download through the many anonymizing
proxy servers on the net, e.g. www.anonymizer.com.
------------------------------
From: "Scott K. Lindsay, P.Eng." <[EMAIL PROTECTED]>
Subject: Re: Encryption of fax
Date: Fri, 17 Mar 2000 15:26:23 -0500
Reply-To: [EMAIL PROTECTED]
This is a multi-part message in MIME format.
==============C6826919E851BDA8F961B3D6
Content-Type: multipart/alternative;
boundary="------------2D43674753F2B4AC04072114"
==============2D43674753F2B4AC04072114
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
My apologies. The signature block is new and I'm not quite used to it yet.
I'll be more careful in future.
skl
< ... stuff deleted >
--
Scott K. Lindsay, P.Eng.
Wireless System Technologies
[EMAIL PROTECTED]
==============2D43674753F2B4AC04072114
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
My apologies. The signature block is new and I'm not quite used to it yet.
<br>I'll be more careful in future.
<br>skl
<p>< ... stuff deleted >
<pre>--
Scott K. Lindsay, P.Eng.
Wireless System Technologies
[EMAIL PROTECTED]</pre>
</body>
</html>
==============2D43674753F2B4AC04072114==
==============C6826919E851BDA8F961B3D6
Content-Type: text/x-vcard; charset=us-ascii;
name="sklindsa.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Scott K. Lindsay, P.Eng.
Content-Disposition: attachment;
filename="sklindsa.vcf"
begin:vcard
n:Lindsay;Scott
tel;fax:416 977 1505
tel;work:416 977 1414
x-mozilla-html:FALSE
org:Wireless System Technologies
adr:;;205 Richmond St. West Suite 601;Toronto;Ontario;M5V 1V3;Canada
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Engineer
x-mozilla-cpt:;-16544
fn:Scott Lindsay
end:vcard
==============C6826919E851BDA8F961B3D6==
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Maybe public key is more secure
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Mar 2000 20:26:45 GMT
[EMAIL PROTECTED] wrote:
:> An active attack certainly can work against quantum cryptography in
:> that fashion. One has to be the 'man in the middle' for both the
:> quantum channel and the conventional channel in which the two parties
:> attempting to construct a common one-time-pad note the times of their
: That would not be a problem. If the security is based on the
: existence of multiple channels, we could make any cryptography
: algorithm more secure by the use of more channels to transmit the
: message.
The second channel is used to provide authentication.
The resulting security is quite different from transmitting a message over
multiple channels with conventional encryption.
: We have also the problem of securing the line. If we need to
: absolutely secure the line for a quantum communication, what's the
: reason of cryptography? If the line is tamper-proof, no one could
: eavesdrop the conversation, so we could send the text in plain format!!
You don't need a secure line. In practice lack of security of the line
could be used to jam it, but that's about all - eavsdropping on its
contents tells you very little.
: If a quantum computer is some day descovered, people would be in a
: great trouble with conventional algorithms!! [...]
I'm under the impression many algorithms will be unaffected, and
that moderate increases in key sizes will result in many public-key
systems becoming usable again. I don't think it's as bad as all that.
: We have the Interlock Protocol that solves a great deal of the
: problem in public key systems. [...]
I don't hear much about this protocol in this forum. It seems to have
great potential when communication between the parties is interactive
and in both directions.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Legalise IT.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: how to introduce hs students to cryptography
Date: Fri, 17 Mar 2000 13:36:58 -0700
In article <8arbl4$141$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > I do know for certain that if you teach lots of number theory to even
> > professional level people after lunch, all but one in the class will
> > sound asleep.
>
> This sounds like an attitude problem. Professionals who have degrees
> in C.S. or other technical field are (or should be) capable of
> learning the material. If they "fall asleep" it is because of bad
> attitudes.
IMO, you're oversimplifying to the point that what you're saying
borders on outright falsehood. I think there ought to be a
mathematical version of Occam's Razor: the explanation that involves
the smallest number of people having abberations is probably the
correct one.
In this case we've got a class of 35 people, and all but one are
having problems. Saying those 34 simply have a bad attitude seems to
me roughly like the proud mother watching the parade and say "Oh
look, everybody's out of step except my Johny." IMO, it's a near
certainty that the problem lies with the teacher, not the students.
Of course, with employees you can look at other things to get a
better indication of where the problem lies. If the class is mostly
full of people who got sent to class to get them out of other
people's way, then 34 people with bad attitudes might be real. OTOH,
if you've got a class full of people who've been top-notch employees
for years and they all suddenly have problems in one place, attitude
of the students should be nearly the LAST thing you suspect as
causing the problem.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 64-bit Permutations
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Mar 2000 20:34:02 GMT
[EMAIL PROTECTED] wrote:
: In a previous article, Stephen Houchen <[EMAIL PROTECTED]> writes:
:>Imagine a cipher where you took plaintext in 64-bit blocks.
:>The bits in each block are simply permuted in the same
:>fashion for each block. The key, then would be the bit-
:>mapping.
: I hope you do realize that the look up table for such a permutation would
: have a size of 137438953472 giga byte.
That's not the quantity of information necessary to specify a 64-bit
permutation.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Immanuel Kant, but Khubla Khan.
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: Re: Encryption of fax
Date: Fri, 17 Mar 2000 21:41:56 +0100
Scott K. Lindsay, P.Eng. <[EMAIL PROTECTED]> wrote:
> --------------2D43674753F2B4AC04072114
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> My apologies. The signature block is new and I'm not quite used to it yet.
> I'll be more careful in future.
Hmmm... next thing to complain about is this mime-thing... :)
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 17 Mar 2000 21:04:52 GMT
Jerry Coffin wrote:
> A strictly conforming program can't produce output that depends on
> anything that's implementation defined, unspecified or undefined.
> In C, anytime you write something to a file, you get results that
> are implementation defined, so a strictly conforming program can't
> write to a file.
No. Implementation-defined behavior means that the implementor
makes a choice from specified alternatives and documents which
choice was made. Normal use of standard I/O facilities does not
invoke implementation-defined behavior. (There *are* several
implementation-defined aspects of I/O, but most programs don't
depend on them.)
> you can isolate the system-specific stuff by itself all right,
> but it ends up as about 90% of the program in most cases.
Funny, it ends up as practically 0% in the code I've been writing
recently, which runs on several different hosted environments,
DSPs, and embedded processors.
> If you need a reasonably modern UI, you usually end up
> with a LOT of non-portable code to implement it.
There are portable solutions to the "every platform has its
own GUI" issue, but if you have a substantial algorithm to
implement, e.g. encryption, it should be developed independently
of the GUI code anyway, for reasons of functional cohesion.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Fri, 17 Mar 2000 22:11:23 +0100
SCOTT19U.ZIP_GUY wrote:
>
> Actually this is quite different than most gambling situations.
> As surely as the government will use the census information to
> cause its citazens troulbe as it did the Japanese Americans
> dumb enough to tell the US they considered them selves of
> Japanese extraction. The AES that the NSA finally allows to be
I remember to have seen documentation photos about that story in
an exhibition. If the authorities could treat citizens of their
own countries 'categorically' like that, there appears indeed to
be scarcely any foundation to assume that machineries like the
Echelon would respect the freedom of privacy of civilians and
commercial firms of foreign countries (whether allied, friendly
or hostile ones) and refrain from intercepting and analysing
their communications.
M. K. Shen
------------------------------
From: "seifried" <[EMAIL PROTECTED]>
Subject: Re: The Breaking of Cyber Patrol� 4
Date: Fri, 17 Mar 2000 21:06:38 GMT
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "seifried" <[EMAIL PROTECTED]> wrote, in part:
>
> >"Microsystems also asked the judge to order the Swedish Internet company
> >where the bypass utility is published to turn over records identifying
> >everyone who visited the Web site or downloaded the program."
>
> Had they asked that of a judge in a Swedish court, promptly erasing
> these records would constitute contempt. Asking a judge in a U.S.
> court to issue such an order, however, is something of a waste of
> time. Although Sweden is a signatory to international copyright law
> treaties, the world we live in isn't quite _that_ borderless just yet.
>
> John Savard (jsavard<at>ecn<dot>ab<dot>ca)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
Speaking of which I disabled ftp logging on both servers and fragged all the
old logs. Step #2 is to setup an SSL wrapped FTP or possibly ssh rsync, does
anyone have any comments on this?
It reminds me of that database comment someone posted. I would _love_ to run
a service that distributes information, and when asked to provide logs/etc
simply say "sorry, I can't do that, they don't exist, and even if you wanted
me to I couldn't".
--
Kurt Seifried - Senior Analyst
[EMAIL PROTECTED]
http://www.securityportal.com/
http://www.cryptoarchive.net/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Fri, 17 Mar 2000 21:09:41 GMT
Mok-Kong Shen wrote:
> SCOTT19U.ZIP_GUY wrote:
> > cause its citazens troulbe as it did the Japanese Americans
> ... If the authorities could treat citizens of their
> own countries 'categorically' like that, there appears indeed to
> be scarcely any foundation to assume that machineries like the
> Echelon would respect the freedom of privacy of civilians and
> commercial firms of foreign countries (whether allied, friendly
> or hostile ones) and refrain from intercepting and analysing
> their communications.
Different time, different culture, different circumstances,
different individuals, different legal environment,
different government. Your conclusion doesn't follow.
------------------------------
** 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
******************************
