Cryptography-Digest Digest #372, Volume #12       Mon, 7 Aug 00 08:13:01 EDT

Contents:
  Re: asymmetric encryption for my keycode generator (Bob Deblier)
  Re: asymmetric encryption for my keycode generator ("eboy")
  Re: asymmetric encryption for my keycode generator ("eboy")
  Re: Note on text compression (Mok-Kong Shen)
  Re: Functions that are slow to invert (Mok-Kong Shen)
  Re: OTP using BBS generator? (Mok-Kong Shen)
  Re: Let us have Lattice (Mok-Kong Shen)
  Re: A non-linear extension of the Hill cipher (Mok-Kong Shen)
  Re: Secure Operating Systems (Mok-Kong Shen)
  Re: New William Friedman Crypto Patent (filed in 1933) (Mok-Kong Shen)
  Re: OTP using BBS generator? (Mok-Kong Shen)
  Re: New William Friedman Crypto Patent (filed in 1933) (Mok-Kong Shen)
  Discret Logarithm ([EMAIL PROTECTED])
  Re: Public-domain Blowfish (Runu Knips)
  Re: Hashing Algorithms (Runu Knips)
  SSL in IIS, NES ("jerry")
  Looking for a *different* type of cipher... (RavingCow)
  Re: Coupon collector's problem ("Artemios G. Voyiatzis")
  Re: Coupon collector's problem ("Artemios G. Voyiatzis")
  Re: Let us have Lattice (Tim Tyler)

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

From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: asymmetric encryption for my keycode generator
Date: Mon, 07 Aug 2000 09:01:42 +0200

eboy wrote:

> I'm a budding shareware author who'd like to code my registration
> keycode generator to use asymmetric encryption (like RSA, with private
> and public keys, but not necessary RSA per se). I figure I shouldn't
> have to worry about keycode generators popping up on cracker sites
> within months of release of my product if I can implement this. One
> shareware FAQ said doing this wasn't that hard a thing to do. (?)
> Anyway, while I know a little about the math theory behind this
> encryption, programming it is in another ballpark from where I'm
> playing. Can anyone point me to some reference that would be helpful for
> a non-math-genius, non-super-geek programmer to accomplish this? (I have
> PGP's source code - there isn't enough time in the universe for someone
> like me to decipher it) (without help).
>
> I guess what I'm looking for is a basic programming algorithm (perhaps
> in pseudocode to just illustrate each step) for encoding and decoding
> some plain text using the primes, plus some details about how to
> generate the monster primes themselves. I was thinking I could just use
> PGP to generate a couple of 2048 bit primes and use those but I can't
> find a way to get PGP to tell me what *both* primes are when it
> generates a public and private key pair for me. If anyone can guide me
> just in this, it would still be a big help...
>
> thanks,
> ed

Maybe you can fiddle around a bit with the BeeCrypt cryptography library.
It should be easy to build applications with it, it's lightweight (unlike
PGP) and it has plenty of the low level primitives for asymmetric
encryption - but no RSA though. The documentation is at this time not
completed, but the code contains some pointers.

Have a peek at the code (you can download it through
http://beecrypt.virtualunlimited.com/) and if you have any questions, feel
free to contact me through [EMAIL PROTECTED]

Sincerely

Bob Deblier
Virtual Unlimited


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

From: "eboy" <[EMAIL PROTECTED]>
Subject: Re: asymmetric encryption for my keycode generator
Date: Mon, 7 Aug 2000 00:41:01 -0700

> >> Well if you want to be lame like this just take a hash,
> >> modify it slightly.  It will still be attackable but will
> >> put attackers at bay for a day or two.
> >>
> >> Tom
----
> >
> >Huh? I'm being lame for wanting to use asymmetric encryption?
> >
> >If you would have me doing something that was NOT lame, what
> >exactly would you have me doing, Tom?
> >
> >ed
----
> If your program is truly usefull people will buy it out of
> respect not because you thwart them with some stupid copy
> protection.
>
> Be mindful of who you are trying to sell it to and I wish you
> the best of luck.
>
> Tom

Oh. You mean I was being lame simply for wanting to use a good software
protection. You're saying if I had a good, useful program to offer, I
wouldn't need any software protection at all because people wouldn't
think of stealing my program if it was truly good enough to generate the
proper "respect" in my users. So really, ALL software protection is lame
("stupid") by its very intent: crypto should only be used to ensure free
speech and keeping out of big brother's eye.

Well, OK. Maybe so. I do agree with you about the respect part. The few
software programs I've registered I've done so ONLY because I had real
respect for the quality of the programming effort that obviously went
into it (labor of love). I don't really know, just starting out in this
business, how much a bite out of revenues not having good protection can
cost a shareware author, but browsing shareware newsgroups would suggest
that it can be a big problem. So I wanted to just get a scheme in place
for me that was good and then I wouldn't have to think about it again
and could devote my full time to working on my applications and not on
their protection schemes.

thanks for your input.
ed




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

From: "eboy" <[EMAIL PROTECTED]>
Subject: Re: asymmetric encryption for my keycode generator
Date: Mon, 7 Aug 2000 01:22:43 -0700

> Maybe you can fiddle around a bit with the BeeCrypt cryptography
library.
> It should be easy to build applications with it, it's lightweight
(unlike
> PGP) and it has plenty of the low level primitives for asymmetric
> encryption - but no RSA though. The documentation is at this time not
> completed, but the code contains some pointers.
>
> Have a peek at the code (you can download it through
> http://beecrypt.virtualunlimited.com/) and if you have any questions,
feel
> free to contact me through [EMAIL PROTECTED]
>
> Sincerely
>
> Bob Deblier
> Virtual Unlimited

Thanks BD. I've downloaded beecrypt, and also something called Crypto++,
a C++ Class Library of cryptographic primitives. Now as soon as I learn
C I'll be on my way! Sigh.

ed




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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Note on text compression
Date: Mon, 07 Aug 2000 11:53:45 +0200



tomstd wrote:
> 
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:

> >I suppose one could consider doing the following which may be
> >beneficial as a pre-processing step for compression schemes that
> >use the Huffman algorithm.
> >
> >Complile a list of 128 most common words. Let these, including
> >the accompanying space at end of words, be coded into 7 bits
> >to be prefixed by a leading bit of '1' to form a byte. Let
> >everything not coded this way be as usual.
> 
> You would be better served using 128 common trigrams and digrams
> instead of whole words.  The world "there" could be encoded
> as "the" and "re"...
> 
> However, you won't be able to edit the file in text editors
> without decoding it first...
> 
> So... You might as well compress the file normally...

Well, the coding and decoding is the price that one has to pay
in the proposed scheme. The question is whether one can better 
compress the file with the coding (preprocessing) as described
and in addition be economically justifiable. As John Savard
commented, one needs to compare with LZW. My thought in writing
the original article was that, if one uses Huffman (perhaps
because it is more straightforward to implement), then this
simple preprocessing probably could help somewhat.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Functions that are slow to invert
Date: Mon, 07 Aug 2000 11:53:50 +0200



Scott Fluhrer wrote:
> 

> Another possibility would be to pick a random N bit key, and encrypt the
> argument with it, along with enough redundancy so that the solver can
> recognize the correct key.  As long as you use a cipher which has brute
> force as the strongest attack, this appears to meet your criteria.
> 
> BTW: what's this for?

Would you please elaborate the phrase 'along with enough redundancy 
so that the solver can recognize the correct key'?

If one uses a function that has fairly asymetrical computation 
times in inversion in a cipher, then one could cause the decryption
to be rather long while optimizing the encryption phase, which 
translates to higher work for the opponent if he brute force. A 
fancy use I could think of is that one wants to tell someone 
something but the recipient should not learn the message
immediately but at some delayed period.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 07 Aug 2000 11:53:18 +0200



Terry Ritter wrote:
> 
> It is particularly interesting to see a cryptographic proof of
> strength carry hidden assumptions which prevent even mathematicians --
> to say nothing of the rest of us -- from seeing that those assumptions
> may not be met in a real design.  The implications for blind belief in
> mathematical assurance should be obvious.

Not infrequently proofs are based on yet unproved number theoretical
conjectures. These might indeed all be true, see e.g. the example of
FLT, which has been proved after a time lag of three centuries. But 
one should anyway keep in mind of the nature of the foundation on 
which the proofs are built, if one really wants to rigorously talk 
about theoretically perfect security (instead of 'practical' 
security), I believe.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Let us have Lattice
Date: Mon, 07 Aug 2000 11:52:50 +0200



wtshaw wrote:
> 
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> >
> > I conjecture that in one situation concatenation of linear
> > transformations could be practically useful, namely when these
> > are applied to different block sizes that are relatively prime.
> > What do you think? Thanks.

> 
> That is an interesting thought, as low primes were disgraced in my recent
> recursion study.  Already I know that multiple sized stream cipher seeds
> work to give disproportionate good results.  Since Sinnet demands odd
> group sizes, are prime odd group sizes meaningful?

I am yet ignorant of what your 'recursion' and 'Sinnet' exactly
are. My thought that concatenations of two linear transformations
could be useful when the block size are different is based on 
the idea that the result would be a bigger transformation and
hence better. Evidently, it is most effective to achieve this
'bigness' when the two block sizes are relatively prime. So, even
without knowledge of what you are exactly doing (perhaps you
would explain that to us in detail later), I would suggest using
relatively prime sizes (not necessarily prime sizes).

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A non-linear extension of the Hill cipher
Date: Mon, 07 Aug 2000 11:53:10 +0200



Benjamin Goldberg wrote:
> 
> Mok-Kong Shen wrote:
> > Benjamin Goldberg wrote:
> > > Some of what you are describing sounds very like Mark Wooding's
> > > "Storin" cipher.  Enciphering is as follows:
> > >
> > > X[i], Y[i], Z[i] = intermediate values.
> > > K[i] : Round keys.
> > > Ma : a 4x4 matrix, invertable under integers mod 2**24
> > > Mb : the inverse of Ma; used for decryption
> > >
> > > Z[-1] = Plaintext, split into a vector of 4 24-bit values.
> > >
> > > For i = 0 to 7
> > >         X[i] = Z[i-1] XOR K[i]
> > >         Y[i] = (X[i] * Ma) MOD (2**24)
> > >         For j = 0 to 3
> > >                 Z[i][j] = Y[i][j] XOR (Y[i][j] >> 12)
> > >         end For j
> > > End for i
> > >
> > > Ciphertext = Z[7] XOR K[8]
> >
> > K is used as whitening and can be excluded from the present
> > discussion. The computation of Y is the orginal Hill cipher
> > step.
> 
> K is expanded from the key.  Ma and Mb are fixed and known.
> 
> > Then Z is computed from Y as given above, i.e. post-
> > processing of the output from Hill.
> 
> The calculation of Z is non-linear.  The matrix transformation, by
> itself, is linear.
> 
> > I am not sure that there is a 'very like-ness' that you indicated,
> > excepting of course the Hill cipher step. Could you please elaborate a
> > little bit?
 
> Umm, well, I'm not sure about 'very' like, myself.  'Sorta' like, maybe?

My proposal extends the Hill cipher by replacing the linear 
transformation with a non-linear one. One can certainly keep
the original (linear) Hill cipher and follow that with an
arbitrary non-linear transformation and thus as a whole
achieve certain non-linearity. But that wouldn't be an 'extension'
of the Hill cipher itself any more, it's rather a concatenation 
of two different processing steps.

BTW, for Hill matrices I'll recommend using pseudo-random ones,
i.e. not constant ones, if possible (economically justifiable).

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Secure Operating Systems
Date: Mon, 07 Aug 2000 11:53:39 +0200



Eric Lee Green wrote:
> 
> Mok-Kong Shen wrote:
> > > Actually the original unix was derived from the disenchantment with of multics
> > > which was supposed to be a secure OS in addition to all things to all people.
> >
> > Could you give a reference to that fact? Thanks.
> 
> Dennis Ritchie's web site http://www.cs.bell-labs.com/who/dmr/
> 
> The problem with Multics, as explained by DMR, was not that Multics was
> secure. The problem was that Multics was slow, bloated, and
> uneconomical, and was not released as an actual commercial product until

[snip]

I suppose you mean the article 'The Evolution of the Unix Time-
sharing System' there. I quickly looked over it but failed to
see any statement that security was one of the design criteria
of UNIX. In fact, as far as I am aware, the original UNIX attempted 
to achieve efficiency through simplicity (throwing away the 
complexities of Multics due to security concerns). UNIX was 
orignially for use in a laboratory environment of that time, if I 
don't err. In that (rather isolated) environment no security issues 
as we currently fear needed be considered. It would actually also 
be very difficult to implement a secure OS on a small machine like 
the PDP-7, I guess.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Mon, 07 Aug 2000 11:53:04 +0200



Terry Ritter wrote:
> 

>    http://www.io.com/~ritter/GLOSSARY.HTM#PriorArt
> 
> 'Prior Art
>       In patents, the knowledge published or otherwise available to
> the public as of some date.  Traditionally, this "knowledge" is in
> ink-on-paper articles or patents, both of which have provable release
> dates.  Private "in house" journals available only within a company
> generally would not be prior art, nor would information which has been
> kept secret.  Normally, we expect prior art information to be
> available in a public library.'

I was told that in Europe an inventor must be very careful not 
to reveal his stuff in a public lecture or else he risks to have
his idea to be regarded as available in the public domain and 
therefore not patentable by himself.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 07 Aug 2000 11:53:33 +0200



Terry Ritter wrote:
> 

> I suppose that one of the issues here might be the use of asymptotic
> proofs of strength, or statistical proofs of strength, to incorrectly
> imply strength in every case.  Perhaps a statistical proof can just
> mean *most* cases, which may mean that some cases which fit under the
> guarantee are not really secure.  That would be an interesting
> definition of "proven strength."

Maybe I am entirely misled by my poor knowledge and low IQ. But 
I have the impression that, excepting OTP, most cases of 'proven 
strength' seem to be just that.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Mon, 07 Aug 2000 11:52:58 +0200



Bill Unruh wrote:
> 
> It would be an interesting court case, if a secret filing could actually
> be considered "prior art". Eg, if a company holds a trade secret, and
> some other company patents it, can that trade secret invalidate the
> patent?

But the patent office apparently could delay processing your
application, say, for 67 years.

M. K. Shen

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

From: [EMAIL PROTECTED]
Subject: Discret Logarithm
Date: Mon, 07 Aug 2000 09:37:56 GMT

Generalised Discret Logarithm Problem

Given a finite cyclic group G of the order n, a generator a of G,
and an element b of G find an integer x, 0 =< x =< n-1, such that
 a^x = b.
Proposed solution can be found at

www.alex-encryption.de

Regards.
Alex.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Date: Mon, 07 Aug 2000 11:46:32 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Public-domain Blowfish

Neil Weicher wrote:
> Is Blowfish still a reasonably secure algorithm?
> Is it the "state of the art" in freely usable, symetric algorithms? 

It is extremely secure. The only problem are weak keys, and
that it has only 64 Bit Blocks which is a little bit small.
And it is a PC cipher only, i.e. you can't implement it on
low end architectures or in hardware chips.

> If not, are better ones available?

Serpent and Twofish are also available. Both are AFAIK not
as fast as Blowfish, but work with 128 Bit Blocks instead,
have no weak key problems and can be implemented with low
resources or in hardware.

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

Date: Mon, 07 Aug 2000 11:58:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Hashing Algorithms

George wrote:
> I have done some research on hashing algorithms, and I have been told that the
> best hashing algorithms are MD5 and SHA. 
> Am I outdated again with my resources?

Yep. MD5 isn't considered secure anymore. Don't use it.

> What is the most "secure" hashing algorithm available to the public today?

SHA1, RIPE MD160, and Tiger.

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

From: "jerry" <[EMAIL PROTECTED]>
Subject: SSL in IIS, NES
Date: Mon, 7 Aug 2000 19:46:28 +0900

I saw MS IIS(Internet Information Server) Security in MS Site.
But I cannot find key length about SSL in IIS(export version).
Does IIS(export version) use 128-bit symmetric encryption algorithm in SSL?
How about a exportable NES(Netscape Enterprise Server)?

Any help will be appreciated.





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

From: RavingCow <[EMAIL PROTECTED]>
Subject: Looking for a *different* type of cipher...
Date: Mon, 07 Aug 2000 20:34:13 +1000

Hi -

I was just wondering if anyone out there knew of a type of cipher which
given plaintext and a positive integer n, could form cipher text in
constant time, taking n steps to decode back into plaintext. For
example:

ciphertext = encode(plaintext, n)      --- O(1)
plaintext = decode(ciphertext, n)      --- O(n)

Some ideas I have already come up with is to encode the plaintext using
a standard cipher multiple times, each time using 1 of n known keys.

For example, given the functions:

RC4(inputText, key)             which returns encrypts/decrypts input
                                with the given key
IsKeyCorrect(inputText, key)    which returns true if the given key 
                                is correct (to unencrypt) for the given
                                inputText

encode:
        lastText = plainText
        for i = 1 to SOME_NUMBER
                lastText = RC4(lastText, knownKey[random * n * 2])
        next i
        cipherText = lastText
        
decode:
        lastText = cipherText
        for i = 1 to SOME_NUMBER
                for j = 0 to n * 2
                        if IsKeyCorrect(lastText, knownKey[j]) then
                                lastText = RC4(lastText, knownkey[j])
                                goto break
                        end if
                        break:
                next j
        next i
        plainText = lastText


While this works though, I personally have never liked the random
function in my code, and I am sure that there must be a better
(and more deterministic) way of doing this. I, unfortunally, can
also see this as being extreamly obvious, but I am putting this
call out for help any way.                              

Thanks in advanced,

--RavingCow

-- 
---
"When all else fails, throw another megavolt over it."
RavingCow
---
[EMAIL PROTECTED]
PGP: 33D2 A90C D908 2607 0C91 4316 2E39 81AA


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

From: "Artemios G. Voyiatzis" <[EMAIL PROTECTED]>
Subject: Re: Coupon collector's problem
Date: Mon, 7 Aug 2000 14:38:15 +0300

Thanks for the reply, but I am interested in proving this formula,
not using it (well, I do use it, but I need a proof). I already
read Knuth, but it didn't provide the proof - maybe it's too obvious :-)

--
Artemios G. Voyiatzis

"Think negative"
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Artemios G. Voyiatzis" wrote:
> > I have seen in many crypto-related publishings the "coupon
> > collector's problem" and I am trying to find a resource (preferably
> > URL) of its proof.
>
> Knuth TAOCP 3.3.2.E has the exact formula, from which you can
> derive approximations using Stirling's formula etc.



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

From: "Artemios G. Voyiatzis" <[EMAIL PROTECTED]>
Subject: Re: Coupon collector's problem
Date: Mon, 7 Aug 2000 14:38:42 +0300

Thanks for the reply, but I am interested in proving this formula,
not using it (well, I do use it, but I need a proof). I already
read Knuth, but it didn't provide the proof - maybe it's too obvious :-)

--
Artemios G. Voyiatzis
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> "Artemios G. Voyiatzis" wrote:
> >
>
> > I have seen in many crypto-related publishings the "coupon collector's
> > problem" and I am trying to find a resource (preferably URL) of its
proof.
> > Could you help me?
>
> See Knuth, vol. 2.
>
> M. K. Shen



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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Let us have Lattice
Reply-To: [EMAIL PROTECTED]
Date: Mon, 7 Aug 2000 11:55:32 GMT

Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:

:> What would be the point of piling linear components on top of one another?
:> 
:> Also, the idea that more rounds of this treatment would produce strength
:> seems mistaken. Even a million rounds of this will not produce anything
:> other than a linear transformation.

: I conjecture that in one situation concatenation of linear 
: transformations could be practically useful, namely when these 
: are applied to different block sizes that are relatively prime.
: What do you think? [...]

With a linear transformation each bit in the resulting cyphertext block is
a linear function of the bits in the corresponding plaintext block, and
the bits in the key.

Use of varying block sizes in transformations piled on top of one
another serves to increase the area of the plaintext which needs to
be considered in each transformation.

Also, instead of the same transformation being appiled to each block,
different transformations will be applied in different areas of the text.
The transformations will start to repeat when about p1*p2*...*pn bits
have been processed.

I believe there are still likely to be severe attacks when the sizes of
the blocks, and the number of transformations applied are known in
advance - though these aren't as simple as the straightforward linear
algebra that will normally break a linear system, though.

If the block size/number of passes are key-dependent, than I can't
immediately think where to attack - but this may well be a reflection
of my own ignorance rather than implying that the construct is strong.
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Namaste.

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


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

Reply via email to