Cryptography-Digest Digest #376, Volume #13      Thu, 21 Dec 00 14:13:01 EST

Contents:
  Javascript Implementation of Block Cipher ([EMAIL PROTECTED])
  Re: Visual Basic Source Code ("Jason Bock")
  Re: Steganography using text as carrier ([EMAIL PROTECTED])
  Re: In today paper I read how Cuban intelligence (Arturo)
  Re: Javascript Implementation of Block Cipher (Paul Rubin)
  Re: All irreducible polys of degree 32 over GF(2) (Mike Rosing)
  Re: Diffie-Hellman Matrix Idea To Break (Bill Unruh)

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

From: [EMAIL PROTECTED]
Subject: Javascript Implementation of Block Cipher
Date: Thu, 21 Dec 2000 15:59:44 GMT

Hi,

I need to implement a block cipher in Javascript for an application that
sends sensisitive (ciphered) information by e-mail and a Javascript code
 then decrypts the mail.

The problem is that Javascript is too slow and, because JS is sent by
mail too, the code can't be too large.

What block cipher is the best choice?
- Must be fast
- Must be tiny
- Must be secure

I thought in TEA, but i think it isn't too strong.

Thanks in advance


Sent via Deja.com
http://www.deja.com/

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

From: "Jason Bock" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Source Code
Date: Thu, 21 Dec 2000 10:30:10 -0600

Paul Schlyter <[EMAIL PROTECTED]> wrote in message
news:91s2mn$q7d$[EMAIL PROTECTED]...
> In article <3a3e475b$0$17730$[EMAIL PROTECTED]>,
> Jason Bock <[EMAIL PROTECTED]> wrote:
> > Guess we have different career insights.  But I did KNOW what the
> > timelines were for the projects I was on.
>
> So did I.  But did you ever consider what might be beyound the
> deadlines of your projects?

Of course.  Your point?

> You describe the customer as some kind of dictator,

Maybe I was being a bit harsh, or you were misinterpreting me.  Either way,
my point is that, if someone hires me as a consultant to work on developing
a system, I'll look over their requirements and tell them what I think is
doable and what is flat-out wrong.  Bottom line is, if they insist that the
"wrong" stuff must be done in two weeks, they're the one holding the money,
not me.  I do have a choice, though.  I can say they're full of it, or I can
give in.  I can also try to see if more discussions will help them see the
error of their ways.

This is usually the rarity.  Most people are willing to hear opinions.  But
I have been on a project where the leader demanded new functionality with
little thought to the outcome.

> But if you
> find yourself doing these quick-n-dirty jobs constantly all the time,
> you should perhaps step back awhile and think about whether this
> actually is what you want to do, and if not you should change your
> situation.

Again, this is the exception.  I'm perfectly happy with my career and where
it's going, though - it's quite different from what you probably think it is
;).

> > Although I try to code prototypes as best as I can, I always add the
> > qualifier that a prototype is just what it is.  It may lead to different
> > ideas and the original one may be canned altogether.  That has nothing
> > to do with the effort of the code underneath.  I was just on a project
> > where I needed to prototype something on a Jornada unit.  I bet none
> > of that code will ever see the light of day for that project, but I
> > learned a lot and I will use that code base sometime in the future.
>
> You see?  It's useful to have what'll happen beyond your prototype
> project even if that particular prototype never makes it into a product.
> Code snippets can wander between projects -- if they are good enough,
> that is.

But again, pressures may not lead to such endeavours.  My point is that a
good developer will always try to write good code, even when the time
pressure is against him/her.  But a short timeline to completion will stress
quality.  That was my point.  You HAVE to allow time to design for reuse.
It simply doesn't happen on its own accord - good intentions isn't good
enough.

> > Again, if the underlying goal is time-to-market, reuse usually falls by
> > the wayside.
>
> But what happens once you're on the market?  I guess there'll be
> demands for new versions.  Will you be able to crate them quickly
> enough?  Depends partially on how well the original version is -- if
> every new version requires a rewrite from scratch becaose of the bad
> quality of the code in the older verison ... well ....
>
> ...but of course that's not your problem if you, by then, is doing
> some other job, rushing some other code to be on market in time...

Cheap shot with no substance.  I get asked to work on a project for a
certain amount of time.  I work on it as best as I can.  Once my time's up,
though, I'm done.  Sorry if you don't understand that I have no control over
my work after the client has taken over the responsibility of maintenance.
I don't rush to another project.

I'm not a cowboy programmer who relishes in hacks and quick fixes.  I try to
create quality code.  But I have no control over a project years after I
left it (which, given the state of current business systems, means it's dead
or competely reworked anyway :( ).

> > In that case, one may argue you write it all in Java.  Or some other
> > language that purports cross-platform use.  Problem is, there's SO much
> > code written in other languages in other systems that you end up with a
> > hard choice.  Do you decide to rewrite it all in the current
warm-n-fuzzy
> > language of the day, or do you try and interop?  That's where I think
> > we'll eventually end up.  It's simply too difficult to get everyone to
> > speak the same language and get everyone to use the same OS.  You're
> > always going to need to interop.
>
> There will of course not be one single language which everyone uses,
> and Java is really too young for us to be able to judge how popular
> it'll be in 5 or 10 years.  However some languages are more portable
> than others, and one can at least try to avoid the less portable
> languages.

Again, though, even with languages that are more portable, you'll still run
into interop issues.  You'll never get away from that.

> > Of course I recommend writing portable code when I can.  Again, though,
> > the requirements of a project may not be geared towards such an
endeavor.
>
> True.  But again, you might then be on the wrong project.

Well, define "wrong project."

> > Well, I wouldn't do this.  As I stated, things change too much.  I
really
> > don't program much in VB anymore, simply because I don't see a lot of
future
> > with it in MS's .NET world (I personally use C#).
>
> C# is another non-standard language invented by Microsoft.

I won't argue this.  MS will (has?) submit this to ECMA.  I can already hear
the howls of derision from someone that they won't, it's all
smoke-n-mirrors, it's a Java-copy (which, to me, Java is a C++ mutation).
My point is that, you can claim that C# is a non-standard language.  If MS
doesn't submit to ECMA or some other standards body, then it won't be.  But
if it is, what do you say then?

> Which probably highlights another difference between you and me: you
> seem to want to follow what Microsoft says, while I'm not too eager
> to do that.

<snicker/>  Yes, all hail MS, the Evil Empire, blah, blah, blah.

My focus is primarily MS/Windows systems.  I'm also willing to move to
another tool/OS if need be.  Just because one uses MS tools does not mean
they hear the word Linux or Java with a complete blank look on their face.

> Yes, MS has a big part of the market, but apart from
> that MS isn't particularly exciting.  Fortunately MS isn't the whole
> market, and there are some job opportunities outsides MS market too.

Really?  You think?  <:(

> >> "If house built hoses the way programmers build software systems,
> >> the next woodpecker which came along would destroy civilisation...."
> >
> > If house build hoses?  Eh??
>
> Sorry, a typo.  Should be:
>
> "If house-builders built hoses the way programmers build software
> systems, the next woodpecker which came along would destroy
> civilisation...."

"house-builders built hoses"?  I think you mean, "house-builder built
houses."

Again, depends on the programmer, the conditions under which the system was
created, etc., etc.

> > I would add this, if (good) developers and programmers were given the
time
> > to implement systems with reuse in mind, solid test plans, etc., then we
> > would be in a better place.  But if management is in power and demands
the
> > new system be done in 2 weeks, there's not much wiggle room.
>
> You can always switch jobs, finding a manager who is more open for
> these considerations.  If sloppy managers would find it's hard to get
> developers working on such consitions, they would become less sloppy
> - or vanish from the market.

You'd be suprised to see what is put up with in the development community.
Not that I do, but a lot of people are willing to work 70-hour weeks coding
ill-defined systems.  I love development, but I'm not about to sacrifice
both my physical and mental health for it either.

> > But I don't really see what this all has to do with VB being or not
being a
> > "real programming language."  I think it is, just as I think Eiffel,
Perl,
> > C#, Java, COBOL, Ruby, C, etc., etc., etc., are all real programming
> > languages.
>
> I guess we have different definitions of a "real programming language".

So, to you, a "real programming language" is one that allows you to create
an OS - i.e. it lets you do whatever you want.  So what do you define the
rest of them?  "Imaginary"?  "Non-real"?

> > Jason
> >
> > P.S. Personally, if I had the choice I'd have everyone program in Eiffel
or
> > some derivative thereof.  It's one of the cleanest languages I've ever
seen.
> > But it's used so infrequently that I haven't made it my principle
language
> > (I need to make money ;) ).
>
> If you had been a programmer back in the early 1960'ies, what
> language would you have used?  Your choices would have been Algol and
> FORTRAN.
>
> In Algol you could have written all sorts of (for that time) elegant
> and clean programs, which also would have been portable as long as
> you didn't do any I/O (the Algol standard didn't specify any I/O
> operations since it considered them to be too "machine dependent").
> However you would encounter severe difficulties if you wanted to run
> your program, because few Algol compilers were available.  Also your
> entire program had to be in one single Algol source file, since
> separate compilation of subroutines was unavailable in Algol.  But
> you could of course have built your own pre-processor with #include
> directives.
>
> In FORTRAN you would have been forced to unstructured spaghetti code
> with lots of GOTO's and similar mess.  If you wanted to do some
> string processing, you would be forced to mess with storing character
> strings in numeric variables since FORTRAN at that time lacked string
> variables (and the number of characters which could fit in one
> numeric variable would be machine dependent, varying between 4 and
> perhaps 10).  However, you WOULD be able to run your program on most
> of the computers available at that time.  And you could build
> libraries of often-used subroutines since separate compilation of
> sobroutines was available in FORTRAN from a very early stage.
>
> What language do you think you would choose under these circumstances?

I'd pick the language depending on what was needed to get the job done ;).

Jason



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

From: [EMAIL PROTECTED]
Subject: Re: Steganography using text as carrier
Date: Thu, 21 Dec 2000 16:32:41 GMT

In article <[EMAIL PROTECTED]>,
  Andre van Straaten <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:

> > compare any  text (T)  to any desired carrier text, (C) character to
> > character, and the difference between the the character in (T) and
the
> > character in (C) can be represented by a number
> > [using positive integers only, ~ e.g. if the character  <d> in T is
> > represented by 100, and the character <b> in C is represented by 98,
> > the difference would be represented by the number 298 {300-100+98}
not
> > by the number 2]
>
> > the offset between any text T and any carrier C, will be able to be
> > expressed as a string of three digit integers, resulting in one very
> > large integer , which can be expressed as an MPI.
>
> Sorry, no clue what is an MPI. Without that, I have problems to
> understand your idea at all.

an MPI is a Multi Precision Integer, commonly used in pgp and other
cryptographic implementations, see the revised rfc 2440:
http://www.imc.org/draft-ietf-openpgp-rfc2440bis

"...
3.2. Multi-Precision Integers

   Multi-Precision Integers (also called MPIs) are unsigned integers
   used to hold large integers such as the ones used in cryptographic
   calculations.

   An MPI consists of two pieces: a two-octet scalar that is the length
   of the MPI in bits followed by a string of octets that contain the
   actual integer.

   These octets form a big-endian number; a big-endian number can be
   made into an MPI by prefixing it with the appropriate length..."

what the MPI accomplishes is to represent a very large integer in a
short notation so that it can be sent easily {and hopefully
steganographically 'hidden' easily } and then reconstructed back into
the very large actual integer when necessary.

in the above proposed scheme, any text can be represented as a series
of three digit integers.
when two texts are compared looking at the  three digit integer
groupings in one text, and the corresponding three digtit integer
grouping in the other text, a three digit integer 'offset' can easily
be generated, describing exactly how one can be transformed into the
other. When these three digit integers representing the offset
difference between the two texts are viewed as a long series of three
digit integers, one next to the other  without any intervening spaces,
they constitute one very long integer.
This very long integer is the key how any plaintext can be transformed
into any carrier text and back into the same plaintext.

When this integer is represented as an MPI, it is a relatively short
string, that if it could somehow be hidden within the carrier text,
it would allow for steganographic hiding of text within text, without
restriction on the length of the texts.

> But it looks to me that it's not only an algorithm for steganography
> but for encrypting, too.

yes,

an alternative to key-based encryption, and not dependent on the
(hopefully, very unlikely) possiblity of breaktroughs in the
underlying 'mathematical problems' basis of public key encryption
schemes.

the security depends only on the agreement of the initial carrier text,

{ideally, as random as possible, and changed after each message, with
the instructions for the next carrier text to be used, included in the
previous message,
also, if used for encryption, the carrier text should be longer than
the plain text, otherwise the end of the plaintext can easily be
reconstructed by an attacker just from the MPI, without knowing the
carrier text}

hope this is clearer,

vedaal


Sent via Deja.com
http://www.deja.com/

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

From: Arturo <[EMAIL PROTECTED]=NOSPAM>
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: In today paper I read how Cuban intelligence
Date: Thu, 21 Dec 2000 18:31:43 +0100

On Tue, 19 Dec 2000 19:01:28 GMT, [EMAIL PROTECTED] (Keith) wrote:

>On Tue, 19 Dec 2000 14:51:34 GMT, Markku J. Saarelainen 
> <[EMAIL PROTECTED]> wrote:

> "Where would Christianity be
>if Jesus got eight to fifteen years with time off for good behavior?" NY 
>State Senator James Donovan, speaking in support of capital punishment.

        IIRC, another senator replied:  "It was Jesus´ resurrection, not his
death, that started Christianity.  If Senator Donovan is able to include
resurrection into his bill, I´ll be glad to consider it seriously"

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

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Javascript Implementation of Block Cipher
Date: 21 Dec 2000 10:49:32 -0800

[EMAIL PROTECTED] writes:
> I need to implement a block cipher in Javascript for an application that
> sends sensisitive (ciphered) information by e-mail and a Javascript code
>  then decrypts the mail.
> 
> The problem is that Javascript is too slow and, because JS is sent by
> mail too, the code can't be too large.
> 
> What block cipher is the best choice?
> - Must be fast
> - Must be tiny
> - Must be secure
> 
> I thought in TEA, but i think it isn't too strong.

Why do you need a block cipher?  Implementing RC4 in javascript is
very easy.  I remember being able to encrypt/decrypt about 5k/second
in a Netscape browser on a 200 mhz Pentium.  That's pathetic compared
to any reasonable language, but should be good enough for decrypting a
typical email message, especially on a newer machine (500+ mhz pii/piii).

You could also consider using a java applet.  That would run a lot faster,
and just about every cipher you want has already been implemented in
java, including public key systems.

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: All irreducible polys of degree 32 over GF(2)
Date: Thu, 21 Dec 2000 12:42:46 -0600

Matt Timmermans wrote:
> 
> This is a good idea, but I have a problem with it that you might be able to
> help with -- I'm under the impression that all of the fast implementations
> of irreducible(p) are probabilistic, and I don't want the senders to have to
> do a whole bunch of trial divisions.  Are there fast and exact tests?

Yes, there are fast and exact ways to do it.  Here's an example:

/*  check to see if input polynomial is irreducible.
        Returns 1 if irreducible, 0 if not.

        This method explained by Richard Pinch.  The idea is to use
        gcd algorithm to test if x^2^r - x has input v as a factor
        for all r <= degree(v)/2.  If there is any common factor,
        then v is not irreducible.  This works because x^2^r - x
        contains all possible irreducible factors of degree r, and
        because we only need to find the smallest degree such factor
        if one exists.
*/

INDEX irreducible( v)
FIELD2N *v;
{
        FIELD2N         vprm, gcd, x2r, x2rx, temp;
        FIELD2N         sqr_x[NUMBITS+1];
        INDEX           i, r, deg_v, k;
                
/*  check that gcd(v, v') = 1.  If not, then v not irreducible.  */ 

        SUMLOOP(i) vprm.e[i] = (v->e[i] >> 1) & DERIVMASK;
        poly_gcd( v, &vprm, &gcd);
        if (gcd.e[NUMWORD] > 1) return(0);
        for (i=0; i<NUMWORD; i++)  if (gcd.e[i]) return(0);

/*  find maximum power we have to deal with  */

        deg_v = degreeof(v, NUMWORD);

/*  create a vector table of powers of x^2k mod v.
        this will be used to compute square of x^2^r
*/

        null (&sqr_x[0]);
        sqr_x[0].e[NUMWORD] = 1;
        for (i=1; i<= deg_v; i++)
        {
                mul_x_mod( &sqr_x[i-1], v, &temp);
                mul_x_mod( &temp, v, &sqr_x[i]);
        }

/*  check that gcd( x^2^r - x, v) == 1 for all r <= degreeof(v)/2.
        set x^2^r = x for r = 0 to initialize.
*/
        null( &x2r);
        x2r.e[NUMWORD] = 2;
        for ( r=1; r <= deg_v/2; r++)
        {
/*  square x^2^r mod v.  We do this by seeing that s^2(x) = s(x^2).
        for each bit j set in x^2^(r-1) add in x^2j mod v to find x^2^r.
*/
                null( &x2rx);
                for (i=0; i <= deg_v; i++)
                {
                        if ( x2r.e[NUMWORD - (i/WORDSIZE)] & ( 1L << (i%WORDSIZE) ))
                                SUMLOOP(k) x2rx.e[k] ^= sqr_x[i].e[k];
                }
                
/*  save new value of x^2^r mod v and compute x^2^r - x mod v */

                copy( &x2rx, &x2r);
                x2rx.e[NUMWORD] ^= 2;

/*  is gcd( x^2^r - x, v) == 1?  if not, exit with negative result  */

                poly_gcd( &x2rx, v, &gcd);
                if (gcd.e[NUMWORD] > 1) return (0);
                for (i=0; i<NUMWORD; i++) if ( gcd.e[i]) return (0);
        }

/*  passed all tests, provably irreducible  */

        return (1);
}

Patience, persistence, truth,
Dr. mike

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

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Diffie-Hellman Matrix Idea To Break
Date: 21 Dec 2000 19:05:45 GMT

In <[EMAIL PROTECTED]> Simon Best <[EMAIL PROTECTED]> writes:


]Hello!

]Having been considering matrix multiplication for cryptography recently
]('cause of another discussion in this newsgroup!), I wondered what's
]wrong with the following public key idea...

]Alice wants to send Bob another secret love letter.  Alice and Bob both
]have a square matrix, M, for such purposes.  Alice randomly picks a big
]number, a, and raises M to that power, to produce A:

]       A = M^a

]Bob does much the same thing, with a big number that he randomly picks,
]b, to produce B:

]       B = M^b

]Alice and Bob keep their big numbers, a and b, secret, and exchange A
]and B.  Then, Alice raises B to the power of a, and Bob raises A to the
]power of b.  Both produce the same matrix as a result, K:

]       K = B^a
]       K = A^b

]It's Diffie-Hellman, but with matrices.  How does the maths work?  It
]relies on the associativity of matrix multiplication:

]       XYZ = X(YZ) = (XY)Z

]Raising a matrix, X, to the power of a positive, nonzero integer, n, can
]be recursively defined as:

]       X^n = X(X^(n-1))        : For n > 1.
]       X^n = X                 : For n = 1.

]Suppose, for example, Alice chooses 5, and Bob chooses 3:

]       a = 5
]       A = M^a = M^5 = M(M^4) = M(M(M^3))= M(M(M(M^2))) = M(M(M(M(M)))))
]       A = MMMMM

]       b = 3
]       B = MMM

]       K = B^a = B^5 = BBBBB
]       K = (MMM)(MMM)(MMM)(MMM)(MMM)
]       K = MMMMMMMMMMMMMMM

]       K = A^b = A^3 = AAA
]       K = (MMMMM)(MMMMM)(MMMMM)
]       K = MMMMMMMMMMMMMMM

]K can then be used as the basis for some secret symmetric key scheme,
]like AES.

]For such a scheme to be secure, it would need to be computationally
]infeasible to get any of K, a, or b, from A, B, or both A and B.  (Of
]course, that's not the only requirement for it to be secure!)

]I would imagine such a scheme would have matrices over finite fields, or
]some such thing (something where addition and multiplication exist).

]I don't have the mathematical knowledge, understanding, etc, to know
]whether or not there's any point in doing Diffie-Hellman with matrices,
]or whether or not matrix logarithms would be computationally feasible,
]etc.  It just seemed an interesting idea...

Sure, Matrix logarithms are just like ordinary ones. In fact, Using S 
to diagonalise the matrix SMS^(-1) then all the multiplications are just
raising the diagonal elements to those powers.@

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


** 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