Cryptography-Digest Digest #934, Volume #11 Sat, 3 Jun 00 21:13:00 EDT
Contents:
Re: Cipher design a fading field? (Mok-Kong Shen)
Re: Cipher design a fading field? (Mok-Kong Shen)
Re: Good ways to test. (Mok-Kong Shen)
Re: Need "attack time" measurements on a toy cipher... (long) ("Paul Pires")
Re: Good ways to test. (tomstd)
Re: Cipher design a fading field? (tomstd)
Re: Cipher design a fading field? (Benjamin Goldberg)
Re: Cipher design a fading field? ("Paul Pires")
Re: Cipher design a fading field? (tomstd)
Re: OT patent protection (Tim Tyler)
Re: Cipher design a fading field? ("Paul Pires")
A Ripe Pomegranate (wtshaw)
Re: No-Key Encryption (David Hopwood)
Re: No-Key Encryption (David Hopwood)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Sun, 04 Jun 2000 01:26:31 +0200
tomstd wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> >Jack wrote:
> >> You can be assurred that phony
> >> crypto gods will say we need more speed in encryption rates. I
> >> say let the hardware speed improve but with just faster
> methods
> >> being proposed I feel it makes us the people more vulnerable
> to
> >> a evil big brother.
> >
> >There is definitely some truth in what you said. The 'one thing
> fits all'
> >stategy, requiring algorithms for encrypting top-level secrets
> to also
> >satisfy the tight memory requirements of some less critical
> applications,
> >and the psychologically seducing advocation for getting ever
> higher
> >performance combine to set sort of implicit upper bound of the
> >strength of algorithms that the current state of the art is
> able to
> >produce. That upper bound might not be ideal for applications of
> >highest security level.
>
> This makes no sense.
>
> While yea we can make 1000 round ciphers that are secure,
> wouldn't the more intelligent thing be to make 10 round ciphers
> that are just as secure?
>
> I agree that you should be conservative (i.e Serpent, Rijndael-
> 18, RC6-24) but not out of proportion.
>
> I strongly believe that Twofish is the best counterexample to
> your point. It's appears strong yet performs well in a variety
> of platforms. Does that interoperability make it a bad cipher?
I must point out that your questions above don't have 'direct'
relationship to what I wrote. I way saying that if one wants a cipher
to be extremely economical in memory usage and also extremely
fast, then its strength understandably would be lower than a similarly
well designed cipher under relaxed (such) requirements. Isn't that
at least plausible and intuitively clear?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Sun, 04 Jun 2000 01:26:25 +0200
tomstd schrieb:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
> [EMAIL PROTECTED]> wrote:
> >
> >
> >tomstd wrote:
> >
> >> To quite the contrary the AES ciphers are faster and more
> secure
> >> then DES. So your idea of fast != secure is invalid.
> >
> >There are more issues involved than is apparent. One has also to
> >take technological advances into consideration. A modern
> airplane
> >is, for example, considerably more secure than a vessel of the
> 18th
> >century.
>
> I am failing to see the point? Does my K6-2 make 3DES any less
> secure? Is that your point?
I never heard of your K6-2. Does that answer well your questions?
I was arguing that the relationship between speed and security can be
rather involved, because a lot of factors must be considered thereby.
Because of this, it is my personal opinion that it is difficult to argue on
the basis of that (inherently complex) relationship.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Date: Sun, 04 Jun 2000 01:29:22 +0200
tomstd wrote:
> Freedom of thought has nothing todo with this. I am not trying
> to force my will on ya, I am telling you the truth.
>
So you are the greatest philosopher of all time. What you say IS
truth. Philosophers of the past are apparently more humble.
M. K. Shen
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Need "attack time" measurements on a toy cipher... (long)
Date: Sat, 3 Jun 2000 16:28:36 -0700
> I know you set up a pretty good work plan for the folks in here to follow
> but you have to understand that no one here is very good at coloring
inside
> the lines.
Before I continue further, let me publicly thank you for your clear and
concise explanation of what to expect here. I mean that literally, not
sarcastically.
I was talking primarily about myself but I don't think that you will find
that reverence or tractability is a treasured virtue here.
<snip>
Okay, translating your statement to 0-based, you know C[4] and C[5].
So you can solve for (TempChar + K[5]) mod 256. How did you get K[5]?
If you can't get K[5], how did you get P[5]?
I would have thought you would start by using C[0] and C[1].
Or by comparing multiple ciphertexts since I was stupid enough to use the
same key on all of them.
This is what I was getting at "I would have thought you would have..." You
start setting up defenses according to your idea of what the adversary would
do and you are already toast.
I pointed out that there probably was Known plaintext, it was just something
you were not worried about cause it was old. I think you confirmed that I
scored a clean hit there. In conjunction with using the same key (which it
turns out is not the case), that means that:
you got a 6 character pre-pad, thats P[0] thru [5]
Then the length of the plaintext P[6]. (I know this value cause I caught you
napping and snatched it up from where you didn't think to look. The
assumption is that I also have the related ctext).
P[6] - C[5] = T[6]. If it's negative, add 256.
C[6] - T[6] = K[6]. if it's neg, add 256.
K[6] yeilds the plaintext size of any other plaintext from it's ciphertext
right?
If I have the whole plaintext and not just it's length I think I have your
whole key from K[6] to the last character before the pad.
Did I miss something? If I did, go to Joseph smiths post as he seems to know
the real answer.
I wasn't trying to show you a break I was trying to point out that the
mindset of building a fortress and standing in the portal with your sword in
hand is a habit you should break. Don't worry about cryptanalysis until you
have ruled out dumpster diving.
Finding out the conventional flaw with your system doesn't tell you squat
about the worst case risk. If you got a time approximation from someone here
and it was something you could live with, would you have used it?
Protect that weenie status.
Those of us who aren't even real bright might be sneaky.
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 03 Jun 2000 16:53:04 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>
>> Freedom of thought has nothing todo with this. I am not
trying
>> to force my will on ya, I am telling you the truth.
>>
>
>So you are the greatest philosopher of all time. What you say IS
>truth. Philosophers of the past are apparently more humble.
Oh stop being an idiot.
Are you trying to tell me that no drug ever released as 'safe'
has ever had a adverse side effect?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Cipher design a fading field?
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 03 Jun 2000 16:54:29 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>
>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>
>> >Jack wrote:
>
>> >> You can be assurred that phony
>> >> crypto gods will say we need more speed in encryption
rates. I
>> >> say let the hardware speed improve but with just faster
>> methods
>> >> being proposed I feel it makes us the people more
vulnerable
>> to
>> >> a evil big brother.
>> >
>> >There is definitely some truth in what you said. The 'one
thing
>> fits all'
>> >stategy, requiring algorithms for encrypting top-level
secrets
>> to also
>> >satisfy the tight memory requirements of some less critical
>> applications,
>> >and the psychologically seducing advocation for getting ever
>> higher
>> >performance combine to set sort of implicit upper bound of
the
>> >strength of algorithms that the current state of the art is
>> able to
>> >produce. That upper bound might not be ideal for
applications of
>> >highest security level.
>>
>> This makes no sense.
>>
>> While yea we can make 1000 round ciphers that are secure,
>> wouldn't the more intelligent thing be to make 10 round
ciphers
>> that are just as secure?
>>
>> I agree that you should be conservative (i.e Serpent,
Rijndael-
>> 18, RC6-24) but not out of proportion.
>>
>> I strongly believe that Twofish is the best counterexample to
>> your point. It's appears strong yet performs well in a
variety
>> of platforms. Does that interoperability make it a bad
cipher?
>
>I must point out that your questions above don't have 'direct'
>relationship to what I wrote. I way saying that if one wants a
cipher
>to be extremely economical in memory usage and also extremely
>fast, then its strength understandably would be lower than a
similarly
>well designed cipher under relaxed (such) requirements. Isn't
that
>at least plausible and intuitively clear?
I disagree again. I think if enough work is put into the cipher
then you can have both compact and efficient ciphers that are
also secure.
You must remember that the five AES candiates where not designed
in an hour.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Sun, 04 Jun 2000 00:07:42 GMT
Mok-Kong Shen wrote:
>
> tomstd wrote:
>
> > To quite the contrary the AES ciphers are faster and more secure
> > then DES. So your idea of fast != secure is invalid.
>
> There are more issues involved than is apparent. One has also to
> take technological advances into consideration. A modern airplane
> is, for example, considerably more secure than a vessel of the 18th
> century.
We're talking about software, not hardware... The AES algorithms are
faster than DES even when run on the same machinery. If I use RC6
on a machine that DES was designed for, RC6 will still be faster
and more secure than a DES cipher of the same keylength.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Sat, 3 Jun 2000 17:08:23 -0700
<snip>
> I disagree again. I think if enough work is put into the cipher
> then you can have both compact and efficient ciphers that are
> also secure.
Sounds like your Cipher designing exercise is corrupting the analyst in you.
Watchout Tom, you are giving me an opening to plug "Weird Stuff".
Paul
------------------------------
Subject: Re: Cipher design a fading field?
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 03 Jun 2000 17:11:19 -0700
In article <w7h_4.57892$v7.2395134@news-
west.usenetserver.com>, "Paul Pires" <[EMAIL PROTECTED]> wrote:
><snip>
>> I disagree again. I think if enough work is put into the
cipher
>> then you can have both compact and efficient ciphers that are
>> also secure.
>
>Sounds like your Cipher designing exercise is corrupting the
analyst in you.
>
> Watchout Tom, you are giving me an opening to plug "Weird
Stuff".
I must be losing my grip on reality. I honest have no clue what
the heck you guys are talking about.
You are denying that secure ciphers could be efficient? Or
what? What the hell is your position?
We agree that no cipher is PROVABLY secure but we take the best
we can, but why can't the best we have be efficient? Or
secure? Secure is just "we don't know how to break it yet", but
think of it this way: If you don't know how to break it (or
presumably nobody does yet) then how can your information be
compromised with it?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OT patent protection
Reply-To: [EMAIL PROTECTED]
Date: Sat, 3 Jun 2000 23:23:49 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
: For a treatment of the negative effects of lack of patent systems read the
: industrial history of the USSR, it's sad. [...]
Many other factors were involved there, though.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Sat, 3 Jun 2000 17:21:48 -0700
Calm down. Take a chill pill.
I was making a reference to something you said to me in an E-mail about the
value of designing ciphers vrs analyzing them. Your post sounded like
something I would say.
Sorry for the left turn without signaling.
Paul
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <w7h_4.57892$v7.2395134@news-
> west.usenetserver.com>, "Paul Pires" <[EMAIL PROTECTED]> wrote:
> ><snip>
> >> I disagree again. I think if enough work is put into the
> cipher
> >> then you can have both compact and efficient ciphers that are
> >> also secure.
> >
> >Sounds like your Cipher designing exercise is corrupting the
> analyst in you.
> >
> > Watchout Tom, you are giving me an opening to plug "Weird
> Stuff".
>
> I must be losing my grip on reality. I honest have no clue what
> the heck you guys are talking about.
>
> You are denying that secure ciphers could be efficient? Or
> what? What the hell is your position?
>
> We agree that no cipher is PROVABLY secure but we take the best
> we can, but why can't the best we have be efficient? Or
> secure? Secure is just "we don't know how to break it yet", but
> think of it this way: If you don't know how to break it (or
> presumably nobody does yet) then how can your information be
> compromised with it?
>
> Tom
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: A Ripe Pomegranate
Date: Sat, 03 Jun 2000 18:17:11 -0600
I began this whim night before last, and found good prospects of a stream
cipher using base 26. I speculated that bigger bases and longer seeds
would mean scaled strength, but I was somewhat in error.
I remember myself saying a time or two that bases are like totally
different worlds and no assumption should be made with out testing, so I
did.
I picked what I would consider representative bases and compared their
behavior with the generic pomegranate algorithm. Bases tested where
25/26/27/30/32/33/35/47.
b25: RU--100; RUN--120; RUNE--1560; RUNES--3905; CRYPTO--15,620
There were lots of obvious bad sequences with repeated letters in b25.
b26: RU--84; RUN--1281; RUNE--10,980; RUNES--216,581
b27: RU--72; RUN--117; RUNE--720; RUNES--1089; CRYPTO--6552
b27 was a disapointment
b30: RU--120; RUN--2184; RUNE--3120; RUNES--more than 25,000
b32: RU--48; RUN--112; RUNE--240; RUNES--336; CRYPTO--1008; JUSTICE--2032
binary did not seem to pass muster
b36: RU--24; RUN--536; RUNE--240; RUNES--5082; CRYPTO--6552
b47: RU--32; RUN--2257; RUNE--more than 1 million characters
b47 was really a surprise
I picked as winners b26, b30, b33, and b47, which were incorporated into
the finished application designed to bleed in a tantalizing manner. Each
character has two cases, so shifts are seen in ciphertext. Characters
outside of the selected set, as well as spaces and formatting characters,
pass through. The processing dumps the keyword, or a set number of
characters up to 1000 from the keysteam.
Using the default keyword of POMEGRANATE and a dump of 11 characters, here
is this sentence encrypted with bases 26, 30, 33, and 47:
Kvvhh kux gzownvr flhvpyl gl AKRXRULFDUY kre h ulsn vd 11 jyicbntlza, pfta
xh hral lqtusuif jbrztzlct grpn bgajl 26, 30, 33, rqz 47:
Amts, yot hglextu t/rpmvd lk QQFQVEXLVXQ miq z v'rl sw 11 pjftt',xlyy upaq
wt 'c'j frdd,hr, bhepmiazj a,'l farpo 26c 30f 33/ lji 47:
Who,, ;nq zlt.saw kxm,nio j/ KUBOBX<SJHZ elf i hwn= or 11 'md'plzzead kpdc
cd qsnn bvng=/up xqqulferg vil. v,-pt 26m 30- 33/ //n 47M
>on5z /c. pdh2xpz \8=bhl9 uc K"H%&()<*DC 819 m 1/j9 ti 0c fjuu.y35ugd \=ev
on msft 89b,,w'v [,qbw4fu` c9g0 m38=/ d6w 85d j-\ .m0 ]jX
I'll put it aside for awhile, but adding custom sets and/or scrambling the
base strings would be just ducky on another rainy day.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
------------------------------
Date: Sat, 03 Jun 2000 21:33:06 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No-Key Encryption
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> John Savard wrote:
>
> > But M*A*B = M*B*A for all M,A,B does not necessarily imply that A*B =
> > B*A for all A,B.
> >
> > I gave an example: perhaps M*Q = M*(-Q) for all M,Q, and A*B = -(B*A)
> > for all A,B. (For example, A*B might be |A| - |B|, although that
> > operator is not associative.)
>
> I am not yet convinced of that. Since '*' is assumed to be associative,
> we certainly have M*(A*B)=M*(B*A). If this is true for any M, I
> think that by applying the inverse one should have A*B=B*A, which
> is the commutativity.
Only if * has a left inverse (i.e. an operation \ s.t. a \ (a * b) = b).
Note that it does need to have a left inverse (which must be feasibly
computable) for the given protocol to work; see my previous post, where
this was one the cases needed to prove that the protocol is insecure for
any associative operator.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTlraTkCAxeYt5gVAQHacwf/eVY35wBnWKfDYOU2cL5yAYAkU41H++qK
YwxYGxBHyrbdaNETgfudG8BnOfMqClaIhhg692zdsDrBXLg8zakNClPVcDpct4vH
ciD3Z+M6y171UhdM+gPz7T+dbqtWqDwLM2Z9gYwScdNOP5Yw6NFc1UOYK0WD8eyv
Uzmkl/1BPS1/zOlJBK5+hDvPZtpZvbSH035ltf1eQ0zOlJAk8yiCJ8i29sUEyrH+
NJm+ILY+bXQPoMbybxnpvJ/VZpCFRQesQQHhmPiOdgz0QMr9/NvGwoUzAAvFD8wS
hgChxuSF4yPm+hdA35iiO3yW4M+XBsTnG/I9GglmUNkwN1f0luQPBQ==
=f2/W
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 04 Jun 2000 01:02:29 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No-Key Encryption
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> John Savard write:
> > <[EMAIL PROTECTED]> wrote, in part:
> >
> > >I am not yet convinced of that. Since '*' is assumed to be associative,
> > >we certainly have M*(A*B)=M*(B*A). If this is true for any M, I
> > >think that by applying the inverse one should have A*B=B*A, which
> > >is the commutativity. What is the flaw here?
> >
> > It's true that there is a right-inverse, so that from M*A, we can
> > obtain M by doing (M*A)/A. But I don't recall seeing it stated that a
> > left-inverse exists.
>
> I suppose you allow a bit more discussion. From the expression like
> M*A*B it can be implied that M, A and B are from the same domain.
> Hence the type of operands on both sides of the operator '*' are
> the same. Now, assuming the existence of a right inverse, we get
> I=A/A, the identity.
What identity? '*' was not stated to form a group [1], so A/A is not
necessarily the same for all A. Even if it were, (A/A)*A is not
necessarily equal to A (note that this is *not* implied by (A*A)/A = A),
and certainly (A/A)*B is not necessarily equal to B, which your argument
implicitly relies on.
> Could you see any flaw in the above?
A concrete counterexample is given by defining a * b = a, and a / b = a
for all a, b in some set with more than one element.
[1] To get back on topic for sci.crypt, there are some interesting cases
of mathematical structures that are not groups, but which can be used
in Diffie-Hellman or discrete log protocols, because (g^a)^b = (g^b)^a.
An example is the infrastructure of reduced ideals in cycles of real
quadratic orders [2]. (I can't remember the details right now, so I
don't know whether this would be suitable for Massey-Omura. Since
Massey-Omura is insecure against active attack anyway, it's rather
academic.)
[2] Ingrid Biehl, Johannes Buchmann, Cristoph Thiel,
"Cryptographic Protocols Based on Discrete Logarithms in
Real-quadratic Orders,"
Advances in Cryptology - CRYPTO '92.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTlzmzkCAxeYt5gVAQE9xggAj1cj8p9aMZKsfuctHyx670EWgEmRWpf8
TDyQeB6mS6uyIo5ZDR7lqlKxX1EIWxFpLI8GrAH1FQHHZUdNv4Hlxo4KVE93A4QJ
Ee4rJ+bw2qjVDjLuiHXEpWd5UgiwrdMwzC2UtZ3x0pybKWDbMD0nqgmTGEvY6enS
WD1GFXtKZ4yqX7Nk/VQrHMBFe0V4a6ZOTGTraJRcoXYTkc/9sjlrxmOrcYG5BzoJ
WCQkwGwyGIw9a0xSBnBuNHE/UPgw/baLvKABZ7Y4S+FATyRH9mco950AQYOnIkHO
SFCxa/+/NvUTvIwf9Wj9jNZu5FfGuBzbr9TaVaCBuXBGxe9xWo0Xdg==
=uwFX
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
