Cryptography-Digest Digest #231, Volume #11       Wed, 1 Mar 00 21:13:01 EST

Contents:
  Re: very tiny algorithm - any better than XOR? (John Myre)
  Re: Crypto.Com, Inc. ("Trevor Jackson, III")
  Re: Best language for encryption?? ("Trevor Jackson, III")
  Re: And this is me actually ... ("Trevor Jackson, III")
  Re: Crypto.Com, Inc. (wtshaw)
  Re: brute force attack on a 128 bit SSL key? ("Randy Given")
  Visual C++ Decompiling Service/Software Needed (ECN UltraTrader)
  Re: Ciphering = deciphering; is this a weakness? (Bryan Olson)
  Microcontroller Cipher (Gary)
  Re: Passwords secure against dictionary attacks? (Johnny Bravo)
  Plain-text attack on ZIP file ("Graeme Elliott")
  Re: Can someone break this cipher? (Tim Tyler)
  Re: Best language for encryption?? (lordcow77)
  Re: Passwords secure against dictionary attacks? (jungle)
  Re: Ciphering = deciphering; is this a weakness? (David A. Wagner)
  Re: First contact, establishing password without public keys (drickel)
  Re: Crypto.Com, Inc. (Xcott Craver)
  Re: Microcontroller Cipher (David A. Wagner)
  Re: ...but what about my cipher? (David A. Wagner)
  Re: Visual C++ Decompiling Service/Software Needed ([EMAIL PROTECTED])

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: very tiny algorithm - any better than XOR?
Date: Wed, 01 Mar 2000 16:15:54 -0700

Terje Mathisen wrote:
> 
<snip>
> I guess I'd have to look at the available machine instructions to figure
> out if you could have some way to get better mixing by working across
> larger blocks.
> 
> I assume speed is non-critical here?

The traditional Feistal structure uses two halves, invertably modifying
one half using the other half.  Extending this to more subblocks, doing
the modification in a circular pattern, seems straightforward.  Can you
get good security if you use enough rounds?

That is, we define

encrypt (word8 *k, word8 *v)
{
   int i, j;
   for( j = 0; j < ROUNDS; j++ )
      for( i = 0; i < 8; i++ )
         v [(i+1)&7] ^= F( v[i], i, j, KS(k,i,j) );
}

where F is the Feistal function, and KS is the key schedule;
decrypt is the same, except for running the loops backwards.

A simple KS might be

#define KS(k,i,j)  k[(i+j)&15]

An F() similar to the one originally proposed might be

#define FBOX(w,i,j,sk)  rotate_left(w+j+sk)

The resulting code isn't *too* much larger, I don't think.  Then we
just set ROUNDS as large as we can afford, say 40.

Comments, anyone?

John M.

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

Date: Wed, 01 Mar 2000 18:44:19 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.

David A Molnar wrote:

> John Savard <[EMAIL PROTECTED]> wrote:
> > It may also be noted that there already does exist a "technology"
> > which provides for _reasonable_ security "on open circuits between two
> > users without the use of a" previously-arranged key...public-key
> > cryptography.
>
> yes, but the quote said "unbreakable." This implies info-theoretic
> security at best, and cluelessness at worst.

Can you break something already broken?  Perhaps they meant unbreakable in
this sense.  ;-)



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

Date: Wed, 01 Mar 2000 18:52:05 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??

wtshaw wrote:

> In article <89ihfs$3m7$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
> Schlyter) wrote:
>
> > In article <1SYu4.12$[EMAIL PROTECTED]>,
> > Adam Durana <[EMAIL PROTECTED]> wrote:
> >
> > > BASIC is great for learning structured programming,
> >
> > :-) ... no, it's indeed not!  But it's great for learning
> > spagetti programming....
> >
> Basic allows that like Fortran as it is very forgiving, but you do not
> need it.  I notice that C does not easly allow goto's to be as effective
> as they would be in Basic.  I see that as a weakness of C, not a
> strength.

How does one measure the effectiveness of a goto?  Whatever the units are, I
suspect that between signal() and longjump() C can probably match it.




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

Date: Wed, 01 Mar 2000 18:56:38 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.politics.org.cia,soc.culture.russian,soc.culture.nordic,soc.culture.europe,soc.culture.ukrainian,soc.culture.china
Subject: Re: And this is me actually ...

"Markku J. Saarelainen" wrote:

>   ------------------------------------------------------------------------
>  [Image]  [Image]

If you keep this up people will start complaining to your service provider.
Being silenced can be the effect of enemy action or your own rudeness.  Which
do you think this will be?



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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Crypto.Com, Inc.
Date: Wed, 01 Mar 2000 17:02:14 -0600

In article <89k433$kgr$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Xcott Craver) wrote:

> wtshaw <[EMAIL PROTECTED]> wrote:
> >> 
> >Shannon was functionally wrong, but lots of what he said is of great
> >importance.  The error was not in what he understood, OTP, but in that it
> >was too simple to say that it is the only choice. This means he did not
> >know or allow for development that might solved the problem, scientific
> >allowance that he should have respected.
> 
>         Can you be more specific about this alleged mistake?  Where he
>         said a wrong thing and what, specifically was wrong?  I.e., did he 
>         really say that a specific OTP was the only choice to obtain perfect
>         secrecy?
>         
>         I thought he had only said that perfect secrecy requires at least
>         as many bits of key as there are bits of message, and that key 
>         data can not be reused.  This much is perfectly true, and very
>         easy to prove.  No buts about the fact that you must meet these
>         requirements in order to possess the propoerty that P(p|c)=P(p)
>         [p=plaintext,c=ciphertext]
> 
>         Also, most people use the phrase "one-time pad" to mean any 
>         cryptosystem whose keydata is never reused, and as large as
>         the plaintext; rather than any specific implementation involving
>         XOR or addition mod 26 or 256 or etc.  Under this convention, any
>         system meeting the definition of perfect secrecy is, by 
>         definition, a one-time pad.

Well, you did much the same worn thing, saying that perfect secrecy
implies a one-time pad.  Since a OTP is a poor cipher due to awkward key
structure, it does not guaratee perfect security by itself, but just about
guarantees its own insecurity. If you deal with cryptographic algorithms
in a vacuum, that is not the real world.

What Shannon did say that was good was that you can judge some aspect of
security with how much ciphertext you must have to solve for the keys
unambigiously.  That is a measure of strength which can be exploited, and
can lead to evaluate ciphers which are practical and extremely strong,
some other factors also being important.

The way to good security involves playing a chance game in which the odds
are in your favor to the extent that an attacker deems it not practical to
attack, and does not require an endless stream of key material like an OTP
would.
-- 
Bush would drop the MS suit if elected because since he is FOR 
fraud, abuse, privacy invasion, squashing the little guy if he gets 
in the way. Obviously, he is consistently NOT for compassion.

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

From: "Randy Given" <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Wed, 1 Mar 2000 14:27:07 -0500
Reply-To: "Randy Given" <[EMAIL PROTECTED]>

> Assume the following:

That's the problem.  You remember what
"assume" represents, right?

For example, wasn't it 30 years ago that
some "expert" said it would take 40 quadrillion
years (40,000,000,000,000,000 years) to break
DES.  Hmmm.  Was he right?  I don't think so.

There are many things to account for.  You mention
Moore's law.  You don't mention breakthrough
technologies nor breakthrough algorithms and
certainly did not mention possible flaws in the
algorithms.



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

From: [EMAIL PROTECTED] (ECN UltraTrader)
Subject: Visual C++ Decompiling Service/Software Needed
Date: 02 Mar 2000 00:18:49 GMT

Hi,

I am engineering a software program that analyzes the stock market. I have
found a few interesting programs similar to it that include interesting
theories and functions. I need to know if it is possible to obtain their source
code by decompiling them. I need to obtain their source code one way or
another, any suggestions are greatly appreciated!

Thank you! 

(please respond through email)


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

From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Ciphering = deciphering; is this a weakness?
Date: Thu, 02 Mar 2000 00:10:46 GMT

[EMAIL PROTECTED] wrote:

> Mathematically speaking such ciphers are permutations
> composed of cycles consistently with a length of two.

Actually one-cycles are also allowed.

> You get the number of such permutations (of blocks of
> bit length n) by dividing the total number of
> permutations (of blocks of bit length n) by 2**(n/2).

Hmmm, that's not what I get.  The question has come up
before; see the thread "Algorithms where
encryption=decryption?" from April 1999.  I'll use
upper-case N for the number of blocks, so N = 2^n.  Then
the number of permutations composed entirely of 2-cycles
is:

    N! / ((N/2)! * 2^(N/2))

This is the same as the product of all odd integers between
1 and N.  It looks to be a little less than square root of
N!, and thus the theoretical maximum key size would be cut
in half.

> This does not diminish the cardinality of the set of
> theretically possible ciphers as much as a halving of
> the block size would.

Right, since maximal key-size increases much faster
than block size.

The theoretical maximum keyspace is not really an issue,
since for typical block sizes we cannot construct keys that
large.


--Bryan

--
email: bolson at certicom dot com


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

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

From: Gary <[EMAIL PROTECTED]>
Subject: Microcontroller Cipher
Date: Wed, 1 Mar 2000 19:27:46 -0500

Microcontroller Cipher.

I'm using an 8 bit microcontroller and am implementing the following simple 
variation of a Feistel cipher.
Let the 128 bit key K have bits k0,k1,k2,....,k127.
I have a block of memory 16 bytes long. I split this into 2 halves, 8 bytes 
each.

To Encrypt:
If k0 is set I XOR the second half to the first, otherwise if k0 is clear I 
ADD the second to the first.
If k1 is set I XOR the first half to the second, otherwise if k1 is clear I 
ADD the first to the second.
and so on... for 64 rounds.
Note:Adds are carried across the whole of the 8 bytes (64 bit ADD).

To Decrypt:
I reverse the operations using SUB (borrows to 64 bit) and XOR.

Is this obviously insecure?

[EMAIL PROTECTED]


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

From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Wed, 01 Mar 2000 19:30:40 +0000

On 01 Mar 2000 14:55:08 -0800, Wally Whacker
<[EMAIL PROTECTED]> wrote:

>Be careful. I think jungle must have one of those little boxes you see
>in the movies that show the "partial" progress of the brute force
>attack by revealing the key sequence number by number.

  LOL.

  Gotta watch out for that black box technology.

-- 
  Best Wishes,
    Johnny Bravo

"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL

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

From: "Graeme Elliott" <[EMAIL PROTECTED]>
Subject: Plain-text attack on ZIP file
Date: Thu, 2 Mar 2000 00:16:53 -0000

I am trying a plain-text attack on a zip file using pkcrack and AZPR using a
fragment of plaintext that exists in encrypted form inside the archive. I
have followed the guidelines precisely by compressing the plaintext with the
same software and same settings as the encryted file. However when I try to
decrypt the file using the above software, it always fails by not finding
any keys.
If I do the above but dont compress the zip or the plaintext then I get the
correct keys in a matter of minutes.
Why is the compression messing it up (or is it just me?)
Any ideas?



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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 2 Mar 2000 00:40:38 GMT

Mary - Jayne <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Mary - Jayne) wrote:

:>http://www.xarabungha.btinternet.co.uk/xicrypt/xichallenge.htm

: OK guys.  I have succumbed to persuasion and posted some details of the
: encryption method on the web page (of which the address above is now
: correct).

All I can see along these lines is:

``The original plaintext was encrypted using traditional cryptological
  methods. These include polyalphabetic encryption, randomised
  cipher alphabets, and transformation; the whole process requiring two
  keys to complete (or reverse).''

Not terribly specific.

It *says* ``with method clues added 01-03-2000'' - but of them there's no
sign - did they really get uploaded?
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

Telepath wanted.  You know where to apply.

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

Subject: Re: Best language for encryption??
From: lordcow77 <[EMAIL PROTECTED]>
Date: Wed, 01 Mar 2000 17:16:11 -0800

In BASIC, I believe that goto can transfer control to arbitrary
parts of the code (which is not much of a problem..."Functions?
What functions? Execution contexts? Threads? External linkage?
What's that?"), whereas in C, the goto can only go to a label in
the same block or function.


* 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: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passwords secure against dictionary attacks?
Date: Thu, 02 Mar 2000 01:35:04 GMT

explanation in the text & at the bottom ...

Johnny Bravo wrote:
> 
> On Wed, 01 Mar 2000 02:40:36 GMT, jungle <[EMAIL PROTECTED]> wrote:
> 
> >> Our computer centre suggest choosing a phrase an using every first
> >> (or second, or last or whatever) character for the password. For
> >> example: My grandma takes 5 glasses of whine per evening = Mgt5gowpe,
> >> who could guess that password?
> >
> >it will be cracked in less than a second by brut force attack ...
> >the key space for it is 360 k of possible permutations ...
> >again, in less than 1 second ...
> 
>   Care to offer the math behind that guess?  I count roughly 50 bits of
> password, would take roughly an hour on a $250,000 dedicated machine.

all is OK, you are right, I created small mouse trap ...
the search key space for above brute force is :
9 char = 2^45 = 3.5 x 10^13 possible keys when all 256 char can be use [ 2^8 ]
practically it is much less because only about 70 char are in use and not 256
char

>   Then again, what would you know, you claimed that a 4 character password
> has a keyspace of 10^30.

my assumption was 4 random char for each word in pass text, instead 2 char for
each word as he proposed

he proposed pass text to be 10 words long :
10 words x 4 char each = 40 char long pass text [ random ]

for this 40 char long pass text the brut force search key space is 
70P40 = 4.5 x 10^67

it is equivalent to key space of symmetric encryption of 222 bits = 
impossible to brute force NOW & in the near future

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Ciphering = deciphering; is this a weakness?
Date: 1 Mar 2000 17:09:15 -0800

In article <89ir3u$rhb$[EMAIL PROTECTED]>,
Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
> so if this is the only weakness I will design
> the cipher with involution property.

It's not the only weakness.  Did you miss the post mentioning OFB mode?

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

Subject: Re: First contact, establishing password without public keys
From: drickel <[EMAIL PROTECTED]>
Date: Wed, 01 Mar 2000 17:48:46 -0800

In article <89k38j$c9g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
>In <[EMAIL PROTECTED]> Ken Savage <[EMAIL PROTECTED]>
writes:
>>away with this.  Alice can relatively easily find a pair of
strings
>>whose partial-MD5 is mmmmmmmm, but Eve would have to try out
many
>>many strings to find even ONE string whose MD5 is mmmmmm, yet
alone
>>a pair of them.
>
>No. It is as hard for Alice to find a second string as it is for
Eve to
>find one string. That is precisely the point of those
cryptographic
>hashes. It is supposed to be very difficult to find a collision
even if
>the original is known.

I think the original poster was trying to build a way for Bob to
pass Alice Bob's password without Eve (sitting in the middle)
being able to grab it.

If i'm following properly, Alice has posted on her web site a
function f (the original post was CRC31 or something, but that
has been shot down), and b and c pairs such that f(a,b) = c.
It's not hard to come up with such an f--Blowfish(message,key)=
cyphertext, where Alice publishes message and cyphertext seems
like it should do.

Bob goes to the web site, calls someone he thinks is Alice,
plucks a couple of b's and c's from the list, and asks Alice for
the associated a's.  Bob can then verify that he is talking
(possibly indirectly--Eve could be in the middle) with Alice
without using a public key.

But i don't see where Bob goes from here.  It's easy if there is
an asymmetric function on Alice's web page, but i thought the
point of this was to try to avoid asymmetric functions.


david rickel


* 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] (Xcott Craver)
Subject: Re: Crypto.Com, Inc.
Date: 2 Mar 2000 01:39:07 GMT

wtshaw <[EMAIL PROTECTED]> wrote:
>
>Well, you did much the same worn thing, saying that perfect secrecy
>implies a one-time pad.  

        No, I said perfect secrecy _requires_ a one-time pad.  Provably true.
        Clearly implementation issues can prevent this requirement from being
        met in real life, making real OTPs a bad choice except in certain 
        situations.  This doesn't make the statement incorrect, though.

        That's like saying 1+1=2 is incorrect because acquiring _exactly_
        one gallon of water and one gallon of water to add together, down
        to the last molecule, is a practically impossible, or at least a 
        logistical nightmare.  This neither invalidates the theory nor
        implies uselessness.
        
        Again, if you want to meet the definition of perfect secrecy,
        you _must_ have as much key information as plaintext information,
        and you can't reuse keydata.  There is no way around this.  Other, 
        real-world systems can be effectively unbreakable, given certain 
        computational assumptions, but they can not claim "perfect secrecy" 
        if they don't meet the keyspace requirements.

>Since a OTP is a poor cipher due to awkward key
>structure, it does not guaratee perfect security by itself, but just about
>guarantees its own insecurity. If you deal with cryptographic algorithms
>in a vacuum, that is not the real world.

        First of all, this was part of the point of his work.  He _showed_
        that the theoretical upper bound of cipher security could not
        be met without a cipher with unrealistic properties.  If you
        accuse Shannon of ignoring practical considerations, then you
        miss the point.  Indeed, you wouldn't be able to write the above 
        paragraph without his work on the subject.  You're practically
        echoing him.

        Secondly, _all_ theory to some extent must be done in a vacuum.  
        If you insist on considering all aspects when developing the theory, 
        you can't do anything.  You could just as easily accuse any 
        researcher in cryptography of not considering real-world issues,
        by identifying some real-world flaw in their invention.

                                                                -S

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Microcontroller Cipher
Date: 1 Mar 2000 17:14:37 -0800

In article <[EMAIL PROTECTED]>, Gary  <[EMAIL PROTECTED]> wrote:
> Let the 128 bit key K have bits k0,k1,k2,....,k127.
> I have a block of memory 16 bytes long. I split this into 2 halves, 8 bytes 
> each.
> 
> To Encrypt:
> If k0 is set I XOR the second half to the first, otherwise if k0 is clear I 
> ADD the second to the first.  [and repeat]

This is insecure: everything in sight is linear, so it can be broken
with standard linear algebra (e.g., Gaussian elimination) with something
like 128 known texts.  (Better attacks probably exist, too.)

Don't use this.  Have you looked at, e.g., Skipjack or GOST?  They
appear quite convenient for 8-bit microcontrollers.

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: ...but what about my cipher?
Date: 1 Mar 2000 17:17:01 -0800

Read the FAQ.

You might better response if you posted a concise, easy-to-follow
description of the cipher, along with any analysis you've done.
I didn't see any of that at the web site you listed.

(You HAVE done some analysis, right?  If not, why are you designing
yet another cipher?)

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

From: [EMAIL PROTECTED]
Subject: Re: Visual C++ Decompiling Service/Software Needed
Date: 2 Mar 2000 01:49:24 GMT

Decompiling copyrighted software is a crime (as long as you don't do it only
to correct errors or need to make changes for compatibility reasons).

If you really need the source code of those particular applications, there is
only one legal and morally justifiable way to obtain it: Buy it from the
copyright owners. If you don't like that option, you must do what the authors
of these applications have done: Work, really, really hard and hope you will
eventually get paid before someone steals the result of all your work.


In a previous article,  <[EMAIL PROTECTED]> writes:
>Hi,
>
>I am engineering a software program that analyzes the stock market. I have
>found a few interesting programs similar to it that include interesting
>theories and functions. I need to know if it is possible to obtain their
source
>code by decompiling them. I need to obtain their source code one way or
>another, any suggestions are greatly appreciated!
>
>Thank you! 
>
>(please respond through email)
>


     -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
     -----  http://newsone.net/ --  Discussions on every subject. -----
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email [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
******************************

Reply via email to