Cryptography-Digest Digest #871, Volume #12 Sun, 8 Oct 00 09:13:01 EDT
Contents:
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (pgp651)
Re: Some thoretical questions... (Tim Tyler)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?/7 (pgp651)
Unauthorized access to your opponent's PC! ([EMAIL PROTECTED])
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
FTL Computation (ca314159)
Re: Apologies for a faulty memory (Mok-Kong Shen)
Re: Deadline for AES... (Mok-Kong Shen)
Re: Pencil and paper cipher. (Roger Gammans)
----------------------------------------------------------------------------
Date: 8 Oct 2000 10:01:11 -0000
From: pgp651 <Use-Author-Supplied-Address-Header@[127.1]>
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Crossposted-To: alt.security.pgp,alt.security.scramdisk
=====BEGIN PGP SIGNED MESSAGE=====
Thank. Very good work !=20
On 7 Oct 2000, [EMAIL PROTECTED] (Rich Wales) wrote:
>I tried posting something on this topic yesterday, but it didn't show
>up on Deja.com. I suspect a large block of armored PGP text in my
>posting may have tripped a "no binaries" filter, so I'm going to try
>again (for the record).
>
>"pgp651" wrote:
>
> > We should have now OFFICIALLY this option from NAI in PGP,
> > in PGP v262
>
>As I noted a few days ago, it is probably futile to expect NAI to
>offer =3Dany=3D changes to PGP 2.6.2 (an old version which predates both
>PGP Inc. and NAI's acquisition of PGP Inc.).
>
>However, I agree with the concept that a widely respected descendant
>of 2.6.2 with support for larger RSA keys (for those who wish to use
>them) ought to become available.
>
>To that end, I'm offering (below) my own patch to PGP 2.6.3ia (the
>"international" version which has been on www.pgpi.org since 1996).
>This patch is simple enough that, if you trust 2.6.3ia, presumably
>you'll also trust the result of the patch.
>
>I've also uploaded this patch, as well as a gzip'ed, signed copy of
>the patch, to my Web site; you can find them at:
>
>http://www.webcom.com/richw/pgp/263i-4k-patch (plain text)
>http://www.webcom.com/richw/pgp/263i-4k-patch-gz.asc (gzip/signed)
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
>The following patches will allow PGP 2.6.3ia to generate and process
>RSA keys up to 4,096 bits in length.
>
>The old warning about PGP 2.6.3ia not being for use in the USA has
>also been removed, now that the RSA patent has expired.
>
>These changes are effective ONLY if the source is NOT compiled with
>the "-DUSA" option.
>
>I believe these patches are bug-free, but I accept no liability; use
>the patched version at your own risk.
>
>The PGP 2.6.3ia source can be found on www.pgpi.org (the "International
>PGP" site run by St=E5le Schumacher in Norway). It's called "2.6.3i"
>on this site, but it includes a set of bug fixes from March 1996 which
>are described at: http://www.pgpi.org/files/pgp263ia-patch.shtml
>
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sun Oct 8 10:01:10 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOeBF505NDhYLYPHNAQHHIgf/XlwexiDZGgVbi4vEEDKXhL3SlP+iklSH
B6tNoxiH7gVYxqO8ndOP30vZytg59T7qyPFD0Z8FHiFLXxbpQo8N2fr2LPYrQPuC
dSvSPARct3QDuCpHCTFGS/livgbG29ZSEix4Nvsdah8W9uj9ODU4D76IKF8zBMbw
j0KGkEQ9t602BiqTxzKTTumdyqM7Bv7dWPhzVki+mSXpuoJF1xsOX45ysKc/VSb9
jxqh3eeKrbWoFVyTxHIPuPEz2LfZJw7kBgIBx29wBTBAehkbsdale9Af3lerxQAG
HxF4kby0w4pcrGAkajHfHbyPmMgCivo01axDuscecioMRquQZpvWzw==
=Se2+
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Some thoretical questions...
Reply-To: [EMAIL PROTECTED]
Date: Sun, 8 Oct 2000 08:32:37 GMT
Nikica Guscic <[EMAIL PROTECTED]> wrote:
: How good security do multiple processes applied on an cleartext give?
: For example: DES, Steganography, DES.
Using multiple processes ususally make an attacker's job harder.
If applying steganography, it normally makes sense to apply it last.
It's probably better for an attacker to not realize a message is there,
rather than to decrypt once and think he has the right message when he
does not.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
Date: 8 Oct 2000 11:40:22 -0000
From: pgp651 <Use-Author-Address-Header@[127.1]>
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?/7
Crossposted-To: alt.security.pgp,alt.security.scramdisk
=====BEGIN PGP SIGNED MESSAGE=====
Thank. Very good work !=20
On 7 Oct 2000, [EMAIL PROTECTED] (Rich Wales) wrote:
>I tried posting something on this topic yesterday, but it didn't show
>up on Deja.com. I suspect a large block of armored PGP text in my
>posting may have tripped a "no binaries" filter, so I'm going to try
>again (for the record).
>
>"pgp651" wrote:
>
> > We should have now OFFICIALLY this option from NAI in PGP,
> > in PGP v262
>
>As I noted a few days ago, it is probably futile to expect NAI to
>offer =3Dany=3D changes to PGP 2.6.2 (an old version which predates both
>PGP Inc. and NAI's acquisition of PGP Inc.).
>
>However, I agree with the concept that a widely respected descendant
>of 2.6.2 with support for larger RSA keys (for those who wish to use
>them) ought to become available.
>
>To that end, I'm offering (below) my own patch to PGP 2.6.3ia (the
>"international" version which has been on www.pgpi.org since 1996).
>This patch is simple enough that, if you trust 2.6.3ia, presumably
>you'll also trust the result of the patch.
>
>I've also uploaded this patch, as well as a gzip'ed, signed copy of
>the patch, to my Web site; you can find them at:
>
>http://www.webcom.com/richw/pgp/263i-4k-patch (plain text)
>http://www.webcom.com/richw/pgp/263i-4k-patch-gz.asc (gzip/signed)
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
>The following patches will allow PGP 2.6.3ia to generate and process
>RSA keys up to 4,096 bits in length.
>
>The old warning about PGP 2.6.3ia not being for use in the USA has
>also been removed, now that the RSA patent has expired.
>
>These changes are effective ONLY if the source is NOT compiled with
>the "-DUSA" option.
>
>I believe these patches are bug-free, but I accept no liability; use
>the patched version at your own risk.
>
>The PGP 2.6.3ia source can be found on www.pgpi.org (the "International
>PGP" site run by St=E5le Schumacher in Norway). It's called "2.6.3i"
>on this site, but it includes a set of bug fixes from March 1996 which
>are described at: http://www.pgpi.org/files/pgp263ia-patch.shtml
>
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sun Oct 8 11:40:16 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOeBdJU5NDhYLYPHNAQFbOwf/Wn49AwGyu+65NO1AHehOe80hOqRgVxjk
efrRb8K9Rb1D5jUSYNbTNtppkQUh+eLBSgl0lBzhIenfkJJ/7ByUB7vV+ndfxyTU
0tJrAv9AWUaAqaDNaBZG1OfSwuEDtYhN7KpOYXWgjaaMCJWHyrsHDNEBg/zrWxc1
sdljaYtQUUpWhycTAbT49ayIzUOQ5PHV+HJ47M0IAkXQlXg/PQyjounL//28cI08
Ph3S8DryzL3n3S2m5yyMFKPG9dx3NVy4ot36DVyvHPFBDVzcuHdQDA/q9BDhyrQe
td24gwxhjttLjZFYZft4+761/4QWbvZagGJ41hRx1Jbft5bpU+GPgA==
=KqNj
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Unauthorized access to your opponent's PC!
Date: Sun, 08 Oct 2000 11:48:09 GMT
Unauthorized access to your opponent's PC!
Get files.
Control mail.
Delete data.
Full anonymity.
Low price.
HeCaxap.
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Sun, 08 Oct 2000 14:33:07 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >
> > Bryan Olson wrote:
>
> > > Seem to claim? Give some useful information? I posted
> > > it. It's been right there in front of you.
> >
> > Why can't you say clearly with one short sentence here
> > whether my scheme is difficult to handle or easier to
> > handle than the normal case where the block cipher is
> > used without permutations? If may be that I am, for
> > whatever reason (good or bad), not aware of what you
> > have already said. But what I am requesting is only one
> > short sentence, and should cause you less effort than
> > the two lines above, I firmly believe. Why didn't you
> > do that? But I think I can tell the reason why you have
> > constantly avoided to give the answer through diverse
> > maneuvres: Because on the one side (understandbly) you
> > dislike to admit that it takes more work to crack my
> > scheme than the normal scheme.
>
> But I did crack your scheme, in as much as this kind of
> general idea can be cracked. That's what's been right in
> front of you.
Is I repeated said, it is the matter of amount of work.
You can 'crack' ANY cipher with 'enough' amount of work,
e.g. with brute force, don't you??
It is surprising that you continue to avoid to give a
direct (and simple) answer to my question that I
repeatedly requested, which is the comparison of the
'amount of work' to crack between my scheme and the
normal scheme.
> > But on the other side
> > you also can't claim the opposite, because that's
> > impossible, as can be simply explained from 'first
> > principle', i.e. from a very general point of view. For
> > the block cipher, when used in the normal way, has a
> > certain measure of strength against any given attack,
> > including the one that you invent. Now you need, as you
> > wrote previously, to have a certain large number of
> > blocks to be processed together in order to realize your
> > method. This is a 'constraint', while in the original
> > case, i.e. without permutation, you are free and don't
> > have that constraint (you can deal with one single block
> > or any number of blocks you like). It is well-known from
> > solution of optimization problems that one gets a less
> > favourable optimum when there are constraints. Thus the
> > work of the analyst with my scheme must be higher (and
> > can never be lower) than in the case with the original
> > block cipher (without permutation).
>
> Wrong. First, the number of blocks is not a constraint
> imposed by the scheme; it's the value the attacker
> chooses (there may be better attacks). Second and more
> important, the optimization theory result is irrelevant.
> It says that if one set of constraints is a superset of
> another, the superset will never have a better solution.
> Here we're talking about two different systems, neither
> is strictly more restrictive than the other.
I never opposed to your choice of the number of blocks.
So you are free to choose it. As I said, the state of
the PRNG at both sides will disagree as a result of your
attack and that leads immediatedly to detection (before
you manage to get sufficient material).
If you put in the identy, then my scheme reduces to the
normal one. Hence the superset situation. I suspect
that you probably even not have properly understood my
origianl scheme, if you are unable see this point.
> > One can look into
> > the matter in another way: Suppose the total effort to
> > crack my scheme is less than cracking the original
> > scheme. That would mean that my scheme combined with
> > your method constitute a new and better method of
> > attacking the orginal cipher!
>
> False. As I already explained, your scheme does not
> use the original block cipher as a unit. It lets out
> intermediate state.
See above and below.
>
> > (For, if I use in my
> > scheme always the identity permutation, then the scheme
> > degenerates to the case of using the block cipher in
> > the common way.) Do you think that that could ever be
> > true?
>
> Always using the identity permutation would contradict the
> specification of your scheme. The pseudo-random permutation
> you specify is the defect that enables the attack.
This is 'only' arranged to show the falsity of your
logic. If you scheme were better, it should also be
shown to be better for this special case. And it doesn't.
So the matter is clear, isn't it? (In fact I use here
a 'defective' PRNG, i.e. one that delivers the identity
permutation, to demonstrate the 'defects' of your
arguments.)
>
> > > > Having said the above,
> > > > why do you think it is not well-formed? Could you
> > > > elaborate that? I want to know whether there is
> > > > reduction or enhancement of strength. Is this issue
> > > > not well-formed? Where?
> > >
> > > See my rhetorical question on breaking an unspecified
> > > cipher.
> >
> > Well-formedness is a syntactic issue, not semantic or
> > otherwise. So which part of my question is not
> > well-formed?
>
> Well-formed has a special meaning in formal languages;
> here it simply means how you formed the question. See
> below.
>
> > You claimed that nothing in my writing is science. Now
> > you have previously attempted to work out something to
> > deal with my scheme. Since my scheme is, according to
> > your opinion, not science, isn't it clear that your work
> > was consequently also not science?
>
> No, of course not. The attack is a real result. Am I
> absolutely certain that I didn't overlook something
> important that would invalidate it? Of course not, but
> results are reproducible so check it out.
>
> [...]
> > As I argued above, the attack in any case causes more work
> > than in the case without permutation. 'Exposing the key'
> > means a crack or a part of it, of course. But see below.
>
> The argument was nonsense. What was that - proof by vague
> analogy to another field?
See above with the identity permutation.
>
> > > I've learned not to make your questions the center of my
> > > efforts. I posted proofs in
> > > http://x56.deja.com/[ST_rn=ps]/getdoc.xp?AN=636649064
> > > that you yourself requested in
> > > http://x56.deja.com/[ST_rn=ps]/getdoc.xp?AN=636497466
> > > You then incorrectly brushed it off as having some bug. Had
> > > you worked to understand the material, you would not have been
> > > mislead by what you thought was a counter-example. I can tell
> > > you that getting the proof to the point that it did not have
> > > that "bug" took me a while.
> >
> > I never claimed bugs. If you spend 'enough' resource to
> > attack with your method, then I suppose that it should
> > function. However, it is the AMOUNT of the work of doing
> > your attack that matters.
>
> The attack is efficient - check it out. I already estimated
> it should run within five minutes. Of course the end-game
> depends on the block cipher which is unspecified, but the
> attack isolates the last round or two, so most should then
> fall quickly.
So you can implement it e.g. with DES and check it
out. Given the fact that the communication partners are
using a certain block cipher in the normal way with a
certain key. Now design the set of messages that you'll
need to crack my scheme. Since you don't know the serect
seed, you have no idea of what the permutations are. It
means that, since you claim that your method works, the
set of messages must be able to crack in the special
case where the PRNG delivers the identity permutation.
But this special case means that you have before you
exactly the original scheme. So you can crack DES within
five minutes. What a world sensation that would have been!!
>
> > I was thus posing the question
> > of whether permutation diminishes or enhances the security.
> > This was in a formulation that I believed to sound better.
>
> Your formulation is nonsense. We do not know for certain
> what the best attacks on the popular Feistel ciphers are,
> and your scheme does not specify a particular cipher. Your
> scheme is a general idea and therefore under-specified for
> specific attack. We do not know what are the best attacks
> on various specific formulations of your scheme.
>
> What I can say is that the general idea of your scheme is
> terrible. The attack that efficiently breaks it is based on
> entirely reasonable parameters where your scheme does not
> name a particular choice. I can identify a lesson from the
> attack: do not expose intermediate state from the encryption
> or decryption process.
What do you mean 'particular choice'? Choice of the
cipher, choice of the PRNG? A general scheme can be
specialized. Do you think that I need to list all the
block ciphers or what? If your method of attack is
general, it should also not depend on the particular
cipher or PRNG. What is your point here?
>
> [...]
> > What do you mean by two simultaneous streams? There is
> > one sender and one receiver. Normally there is only one
> > channel. Messages are send sequentially in it. If there
> > are more than one channel, why can't we deal with these
> > independently? There will then be one PRNG for each channel
> > and the PRNGs may even be different. Of course, the seeds
> > will also be different. There can be no interference
> > between the channels at all. (The transmission protocol
> > separates these.)
>
> You seemed to propose this as alternative to a block
> cipher and conventional chaining mode. A secret key has a
> value, but is otherwise stateless. We can back keys up,
> encrypt multiple streams, and decrypt stored text without
> knowing a state particular to the time of encryption. Users
> do all of those things and are not likely to re-engineer
> their systems around the shortcomings of a scheme that
> cannot.
To use old key is always a bad idea in my opinion. Even
if you do back up, then it means that the last use of
the key is no longer valid and the back up key functions
as if it were a new key. If you do this, I'll suggest
that the PRNG seed be changed. Since, as I aruged above,
use of PRNG can only strength, never weaken, the security,
using the same seed once again doesn't cause weakness,
only leading possibly to no gain. If you do use the same
key and seed parallelly for two message streams at the
same time point, you are having two channels and should
properly use two different secret seeds to initiate these.
The messages from the channels are easily rendered
distinguishable by the transmission protocol. I don't
see the problem you have. (If I write two series of
letters to someone, I can number each with numbers
from 1 upwards, but I can use a charater A or B to
distinguish between the two series to avoid mixing-up,
don't I?) User acceptance, which may be dependent on
marketing, is an issue that we shouldn't discuss here,
or at least not before the security issue is debated to
the end.
M. K. Shen
===============================
Was sich ueberhaupt sagen laesst, | Whatever can be said
laesst sich klar sagen; | can be clearly said;
und wovon man nicht reden kann, | and silence must be kept
darueber muss man schweigen. | on what one cannot tell.
|
Ludwig Wittgenstein | (a translation)
(1889 - 1951)
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: FTL Computation
Date: Sun, 08 Oct 2000 12:15:51 GMT
In article <SDGD5.13209$[EMAIL PROTECTED]>,
"Paul Lutus" <[EMAIL PROTECTED]> wrote:
> ca314159 <[EMAIL PROTECTED]> wrote in message
> news:8rn255$1bj$[EMAIL PROTECTED]...
>
> > It might be interesting though to consider how
> > this effect may be used for FTL computation.
>
> To earn its name, FTL computation would rely on FTL communication.
Let's see
> if there is any --
>
> > For instance, if a hologram is made of a slide rule
> > with a displacement between the slides, then
> > the apparent FTL motion due to the lighthouse effect,
>
> The lighthouse effect is not an FTL effect. Not apparent, not real.
Imagine
> the water coming out of a swinging hose. None of the water travels at
> greater than the basic stream velocity. It's the same with light.
>
> --
If the projection of a spot of light can virtually move FTL
then so too can the projected images of a slide rule's slides.
The computation 'in effect', takes place FTL.
The I/O to whatever device is doing the projection is physical,
and must obey the speed limit of c, and the uncertainty in
position and time of the projected images.
In effect, the perspective projection is amplifying
a virtual computation speed whereas transisters are
limited to amplifying physical quantities. The Hilbert
space of quantum computers is similarly 'virtual' in
the sense that one doesn't measure it, without it collapsing.
The I/O into Hilbert spaces is also limited by projection
uncertainties and the speed limit of c.
Dependancies have to obey the speed limit, correlations don't.
Any computation which can be put into the later form, via
nomographic duality, can benefit from this space-time
complexity trade-off.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Apologies for a faulty memory
Date: Sun, 08 Oct 2000 14:57:21 +0200
John Savard wrote:
>
[snip]
> Anyways, in addition to congratulating the developers of Rijndael on
> their success, I must also thank Brian Gladman for suggesting keys and
> block sizes that are odd multiples of 32 bits - since that happens to
> create a solution to the apparent problem, if there is any remaining
> grounds for concern.
Sorry for not having followed the material. What are the
main advantages of requiring odd multiples of 32 bits
for key and block size? (Wouldn't that indicate some
weakness of Rijndael's design style?) Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Deadline for AES...
Date: Sun, 08 Oct 2000 14:57:27 +0200
Mack wrote:
>
[snip]
> That choice is fairly arbitrary I think. They state that it
> provides certain properties. No fixed points for one.
> If you are unhappy with the choice it would certainly be easy
> to replace the ByteSub for 'private' use. It could even
> be set up as a keyed table.
>
> Back to Rijndael. The properties of the s-box are such that it
> is unlikely that a backdoor exists. The very simplicity of the
> polynomials used certainly hinders the insertion of trap doors.
>
> The s-box itself is taken from the Nyberg construction.
>
> The affine transformation is stated to
> 1) remove fixed points.
> 2) be the simplest possible.
> 3) add the most complexity to prevent interpolation attack.
>
My point is that the user should be able to verify that
the chosen s-box indeed is the optimum (or one among
'equally' optimals ones) satisfying the above criteria.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: Re: Pencil and paper cipher.
Date: Sun, 08 Oct 2000 12:48:52 GMT
In article <[EMAIL PROTECTED]>, John Savard wrote:
>On Sat, 07 Oct 2000 01:59:23 GMT, Benjamin Goldberg
><[EMAIL PROTECTED]> wrote, in part:
>
>>3) Move the first digit to the end of the message.
>
>>4) Convert digit pairs back to letters. See a and b in step 2.
>
>That basic principle was mentioned in David Kahn's "The Codebreakers"
>as a common amateur system. If the only key is the code for converting
Given we have each letter as a value in GF(p^2) (p=5), are there
any modern tricks which could be brought into play?
TTFN
--
Roger
Think of the mess on the carpet. Sensible people do all their
demon-summoning in the garage, which you can just hose down afterwards.
-- [EMAIL PROTECTED]
------------------------------
** 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
******************************
