Cryptography-Digest Digest #274, Volume #11 Tue, 7 Mar 00 21:13:01 EST
Contents:
Re: Possibly dumb question about re-encrypting a data stream (Paul Koning)
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: An RC5-like cipher (Paul Rubin)
I have a training application for information security that was ("Markku J.
Saarelainen")
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: An RC5-like cipher (Scott Contini)
Re: PC risks analysis? ("Joseph Ashwood")
Re: are self-shredding files possible? (John Underwood)
Re: Possibly dumb question about re-encrypting a data stream (Bill Unruh)
Actually, the discussion of the GSM encryption is nothing new, I drove ("Markku J.
Saarelainen")
Free-MAC mode (Adam Back)
Re: An RC5-like cipher (Carl Byington)
Re: Want to poke holes in this protocol? (Edward A. Falk)
Re: Excel password remover (Steve K)
Protocol question -- detecting patching of software (Edward A. Falk)
----------------------------------------------------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Possibly dumb question about re-encrypting a data stream
Date: Tue, 07 Mar 2000 16:53:58 -0500
[EMAIL PROTECTED] wrote:
>
> Hello,
>
> This might be a dumb question, I just don't know. All I know is that
> I'm suspicious of everything.
>
> Consider the following scenario:
>
> 1) Alice encrypts a message and sends it to Bob.
>
> 2) Bob decrypts it and re-encrypts it with another key. He sends it
> to Carl.
>
> 3) Interloper Eve receives both messages and wants to know what was
> said, and/or anything about the key.
>
> A stream cipher is used with XOR being the operator.
>
> Can Eve gain anything knowing that the same plaintext was used in both
> cases?
>
> I know this is a problem if Alice is hostile and wants to know Bob's
> key. But if Alice and Bob trust each other, is there a problem with
> this scheme? I also know that this scheme is suceptible to replay
> attacks - let's just say I've got that covered already.
With world war 2 vintage ciphers, this would have been a fatal
error and a major violation of the rules for correct secure
communication procedures. With modern ciphers, this should be
perfectly ok; the attacker has less to work with than a chosen
plaintext attack or chosen ciphertext attack, either of which
a good modern cipher will resist.
paul
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Tue, 07 Mar 2000 22:41:57 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] wrote:
> >
> > >
> > >Dr. Wang is exactly correct. However, it is possible to define a
> > universal cellular automata (CA) such that given the code of a CA "B"
> > and input "x" it can simulate the behavior of "B" on input "x". Both
> > this universal CA and a turing machine (TM) cab be proven equivalent
> > (i.e. of the same power) via Roger's isomorphism theorem. To see how
> > this is done go to http://alife.santafe.edu and then, if I remember
> > correctly, to "CA" then "topics" then "faq" then "properties" then
> > "computability".
>
> From the big difference in power, it seems that the universal
> cellular automata is quite different from the ordinary cellular
> automata, right? Could you please give a few salient features of
> the universal one, just for having some rough ideas? Thanks.
>
> M. K. Shen
>
If "ordinary" CA are given an appropriate
initial configuration then they can simulate a
universal Turing Machine (TM) and thus
perform general computation. The key feature
of the universal CA above is its mentioned
ability to "interpret" a CA. By expanding this
idea and combining it with a total recursive
function it was shown to be an acceptable
programming system of the same type as TM.
This is what is described in the "properties"
section of the FAQ link above.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: An RC5-like cipher
Date: 7 Mar 2000 23:01:19 GMT
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
>Here is a cipher that is a like RC5, but can be implemented with fewer
>instructions that RC5 for block sizes greater than 16 bits, on the
>Atmel AVR architecture. I do not have a clue to the security of this
>cipher, although I believe that n rounds of this cipher is at least
>as strong as n-2 round RC5.
I'd thought of something like this too, but with 64-bit blocks and 12
"rounds" (an RC5 round is like two of what most other ciphers call a
round), it needs 50 bytes of key-dependent S-box data, which is more
than the available amount of RAM in the system under discussion.
If that much RAM is available, it might also be possible to code
CAST in 50 bytes, again using a precomputed key schedule.
[To Carl]: I'm not familiar with the AVR product line, but maybe
there's a part with more program ROM that doesn't cost too much more
and you might want to look into switching. You'll probably need
something like that sooner or later anyway.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.soviet,soc.culture.israel,soc.culture.nordic,alt.2600,alt.security
Subject: I have a training application for information security that was
Date: Tue, 07 Mar 2000 23:22:53 GMT
I have a training application for information security that was
developed by the NSA for the U.S. government. I have taken this training
and any tests many times by myself without anybody really ever knowing.
I could share few experiences and this application. I think that I got
it in 1994 or so. It is quite good and I have implemented it in my
business arrangements. It is actually about 3MB in its size.
Yours,
Markku
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Tue, 07 Mar 2000 23:18:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> : [A side question- Earlier, was the Garden of Eden problem (deriving the
> : starting pattern from an n-th iteration) the main obstacle to
> : implementing CA based cryptosystems, especially given the fact that some
> : CAs don't have a single inverse because of multiple inputs going into
> : the same output?]
>
> This is not a problem:
>
> Reversibility in CA has been fairly well studied by now. The
> Garden-of-Eden "problem" is simply not a problem any more.
>
By "earlier" I meant historically, i.e. initially.
In this thread, Trevor Jackson mentioned the
weaknesses of Wolfram's cryptographic
approach and I conjectured to myself that the
Garden of Eden problem might have been the
greatest such weakness. Your reply was
interesting, however, because it illustrated to
me the variety of solutions to reversibility in
CA.
A side note- I mentioned David Cary's belief
that architectures built from arrays of
identical cells would be close to the optimum
architecture for nanocomputers. Though, at
the quantum scale, it seems to me that a
combination of CA and gate array architecture
might be more optimal. I have heard of
quantum CA and finite automata with quantum
and classical states but I am unfamiliar with
these and do not know if they would be more
effective for computation or cryptography.
Earlier, I examined CA for their artificial life
potential but did not consider their role in
cryptography until recently.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: An RC5-like cipher
Date: 7 Mar 2000 23:34:14 GMT
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
>Here is a cipher that is a like RC5, but can be implemented with fewer
>instructions that RC5 for block sizes greater than 16 bits, on the
>Atmel AVR architecture. I do not have a clue to the security of this
>cipher, although I believe that n rounds of this cipher is at least
>as strong as n-2 round RC5.
>
>RC5 encryption is as follows:
>
> A = A + S[0];
> B = B + S[1];
> for (i = 2; i <= 2*R+1; i++)
> {
> A = A ^ B;
> A = ROTL(A, B); /* Rotate A left by B bits */
> A = A + S[i];
> SWAP(A, B); /* Swap contents of A and B */
> }
>
>Eliminate whitening step and reorder operations.
>
> for (i = 0; i <= 2*R+1; i++)
> {
> B = B + S[i];
> A = A ^ B;
> A = ROTL(A, B);
> SWAP(A, B);
> }
>
I question whether you really want to leave out the pre-whitening.
I haven't read the most recent attacks on RC5, but I would suspect
that leaving out this pre-whitening will allow differential attacks
to extend a few more rounds. Therefore, my comments in the next
paragraph assume you put the prewhitening back in (well, at least
putting A = A + S[0] back in).
I don't see how you can implement this in fewer instructions.
You variant of RC5 has the same round structure as the original,
except that you are pushing the A = A + S[i]; into the beginning
of the next round. In other words, your cipher is doing more or
less the same as RC5 if you look at it the right way. Here is
how it looks graphically:
RC5 ROUND: "NEW" CIPHER ROUND:
A B A B
| | | |
XOR<-----+ | +S_i
| | | |
ROTL<-----+ XOR<-----+
| | | |
+S_i | ROTL<----+
| | | |
\ / \ /
\ / \ /
\ / \ /
X X
/ \ / \
/ \ / \
/ \ / \
| | | |
Imagine several of these rounds linked together. Take the +S_i from
the RC5 rounds and move it down into the beginning of the next rounds,
and you get exactly your "new" variant of RC5.
Scott
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: PC risks analysis?
Date: Tue, 7 Mar 2000 15:32:07 -0000
Many of us here are capable of doing such for you. But
defining a standard for it, which is basically what you
asked for, would be effectively impossible. Any reasonable
examination of security needs to take into account your
needs. If you require an environment that can be certified
for use by the US government for the highest risk
information, your needs will certainly differ from the
requirements of your average office building, where at worst
you have to contend with a determined company. If you want,
there are many of us that would gladly accept the
opportunity.
Joe
"Mykhailo Lyubich" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]...
> Hi there
>
> does somebody know an official source (report, standard)
> with "how vulnerable be a PC environment"?
> I look for risk analysis survey or research report
> for software encryption and password based data storing
> on user's workstation.
>
> I appreciate your help.
>
> Mykhailo Lyubich
>
>
>
------------------------------
From: John Underwood <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Tue, 7 Mar 2000 22:21:53 +0000
On Tue, 7 Mar 2000 at 12:27:51, Vernon Schryver
<[EMAIL PROTECTED]> wrote in comp.security.pgp.discuss:
(Reference: <8a3l7n$lsu$[EMAIL PROTECTED]>)
>Why can't they answer "we're sorry, your honors, but we don't have that
>key anymore"?
One gets the impression that, under the proposed "freedom of information
according to Jack Straw" Act, that would constitute a clear admission of
guilt since the only defence is to prove you never knew the key.
--
John Underwood
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Possibly dumb question about re-encrypting a data stream
Date: 7 Mar 2000 23:58:23 GMT
In <uEdx4.367$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Consider the following scenario:
>1) Alice encrypts a message and sends it to Bob.
>2) Bob decrypts it and re-encrypts it with another key. He sends it
> to Carl.
>3) Interloper Eve receives both messages and wants to know what was
> said, and/or anything about the key.
>A stream cipher is used with XOR being the operator.
>Can Eve gain anything knowing that the same plaintext was used in both
>cases?
She can gain a knowlege of Alice's stream being encrypted by Bob (xor
the two steams together). For a true OTP of course this gives zero
information about either. For a pseudo OTP, it might leak into (eg BOB
always uses the same stream Alice does) but that does not give much info
about the message. Of course patterns in this stream might give hints
about breaking the original stream cypher.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.security,alt.2600
Subject: Actually, the discussion of the GSM encryption is nothing new, I drove
Date: Wed, 08 Mar 2000 00:53:43 GMT
Actually, the discussion of the GSM encryption is nothing new, I drove
two SW specialists working for Nokia to a disco in Finland in 1991 and
we discussed details how the GMS encryption can be broken in few minutes
or less by professionals .. this was the summer in 1991 ... I think
that I also made few remarks how certain multinational enterprises may
easily penetrate to other companies and businesses ...
Yours,
Markku
------------------------------
From: Adam Back <[EMAIL PROTECTED]>
Subject: Free-MAC mode
Date: Tue, 07 Mar 2000 19:55:09 -0500
Following on from the discussion of block modes which try to exhibit error
propagation to give a MAC or MDC combined with a block mode in the thread
with subject "avoid man-in-the-middle known plaintext attack using a stream
cipher", here's a block mode Anton and I have been working on.
encryption is:
y_i = E_k( x_i + y_{i-1} ) + x_{i-1}
and decryption is:
x_i = D( y_i + x_{i-1} ) + y_{i-1}
In practice to make a MAC out of this you would append a fixed block to the
message and verify that this fixed block was preserved on decryption. This
block could be public, or perhaps could be the IV, or a separate key.
We are working on a paper describing the Free-MAC mode, and output feedback
as a way to get error propagation on the decryption operation of a block
mode.
The result is likely to be essentially as efficient as CBC encryption, and
doesn't suffer the block swapping attacks that Propagating-CBC,
Plaintext-CBC, iaPCBC and CBCC do.
Adam
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: An RC5-like cipher
Date: 8 Mar 2000 00:57:52 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <8a41nv$3hp$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[snip interesting discussion of rc5 variant]
>[To Carl]: I'm not familiar with the AVR product line, but maybe
>there's a part with more program ROM that doesn't cost too much more
>and you might want to look into switching. You'll probably need
>something like that sooner or later anyway.
We are already using the largest variant they make.
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCVAgUBOMWljNZjPoeWO7BhAQH3LQP/awT/jrORdDtPoApQq276l1iWaWCa9Gnl
DG2SI6CY01uqjpuuhkv+UPDvRbnmo8LPKF/Gshq2xm2EbM2Y1x4z7dfZHsqgbHXF
2ARxdice9xWyJmsjlAVBjLYVOPiqqIEqbXbSkcmdUWJPQda3ktpSAzJJugnkGLMJ
v5bno6nuvR8=
=2se8
=====END PGP SIGNATURE=====
------------------------------
Subject: Re: Want to poke holes in this protocol?
From: [EMAIL PROTECTED] (Edward A. Falk)
Date: 08 Mar 2000 01:41:53 GMT
In article <89hkp6$1t4$[EMAIL PROTECTED]>,
Xcott Craver <[EMAIL PROTECTED]> wrote:
>Johan Hoogenboezem <[EMAIL PROTECTED]> wrote:
>>Hi Everyone,
>>
>>Would some of you please help me to poke holes in this scenario?
>
> [protocol]
>
> Yikes!!!
>
> The first attack that comes to mind: an attacker spies on Alice's
> transmission, records the whole thing, and then "plays it back" later,
> pretending to be Alice. Whatever Alice did during that session is performed
> a second time. If Alice made a transfer of funds to Carl, Carl could
> reperform the transfer 100 times, take the money and run.
Good point. When I read the protocol, my first thought was that
the authentication should be done via challenge-response, rather
than traditional password. Now I know why.
> In fact, with the right analysis of the traffic, Carl could isolate
> specific commands. If the symmetric crypto uses chaining throughout
> the entire session, however, this is avoided too.
Does anybody *not* use chaining for serious work?
> Lemme think about it some more; I'll tell you if I see anything
> really dangerous.
I felt a little funny about the generation of the random session
key at Alice's computer. I'd feel a little better if the bank
threw in some randomness too. Why not D-H key exchange?
--
-ed falk, [EMAIL PROTECTED] See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
and read 12 Simple Things You Can Do ******!***************************#**
to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Excel password remover
Date: Wed, 08 Mar 2000 01:53:22 GMT
On Tue, 7 Mar 2000 17:58:19 +0100, "Tobiass Mai" <[EMAIL PROTECTED]>
wrote:
>Thanks for your answer!
>
>Regards
>Tobiass
Let me reinforce the view that the Excel format is "open" in the sense
that software is allowed to read & write it: Star Office, originally
made by Star Division in Germany, was sold a few months ago to Sun
Microsystems. Star Office will open, edit, and even create
Excel-formatted files. Actually, your excel password cracker is a
missing functionality in Star Office, for complete inter-operation, as
Star Office can not presently open password protected Excel files.
So far, no one has complained about Star Office. And BTW, it's very
similar to Microsoft Office, inter-operates freely with Word and Excel
files, runs on both Windows andthe Unix clones, and comes with
advanced graphics functions. It's free for both personal AND business
use.
See http://www.sun.com/staroffice/ .
Time to kick the security "issues" that come attached to MS Office off
our Windows boxes? I think so...
:o)
Steve
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
Subject: Protocol question -- detecting patching of software
From: [EMAIL PROTECTED] (Edward A. Falk)
Date: 08 Mar 2000 01:57:24 GMT
Hi all; here's a puzzler that's been nagging me for a few days:
You have a multi-player game, where the players run a copy of
the game on their own computer, and play over the net, connected
to a server.
It's possible to cheat by patching your copy of the game.
Is it possible to design a protocol by which the server could
challenge the user's software to ensure that it hasn't been
modified?
I know someone who did this many years ago by having the software
execute a checksum on itself and verify the results. Theoretically,
any tampering with the program would ruin the checksum and bust
the tamperer. Of course, the tamperer could also patch the checksum
routine. My friend worked around this problem by having eight
different checksum routines in different parts of the program.
The idea was that the tamperer wouldn't find all eight checksums
and would miss at least one, thus getting busted. This is
security-through-obscurity, however -- not a real solution.
I'm trying to decide if there's a better way to do this. What I've
got so far is this:
* Program code contains a cryptographically secure checksum algorithm.
* Server issues a challenge that says: Here is an initialization
vector. Compute your checksum and send the result back to me.
This doesn't work either though, as the tampered program merely
keeps an untampered copy around and computes the checksum on that.
Obviously, the checksum will have to include some sort of dynamic
but known-to-the-server state. If the program is a game, the
checksum could be computed based on the initialization vector, the
program code, and the current game state. This still has holes in
it though.
Any thoughts on this?
--
-ed falk, [EMAIL PROTECTED] See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
and read 12 Simple Things You Can Do ******!***************************#**
to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
** 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
******************************
