Cryptography-Digest Digest #330, Volume #14      Thu, 10 May 01 19:13:00 EDT

Contents:
  Re: Random and not random (James Felling)
  TC15 Design (was Bitsliced Cipher) ("Tom St Denis")
  Quasi Functions, a way to design Maximum Secure Cipher ("Kostadin Bajalcaliev")
  Re: Searching for a free OCSP implementation ("Tor Rustad")
  Re: Bleaming strock cipher ("Paul Pires")
  Re: Quasi Functions, a way to design Maximum Secure Cipher ("Tom St Denis")
  Re: TC15 Design (was Bitsliced Cipher) ("Tom St Denis")
  Re: Quasi Functions, a way to design Maximum Secure Cipher ("Tom St Denis")
  Re: Encryption in JavaSCRIPT (DES or Blowfish) ("Super-Simon")
  DES-CBC without Crypt::CBC ("Super-Simon")
  Re: Secret Sharing algo (Paul Rubin)
  Re: Intacta.Code ... (WARNING: high heat ahead, possible exposure to direct flame) 
(John Savard)
  Re: Security with provable strength. (John Savard)
  Re: Security with provable strength. (John Savard)

----------------------------------------------------------------------------

From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Thu, 10 May 2001 15:03:56 -0500



Mok-Kong Shen wrote:

> Bryan Olson wrote:
> >
> [snip]
> > Mok-Kong Shen wrote:
> > >
> > > Note that, if a dependency
> > > on the content of the OTP segments could result in
> > > any difference, that means directly I could determine
> > > one permutation out of the 6 that the opponent has the
> > > least chance of success and consequently I should have
> > > chosen that one, instead of making a random choice (your
> > > independent choice). Is that right?
> >
> > It is wrong.  We assume the method, but not the key, is
> > known to the attacker.  See Shannon's paper or the FAQ.
>
> I think I could even rigorously prove my claim. Let's
> denote the original and perfect strategy of choosing the
> permutation with U, where, in order to ensure absolute
> no dependency on the content of the OTP segements, I
> additionally employ a perfect die to determine the
> permutation to be used, thus avoiding any conceivable
> human bias. Are you entirely satisfied?

Sounds good so far.

> Under U, the
> opponent's chance of cracking the messages is thus zero.
> Right? Now I devise a second strategy V in that I
> carefully examine the pad and from that information
> determine (according to a certain algorithm designed by
> me) which permutation to choose. According to what you
> have hithertofore maintained up till now, the perfect
> security of OTP is thereby gone, for now the choice
> depends (in fact strongly depends) on the content of
> the OTP segements. Right?

Yes good so far.

> That is, the opponent now
> has a certain non-zero probability P to crack the
> messages. Note however that under U one of the 6
> alternatives is randomly chosen, while under V a
> particular one of the 6 is (deterministically) chosen
> (from the same set of alternatives). Thus there is
> a non-zero probability Q that the selection of U and the
> selection of V coincide.

Ok so far.

> (Offhand I think that Q=1/6,
> but the exact value doesn't matter.) Therefore,
> according to the above, the opponent should have under
> U a non-zero probability of P*Q of cracking the messages,

This is like saying I have a group of people 20% are pregnant, 50% are
men, therefore 10% of my population is made up of pregnant men.

nope this is where you are wrong. In case U with a break of everithning
but 1 pad you have a 100% chance of guessing what that die roll was.
This reveals nothing about our system.

In case V you have a 100% chance of gaining some information about the
pad used in the selection of the permutation, this reveals key data.

>
> which is contradictory to the original assumption that
> U provides the perfect security of OTP.
>
> M. K. Shen
> --------------------------------
> http://home.t-online.de/home/mok-kong.shen


------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: TC15 Design (was Bitsliced Cipher)
Date: Thu, 10 May 2001 20:09:53 GMT

At

http://24.112.8.23:8080/test_tc15.c

You can find the source I used to design the LT.

I plan on making an interactive one where it tries out random rotations and
checks the SAC over 4/8/12/16 rounds to see which has the highest avalanche
and the closest binomial distribution.

As for now..The source shows how I analyzed it.  Basically you pick two
quads <a,b,c,d> and <e,f,g,h> that differ in a single bit and dump the
output <a^e,b^f,c^g,d^h> over the rounds.  If the LT is bad the hamming
weight will be low.  Of course since this is a single shot test it's not
very scientific.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org



------------------------------

From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Quasi Functions, a way to design Maximum Secure Cipher
Date: Thu, 10 May 2001 21:05:07 +0200

Hello

After a years of research I have finally define the Quasi Function theory,
and its practical implementation in cryptography the Polymorphic
Encryption.
Here is only the Introduction chapter of the thesis describing the results
accomplished. I hope you will have interest to examine this thesis, all the
comments and suggestions are welcomed. The full text of the thesis is
available at

http://eon.pmf.ukim.edu.mk/~kbajalc/algo/theory/pme
or
http://kbajalc.tripod.com/algo/theory/pme

As a illustration here is the round function of SQ6 the cipher implementing
the theory described in the thesis:

B0 B1 B2 B3 - are 32-bit words, Message BLOCK
S0 S1 ... S15 - 32-bit words, the KEY
F[0..0xFFFFFFFF](A1,A2) - array of functions returning 32-bit word


Each Round is Defined as

B3^=F[B0](B1,B2);
(B0,B1,B2,B3)=(B3,B0,B1,B2)       /* rotation */


The function is defined as:

T{i,j} denote the number formed from the i-th to the j-th bit of T
Op = {+,xor,*,-}; Op[i] denote the i-th element of set Op
S[0..15] array of 32-bit words = 512-bits of KEY

F[G](A,B,C)= (S[g]<<<g) og A og (S[g]<<<g) og B og (S[q]<<<g)

og - operation choused by G
g  - the value of a particular binary substring of G

=========================
F[T](A1,A2) = (S[{T{3..0}] <<< T{7..4})                           \\
                    op[T{25..24}] A1
\\
                    op[T{27..26}] (S[T{11..8}] <<< T{15..12})             \\
                    op[T{29..28}] A2
\\
                    op[T{31..30}] (S[T{19..16}] <<< T{23..20});

Fox example having T=To=11 01 00 10 0010 1101 0101 1001 1011 1010
The function F will be:

F[To](A1,A2) = (S[10] <<< 11) * A1 + (S[9] <<< 5) xor A2 - (S[13] <<< 2);

==================================================================


1. Introduction

The best representative of the classical block-cipher design paradigm is
Feistel Network with
its most prominent realization, the Data Encryption Standard. The security
in this approach is
determined by the non-linearity of the S-box. Even there have been a wide
interest and
discussion about the design of S-boxes there is no algorithm proposed for
generating “secure
S-box”. Maybe the invention of Differential and Linear cryptanalysis is the
final word about
this paradigm. DES-like ciphers are not candidates for Maximum Secure
Cipher.

Maximum Secure Cipher (MSC) is an encryption algorithm immune to all
possible
(existing and to-be-invent) attacks. Existence of an attack against MSC
implies a
need for a significant knowledge about the key as a precondition to launch
it. The
growing disparity between the advance of the cipher-design and the
cryptanalysis
indicate a convergence in the process of developing secure ciphers. The
limit of this
process is the MSC.

The MSC should be immune to any kind of attack that is trying to discover
the key without a
prior knowledge about it. The classical approach promote the use of fixed
transformation, the
key and plaintext enter a predefined sequence of transformations. Both the
key and the
plaintext have no impact on the algorithm, c=E(k,p) concept. Because of this
the properties of
f can be independently analyzed abstracting the key and the plaintext. As
the history has
shown there is an alternative approach. RC5 has introduced the
data-depend-rotation. This is
the simplest instance of what is going to be described here as Polymorphic
Encryption. Instead
of being a passive object of transformation, the plaintext determines part
of them. The history
of science is showing that each improvement in the human ability to
understand the nature or
to construct something lead to a discovery of at least one new problem.
Because of this, it is
an imperative to acknowledge the boundaries of advance concerning a given
problem. Having
cryptography in mind, the problem of designing secure cipher is equivalent
to the problem of
estimating the efficiency of the possible attacks. This implies existence of
two distinct classes
of solutions. The first approach is to design cipher immune to the attack,
and the second to
design cipher incompatible to the attack. For example, there is no use of
the Differential
cryptanalysis if the cipher is not Feistel-Network based, AES is a nice
example. MSC should
be designed to be incompatible to any kind of attack assuming the secrecy of
the key.
The Polymorphic Encryption is a general concept applicable in MSC design.
The idea is
originally presented in 1997 in ANIGMA [1] cipher and MEX [2] hash
algorithm.
Consequently, there are several different implementations: A2 [3], SQ2 [4],
Z876 [5]. These
algorithms present the evolution of the theory presented in this thesis as
well as the previously
published draft version of this thesis [6]. The goal is to construct a
cipher that act significantly
different according to the key. This is an analogy of the nature, the key is
the DNA and the
cipher is the body. The encryption algorithm specifies a template what
should happen, but
DNA - the key, determines how it is going to, the cipher is an algorithm
that generate an
encryption function according to the key.

==========================================================================







------------------------------

From: "Tor Rustad" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Searching for a free OCSP implementation
Date: Thu, 10 May 2001 22:48:52 +0200

"Tomas Perlines Hormann" <[EMAIL PROTECTED]> wrote in
message
> Hi,
>
> I am currently working on my master's thesis about SignedContent and
> need an implementation of the "Online Certificate Status Protocol
> (OCSP)" as specified in IETF RFC 2560.
> My purpose is to evaluate different certificate validation techniques
> within a PKI.
>
> Does anybody know of a free implementation? I would be very grateful if
> anybody could direct me to some freely available implementations.

Check out the latest cryptlib release, but when I asked Peter G. about OCSP
half a year ago, he had some problems finding an OCSP valdidation site which
was up and running...

Also check keytools lite from Baltimore, however OCSP might be stripped away
in the free version.

--
Tor <torust AT online DOT no>



------------------------------

From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Bleaming strock cipher
Date: Thu, 10 May 2001 12:01:52 -0700


Scott Fluhrer <[EMAIL PROTECTED]> wrote in message 
news:9dda6f$lqq$[EMAIL PROTECTED]...
<snip>
> > Got it! Yep, nothing mysterious just good old fasioned parity.
> > If I take out the xor of the block counter from the B update routine it
> does as
> > you say.
> I overlooked the xor of the block counter (oops).  With it in, then it
> appears that if the block counter from the previous block had even parity,
> then the plaintext parity == ciphertext parity, and if the previous block
> ocunter had odd parity, then the plaintext parity != ciphertext parity.

ocunter? That wasn't a Sloidian frip was it? About the counter versus parity,
for a constant plaintext parity the ciphertext parity flips back and forth in a funny
syncopated way. Here's 64 successive blocks.

0,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,
0,0,1,1,0,1,0,0,1,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1

Don't tell me why! I'm gonna figure it out. I think it has to do with the alternating 
update
which always makes one table lag in regards to the the circular shift.

<snip>
> > I'm really surprised that none of the tests I ran caught this. I guess
>>that says something about relying on tests. Maybe you just had your
>>wheatees today.

> Well, the problem with statistical tests is that they look for obvious
> statistical defects (e.g. too many ones, not enough ones, too many
> occurances of a specific pattern, etc), and hence overlook things such as
> 'the xor of 64 continguous bits show an obvious pattern' -- there are too
> many possible weaknesses like that for them to even think about testing for
> a nontrivial fraction of them.

This is a very practical observation about randomness tests. You often
see, "You can't use a test of data to validate randomness since randomness
is a characteristic of the generator". That's fine but it doesn't always hit
someone where they live. I cringe when I see someone pointing to a
particular test and saying, "In this way you have an absolute reference for the
goodness of a PRNG" Next time someone say's that, I'm going to take some
random output, divide it into weird, arbitrary blocks, diddle a few bits in each
block according to a coin flip until the parity from block to block spells out,
"You Loose". Hand this to the guy who say's he has an oracle that makes a
yes/no answer on randomness and see what he finds.

Much easier than arguing.

Paul

>
> --
> poncho
>
>
>




------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher
Date: Thu, 10 May 2001 21:24:52 GMT


"Kostadin Bajalcaliev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello
>
> After a years of research I have finally define the Quasi Function theory,
> and its practical implementation in cryptography the Polymorphic
> Encryption.

"Polymorphic" just means many shapes doesn't it?  How does your cipher
change shape?

> Here is only the Introduction chapter of the thesis describing the results
> accomplished. I hope you will have interest to examine this thesis, all
the
> comments and suggestions are welcomed. The full text of the thesis is
> available at

Blah blah blah.  Why would the laymen (like me) give a rats ass?  You should
really post your claims/results/findings.

For example when I posted my nifty toy block cipher I also posted "one would
care because it's fast, small, efficient, etc...).

Tom



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15 Design (was Bitsliced Cipher)
Date: Thu, 10 May 2001 21:27:48 GMT


"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:lACK6.59213$[EMAIL PROTECTED]...
> At
>
> http://24.112.8.23:8080/test_tc15.c
>
> You can find the source I used to design the LT.

I modified that source to look for good LT's.  If someone could go thru the
above source I would appreciate it to make sure my math is right.

Basically I calc the distribution of differences 0..128 from two texts (I
ignore the sbox in this test).  on average (er mode) 64 bits should change.
This then calcs the error between the expected distribution and the observed
and normalizes it out of 1 (1 = bad, 0 = good).  I only used four rounds
since with 16 virtually any LT is good...

The original TC15 got a score of 0.93.  I found LT's with a score of 0.86.

New TC15 source is on the website

http://24.112.8.23:8080/tc15.c

In theory (if the above program is right) the new TC15 should have a higher
avalanche rate and appear more random.  Since it follows the distribution
closer.

Tom



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher
Date: Thu, 10 May 2001 21:42:09 GMT


"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:EGDK6.59342$[EMAIL PROTECTED]...
>
> "Kostadin Bajalcaliev" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hello
> >
> > After a years of research I have finally define the Quasi Function
theory,
> > and its practical implementation in cryptography the Polymorphic
> > Encryption.
>
> "Polymorphic" just means many shapes doesn't it?  How does your cipher
> change shape?
>
> > Here is only the Introduction chapter of the thesis describing the
results
> > accomplished. I hope you will have interest to examine this thesis, all
> the
> > comments and suggestions are welcomed. The full text of the thesis is
> > available at
>
> Blah blah blah.  Why would the laymen (like me) give a rats ass?  You
should
> really post your claims/results/findings.

Again this is me making a fool of myself.

Sorry... damn it.  I meant "what are your findings?" (ignore the rats behind
part).

Tom



------------------------------

From: "Super-Simon" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.javascript,comp.lang.javascript
Subject: Re: Encryption in JavaSCRIPT (DES or Blowfish)
Date: Thu, 10 May 2001 23:53:23 +0200

Thanks!

"jlcooke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> www.google.com
> "des.js"
> and press "I'm feeling lucky".
>
> But you do not have the same control over memory in JS and you do in
> compiled languages, so any data you encrypt is still susceptible to
> localhost memory attacks by virii.
>
> JLC
>
>
> Super-Simon wrote:
> >
> > Hi,
> >
> > Is it possible to encrypt and decrypt strings with DES or Blowfish in
> > JavaSCRIPT? If it is possible, where can I get more information????
> >
> > With kind regards,
> >
> > Simon



------------------------------

From: "Super-Simon" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.comp.perlcgi.freelance,alt.perl,alt.perl.sockets,comp.lang.perl,comp.lang.perl.misc
Subject: DES-CBC without Crypt::CBC
Date: Fri, 11 May 2001 00:00:42 +0200

Hi all,

I have to encrypt / decrypt strings using DES-CBC. On my hostingserver is
Crypt::DES installed, but not Crypt::CBC (the only Crypt modules installed
are DES and Blowfish).

Where can I get a .pl file doing this (without using another Crypt-module
than Crypt::DES)??????


With kind regards,

Simon



------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Secret Sharing algo
Date: 10 May 2001 15:22:52 -0700

"Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
> How about just encrypting the secret key to all key share-holders in
> succession?! Without any checksums inside which would compromise the
> final security. E.g. if you want to split a key into five shares of
> which three need to be reunited you could just encrypt the key to every
> possible combination of three keys:
> 
> /5\
> \3/ == 5!/(3!.2!) == 5.4/2= 10 different encrypted blocks of keys. Not
> that much data to use. If you want all shares to be united you would
> just need one block of encrypted secret key data. Even (5 above 4) has
> lesser data than the (5 above 3 or 2) example.
> 
> K.I.S.S. ??!

If you want to split it into 100 shares where 50 can reconstruct the
key, the number of blocks gets impractical.  Existing secret sharing
schemes aren't that complicated and don't have that problem.


------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Intacta.Code ... (WARNING: high heat ahead, possible exposure to direct 
flame)
Date: Thu, 10 May 2001 23:03:59 GMT

On Wed, 9 May 2001 12:38:53 -0700, "Joseph Ashwood" <[EMAIL PROTECTED]>
wrote, in part:

>John's so-called attack on you was a comment that I guess hit your
>masculinity a bit too closely to what you fear, for the rest of us it was a
>funny remark.

I was wondering what you were talking about, since while I have spoken
bluntly to "newbie", I hadn't brought his masculinity into it, but
after hunting up the thread, I see you're referring to the post by
John Luebs.

John Savard
http://home.ecn.ab.ca/~jsavard/

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Security with provable strength.
Date: Thu, 10 May 2001 23:06:03 GMT

On Wed, 09 May 2001 22:30:22 -0400, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:

>I have two questions: one, what's its name (I'm sure someone remembers,
>even if I don't), and two, how does this scheme compare to Rabin's
>"unbreakable" encryption scheme -- assume that the random strings can be
>gotten from the same sort of random source that Rabin's scheme uses.

I don't think that scheme can be compared to Rabin's scheme at all;
they're not in any way related.

This scheme, if anything, reminds me of knapsack algorithms.

John Savard
http://home.ecn.ab.ca/~jsavard/

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Security with provable strength.
Date: Thu, 10 May 2001 23:07:43 GMT

On 09 May 2001 19:49:16 -0700, Paul Rubin <[EMAIL PROTECTED]>
wrote, in part:

>It was attributed in AC2 to Udi(sp?) Maurer, but it's completely
>insecure and there has to be some kind of mistake involved.

No, it isn't trivially insecure. Suppose the message is also N bits
long, and the N strings are:

10000....000
01000....000
00100....000
...
00000....001

The matrix is even invertible, but the system is secure: it's the
one-time-pad.

John Savard
http://home.ecn.ab.ca/~jsavard/

------------------------------


** 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 by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to