Cryptography-Digest Digest #945, Volume #13      Mon, 19 Mar 01 21:13:00 EST

Contents:
  Re: primes for BBS (Terry Ritter)
  Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long) (Terry 
Ritter)
  Re: Idea (amateur)
  Re: Are prime numbers illegal ? (Nicholas Sheppard)
  Re: Fast and Easy crypt send ("Joseph Ashwood")
  Re: Signing/Not signing posts (SCOTT19U.ZIP_GUY)
  Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
  Re: Signing/Not signing posts ("Joseph Ashwood")
  Re: Fast and Easy crypt send (amateur)
  Re: How to eliminate redondancy? ("Joseph Ashwood")
  Re: Fast and Easy crypt send (amateur)
  Re: FIPS 140-1 does not adress eavesdropping (Paul Rubin)
  a 32-bit block cipher (Gregory G Rose)
  Re: Fast and Easy crypt send (amateur)
  Re: a 32-bit block cipher (Paul Rubin)
  Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)

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

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: primes for BBS
Date: Tue, 20 Mar 2001 00:00:48 GMT


On 15 Mar 2001 20:00:11 -0800, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] wrote:

>[EMAIL PROTECTED] (Terry Ritter) writes:
>> On 15 Mar 2001 12:16:04 -0800, in <[EMAIL PROTECTED]>,
>> in sci.crypt [EMAIL PROTECTED] wrote:
>> >All true until the last part.  You don't have to check that x doesn't
>> >produce a short cycle.  If you ever find an x that produces a short
>> >cycle, you have cracked RSA and factored a 1024 bit modulus!  If you
>> >believe that RSA with a 1024 bit modulus is secure, you don't have to
>> >check for short cycles.  If short cycles can be found, RSA is insecure.
>> 
>> Note the logic error above:  If the sender does choose a short cycle,
>> N *can* be factored.  That is not an ability to factor N at will; that
>> is a weakness deliberately allowed to exist.  It is argued that such a
>> thing hardly ever happens.  
>
>No, you can use this to factor N at will.  Give me an N, I will choose
>an x and unluckily find a short cycle.  (If you think it can happen
>with BBS you must grant me the ability to do it with your N.)  I will
>factor your N.

As far as I can interpret this, that's *my* point.

Short cycles *do* exist in BB&S (and, I believe, RSA).  Absent some
way to prevent their selection, a short cycle *can* be selected for
use in a BB&S stream cipher.  The use of any short confusion sequence
is indisputably insecure as a stream cipher, but in a BB&S stream
cipher it also supports factoring N.  And factoring N essentially
exposes all previous and all subsequent use of that N, even if all
other use occurred on long cycles.  

If you are arguing that no short cycles can exist in these "proven"
number-theory systems, you have just answered a comment I received
last week, where it was claimed that everybody has long known about
the short cycle issue.  

I summarized some cycle-length experiments with X**2 mod N (i.e.,
BB&S) in my 1991 Cryptologia article:

   http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect7.2.2


>> A similar problem occurs in any system which has weak keys: typically,
>> the implementor gets to decide whether checking for weak keys is
>> worthwhile.  The difference here is that the result is supposed to be
>> "mathematically proven," so that users probably think it is
>> indisputably secure.  The proof, however, works asymptotically, over a
>> huge universe of possible x0's.  So if the sender "lucks out" and the
>> system chooses a short-cycle x0, the resulting cipher is unarguably
>> insecure anyway.  That is not something the opponents must do to
>> factor N; that is something the sender does for them.  
>
>The difference is that the analog of the "weak key" is a seed which
>is chosen INDEPENTLY OF N!  It would be as if your cipher had a "weak
>key" which would break it regardless of what key you actually used.
>I'd call such a cipher "broken".  

As far as I can understand that comment, BB&S does in fact have that
property, and I believe RSA does as well.  Short cycles do exist, and
if you find one, you can factor N.  And factoring N makes the system
insecure, even when the system is no longer using a short cycle.

Weak keys are not particularly unusual in cryptography, and are not
generally assumed to indicate a broken cipher.  

Short cycles will vary with N:  I would not expect any particular
short cycle to remain unchanged and thus weak for all N.  There will
be different sets of weak keys for different N.  

If we are willing to accept weakness which hardly ever, ever happens,
none of this is an issue of security in practice, because finding a
short cycle at random is very, very unlikely.  Instead, this is an
issue of "proof" in practice, and what the user thinks "proven
strength" means:  If the user thinks a mathematical proof of strength
means the system has no weaknesses at all, they may be surprised.

We do accept rare weakness with respect to keys, but for that we have
no alternative.  In contrast, the rare short-cycle weakness exists in
addition to the possibility of choosing the correct key at random.
The short-cycle weakness can be prevented in practice, but it appears
that such a thing is just too much trouble.  


>If you think RSA has this property
>you think RSA is busted.

As far as I know, RSA *does* have that property, but we were talking
about BB&S:  

BB&S is often used directly as a stream cipher, with hidden N.  The
only way a short cycle might be exposed to the opponent is to be
selected by the enciphering end.  Absent some way to prevent it, a
short cycle *could* be selected.  That would be a weak key.  That
would be the enciphering end exposing itself, simply because it could
not be bothered to certify a long cycle.  Using such a system is
equivalent to wishing and hoping that it will not be weak.  It has a
known weakness that is not excluded, which is hardly what one expects
from mathematically proven security.  Other cipher systems may have
weakness, but at least we don't know about it and then not fix it.

A stream cipher which protects long messages may well traverse a short
cycle, if a short cycle is selected and  used.  But because of the
proof, a BB&S stream cipher may be used with the weakest possible
combining of data and confusion, simply because the implementor will
believe that the sequence is "mathematically proven" unbreakable.  And
I suppose that is the greatest risk of all.  

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


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

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long)
Date: Tue, 20 Mar 2001 00:01:35 GMT


On Mon, 19 Mar 2001 13:04:12 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:

>[...]
>any of Ritter's fft-based ciphers can be
>parallelized... although I'll admit Ritter's are ridiculously
>inefficient in terms of RAM.

"Ridiculously inefficient in terms of RAM?"  Harumph!  Large RAM is an
appropriate tool in cryptography.  

My mixing ciphers do not use the Fast Fourier Transform (FFT), or even
the Fast Walsh Transform (FWT), since both of these use operations
which inherently expand the data range of each element.  Instead, I
generalize the FFT concept into non-expanding mixings, based on
polynomial finite fields, or keyed discrete orthogonal Latin squares
(oLs).  One advantage is an ability to reason about the result:
Mixing is thus guaranteed, not assumed.  

In my Balanced Block Mixing ciphers, each "butterfly" operation can
indeed be performed in parallel hardware, so that a block twice as
wide needs only one additional layer of butterfly computations.
Hardware latency is thus sublinear: a log 2 factor of block size.  

RAM is cheap.  More to the point, RAM is also *arbitrary*, which
generally means that we can fill it such that there is unlikely to be
any shorter description of the contents.  Failure to grasp the
opportunity to use cheap RAM seems rather short-sighted.  Using RAM is
not "inefficint," it is "appropriate cryptographic use."   

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


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

From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Mon, 19 Mar 2001 19:17:57 -0400

Don't forget that with my idea the same clear could produce multiple
cyphertext.
Schneier is defining restricted algorithm when algo is kept secret.
That's not my case.
All my algo is public. The secret who is to find and distinguish two
categories of symbols is not secret at all.
But the sender has the freedom to imagine any kind of two categories
before encrypting.
This secret is disclose if the recipient has the key.
All modern cryptography is based on power of computing.
What I'm proposing is to found a new cryptography based on the inability
of computer to analyse a text trying to distinguish two categories.
Computer has no this attribute. So the cryptanalist even if he use the
computer is helpless. The only strategy for him is to try to guess what
a sender has choosen to encrypt every bit.
And this domain is infinite.
You have multiple combinations using only the characters of ASCII table.
If using others codes, you have to understand thas it's quite impossible
to attack.
  

John Joseph Trammell wrote:
> 
> On Sun, 18 Mar 2001 14:00:29 -0400, amateur <[EMAIL PROTECTED]> wrote:
> > Give me a precise reference. I have the book of Menezes.
> 
> Schneier, p. 2, definition of "restricted algorithm".
> 
> Have you familiarized yourself with the sci.crypt.research FAQ?
> 
>   http://www.landfield.com/faqs/cryptography-faq/

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

Date: Tue, 20 Mar 2001 08:57:27 +1100
From: Nicholas Sheppard <[EMAIL PROTECTED]>
Subject: Re: Are prime numbers illegal ?

On Mon, 19 Mar 2001, John Savard wrote:

> If you can't copyright items that are on the real number line, if you
> can't copyright integers, how can you copyright anything, since
> everything can be coded as a number?

Coding something as a number isn't, in itself, enough to store the
information to reproduce an artistic work. There is no number that one can
point at and say "This is The Phantom Menace". Without knowledge/use of
the coding method used, it's just a number.

As an earlier poster said, one expects that "intention" is a key factor in
determining whether or not any particular expression of a number is
illegal. The number itself is an abstract quantity and making it "illegal"
would be both ridiculous and futile.

If I wrote a paper that happened (by coincidence) to pop out a number that
happened to be identical, say, to a gzipped form of MS Windows, then (a)
that's just unfortunate and (b) the readers who noticed it have far too
much time on their hands.

If we're determined not to apply common sense, should we be surprised that
we manage to come up with something nonsensical?

--
Nicholas Sheppard                                   | Ph: +61 2 4221 5290
Research Fellow                                     | Fax: +61 2 4221 4170
School of Information Technology & Computer Science | E-mail: [EMAIL PROTECTED]
The University of Wollongong, Australia             | WWW: www.uow.edu.au/~nps


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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Mon, 19 Mar 2001 16:48:02 -0800

This looks to be the same algorithm you posted a few days ago (addition and
subtraction are the same operation). Let's see if I remember correctly. It's
a Vigenere cipher (I really suggest you at least look this up before posting
the same drivel again) therefore the attack is:
Take 2 blocks add them to each other
You have now eliminated the key
If it's in English you will have a very small number of valid texts that
could come out the other end (1 bit of entropy per character), determine
which two add to the given value, decide on order, solve:
A-K=E
Where the value E is from the supplied stream, A is the now known-plaintext,
K is easily solves. Your entire cipher is (just like it was the last time
you posted it) completely eliminated.
                        Joe

"amateur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
[snip hey look at my Vigenere Cipher which I've posted at least twice now]



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Signing/Not signing posts
Date: 20 Mar 2001 01:00:25 GMT

[EMAIL PROTECTED] (Joseph Ashwood) wrote in <OlGaOhMsAHA.353@cpmsnbbsa07>:

>I am only opening a discussion on this because this seems to be an
>issue. Should post's be signed?
>
>It is my opinion that some posts should be signed, and some should not.
>If something is said where it for some reason needs to be linkable to
>you, it needs to be signed. For example if David Scott were to retract
>his statements regarding Bruce Schneier it would require a signature of
>some kind to be believed. However for the majority of posts it is
>unreasonable. Consider what usefulness that signature will serve. Under
>most circumstances it will serve none, and may even be detrimental.
>Based on this I urge people to follow the advice to not sign posts. As
>always I am open to dissenting opinions.
>                        Joe

   Personnelly I think he and Wagner should have signed statements
saying they were full of crap when they stated scott16u weak. In
only one vague post did Dave Wagner admit that when he stated scott19u
dead from the slide attack he admitted he never really followed the
method and the person who tried to break it was correct in that
the slide attack would not break it. Secondly if I signed a statment
with PGP what key do I use. I may have posted a public key years
ago but I really have no keys at present time. I make them and then
3 weeks later they are gone. You could make a PGP key in my name and
sign anything. But who would know that it is not my key.

   Secondly I don't trust Mr BS. I did not appricate his SPAM which
I must admit he has not sent SPAM to me in awhile so manybe he 
is getting better.

David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How to eliminate redondancy?
Date: 20 Mar 2001 01:21:37 GMT

[EMAIL PROTECTED] (Joseph Ashwood) wrote in <#FZvf1MsAHA.354@cpmsnbbsa07>:

>SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>Actually I can prove that your compression is not 1-1 onto, based on one
>simple assumption, it compresses. Given a set consisting of each
>possible input up to a given length, the best you can manage is a

   Actually your wrong again. Like all lossless compressors that
work on the set of all 8-bit binary files. They only seem to make
most files smaller so we call them compressors. In fact most
lossless compressors make most files longer. By the counting
theorm "something you may not be familiar with" if you can't
make all files smaller and keep the information and when you
compress some files to make them smaller there are more that you
make longer. You have proved nothing.
  For h2com.exe it is a general file compressor. Any 8-bit
binary file is mapped back to the same set in a unique way
each file has a unique mapping. Same with the inverse of it
which is h2unc.exe  It also maps anyfile from the same set
to a unique entry in that set.

  To do your phony crap take any file up to a given length N
does it map unique to the set of all binary files. Note some
file longer than N after compresion thats OK. Take the
same value of N to see if each file uncompress uniquely
they do. They map to the same set of all binary files.
AS you incrases the value of N it still holds there is no
value of N for which it does not hold.



>permutation. The average length will be the same after as before. My
>statements really did not specify strictly compression, but allowed for
>the use of a padding transform (or the proper type) and/or and AONT. It
>seems reasonable to state that your rather winded explaination of "1-1
>compression" could in fact be a 1-1 onto transform, however stating it
>as such would be much more recognisable than
>> But I also asked what compression you used before you encrypt
>> something. take h2com.exe  it map every member of 8-bit binary files
>> to a one and only one member of the same set.  The reverse maps
>> every member back.
>> For any file X then  Uncompress( Compress ( X)) = X
>> and also for any file Y then Compress( Uncompress (Y)) = Y
>> does this not meet your defination.
>
>Of course the first also requires that the reader have some minor amount
>of Computer Science, Function Theory, etc knowledge. Personally I think
>this was introduced 3rd semester Computer Science, bachelor's degreee.
>

   I wouldn't  know never took mickey mouse Computer Science for
bachelor's degree. Took most of the courses for the Masters degree
but never bothered to get the degree since already had what I
considered a more real degree. A master degree in control thoery
in electrical engineering. Besides at the time I also need to take
an english test for the masters in computer sience but since I got
in 17% in english test to get in college just took the classes and
told them to fuck the english requirement and the second master degree/

>> Does the compression you use
>> meet this criteria.
>
>Actually I don't tend to use compression out of a preference for other
>types of transforms, and the realisation that quite often the length of
>the encrypted information reveals much of the content.


   So then what kind of padding to you use care to descibe it.


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Signing/Not signing posts
Date: Mon, 19 Mar 2001 17:25:16 -0800

I was going to take this to private e-mail but it bounced.

"amateur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> ??? I did not understand.


What about it don't you understand?

> Is it real issue? signing or not?

It's one of those issues that sporadically pops up in security newsgroups
(or any internet based security discussion). The decision about whether or
not to attach signatures hinges mostly on whether or not someone wants to
identify you. For example you have only the name I post under to link me to
the other items I have posted, you have no certainty that they are linked in
any other way. If the poster signs the documents then the items can be
linked (even though the certainty in the name is suspect). The downside is
that we have to agree on a signature method (PGP seems to be the sig du
jour), once that is defined then there is the hassle of varying levels of
trust, just to pick on the same person, do I trust David Scott to sign the
certificates of others? Whether I personally would or not is not a big issue
instead the issue is that every person reading the ng has to assign a level
of trust to David Scott, and particularly with PGP this can become
complicated in a hurry. So except in rare circumstances I tend to frown on
signing ng posts.
                    Joe




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

From: amateur <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Mon, 19 Mar 2001 20:28:45 -0400

You have to read before. I'm talking about sending encrypted text no
matter what is the type of encryption  

Joseph Ashwood wrote:
> 
> This looks to be the same algorithm you posted a few days ago (addition and
> subtraction are the same operation). Let's see if I remember correctly. It's
> a Vigenere cipher (I really suggest you at least look this up before posting
> the same drivel again) therefore the attack is:
> Take 2 blocks add them to each other
> You have now eliminated the key
> If it's in English you will have a very small number of valid texts that
> could come out the other end (1 bit of entropy per character), determine
> which two add to the given value, decide on order, solve:
> A-K=E
> Where the value E is from the supplied stream, A is the now known-plaintext,
> K is easily solves. Your entire cipher is (just like it was the last time
> you posted it) completely eliminated.
>                         Joe
> 
> "amateur" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> [snip hey look at my Vigenere Cipher which I've posted at least twice now]

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Mon, 19 Mar 2001 17:32:33 -0800

"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
[snip]
>    So then what kind of padding to you use care to descibe it.

I never said I used padding either. I said I (most often) use transforms
other than compression. I will choose not to reveal more about it than that.
                    Joe



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

From: amateur <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Mon, 19 Mar 2001 20:36:12 -0400

The text is encrypted with my algo. Read before attaching.
The ouput you are looking for is random.
Every bit is crypted with symbol which is choosen randomly.
If I choose odd and even to encrypt. Then the number 0 or 2 or 4 or 6 or
8 represent the bit 0.
So the ouput E you are trying to test is random.
That's what you don't understand.
I know this type of attack.
If you use you are going to find millions of output with odds and even.
Like OTP.
You could find "hello" or thank or all strings with 5 characters.

 

Joseph Ashwood wrote:
> 
> This looks to be the same algorithm you posted a few days ago (addition and
> subtraction are the same operation). Let's see if I remember correctly. It's
> a Vigenere cipher (I really suggest you at least look this up before posting
> the same drivel again) therefore the attack is:
> Take 2 blocks add them to each other
> You have now eliminated the key
> If it's in English you will have a very small number of valid texts that
> could come out the other end (1 bit of entropy per character), determine
> which two add to the given value, decide on order, solve:
> A-K=E
> Where the value E is from the supplied stream, A is the now known-plaintext,
> K is easily solves. Your entire cipher is (just like it was the last time
> you posted it) completely eliminated.
>                         Joe
> 
> "amateur" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> [snip hey look at my Vigenere Cipher which I've posted at least twice now]

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

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 does not adress eavesdropping
Date: 19 Mar 2001 17:42:41 -0800

Frank Gerlach <[EMAIL PROTECTED]> writes:
> In response to the Paul Rubin's reference to the IBM 4758 cryptographic
> coprocessor I have read a paper from IBM, describing the FIPS 140-1
> validation process:
> http://www.research.ibm.com/secure_systems/papers/nfips.pdf
> 
> It clearly states that FIPS 140-1 does not even adress power line analysis.
> 140-1 just has a different threat model: mainly active attacks conducted
> physically (e.g. opening the device) or through stimuli (e.g. malicious
> commands by application software).
> I consider the stimuli-based threat model very important, but it is not
> related to the threat model in this discussion threat.

They probably ought to extend FIPS 140-1 to discuss power trace
analysis along with induced fault analysis and other such methods.
However, I can tell you that hardware designers are acutely aware of
these attacks and do what they can to protect against them, whether or
not 140-1 requires it.

I'm somewhat more concerned about firmware back doors being built into
devices.  I'd like to see the sci.crypt community design its own
device with standard parts and public specifications, but I'm not
enough of a hardware whiz to start such a project myself.

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

From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: a 32-bit block cipher
Date: 19 Mar 2001 17:43:56 -0800

Recently I needed a way of generating an
unpredictable permutation function of 32-bit
values, in other words, a block cipher with a
32-bit block. It was important for that
application that 32-bit values generated over a
period of time should not repeat. I searched
around looking for such a cipher, and couldn't
find one, not surprisingly since it would be
insecure in the face of a codebook style attack
(the entire codebook would fit into 16GB).

Anyway, that didn't change the fact that I needed
one, so I wrote one. I took Skipjack (Panu
Rissanen <[EMAIL PROTECTED]>'s version) and turned it
into a 24-round feistel cipher. It retains the
F-table, the G-permutation and the key-schedule
(including the 80-bit keys), but it loses the
feedback register structure and the two different
kinds of rounds.

Then for the fun of it I applied for, and
received, an export license from the Australian
Defence Signals Directorate that allows me to post
it on the Web. It's at:
  http://www.home.aone.net.au/qualcomm/skip32.c

It's freely available, and I hope it is of use to
someone else too. If anyone sees any problems with
it, please do tell me.

Greg.

-- 
Greg Rose                                       INTERNET: [EMAIL PROTECTED]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

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

From: amateur <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Mon, 19 Mar 2001 20:44:05 -0400

I used a single function a-k. You can any complex function using all the
function families.
Just to illustrate I had choosen a simple and easy function.
You have to read all the text "idea" without scorn or contempt.
Thank you.

Joseph Ashwood wrote:
> 
> This looks to be the same algorithm you posted a few days ago (addition and
> subtraction are the same operation). Let's see if I remember correctly. It's
> a Vigenere cipher (I really suggest you at least look this up before posting
> the same drivel again) therefore the attack is:
> Take 2 blocks add them to each other
> You have now eliminated the key
> If it's in English you will have a very small number of valid texts that
> could come out the other end (1 bit of entropy per character), determine
> which two add to the given value, decide on order, solve:
> A-K=E
> Where the value E is from the supplied stream, A is the now known-plaintext,
> K is easily solves. Your entire cipher is (just like it was the last time
> you posted it) completely eliminated.
>                         Joe
> 
> "amateur" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> [snip hey look at my Vigenere Cipher which I've posted at least twice now]

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

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: a 32-bit block cipher
Date: 19 Mar 2001 17:56:06 -0800

[EMAIL PROTECTED] (Gregory G Rose) writes:
> Recently I needed a way of generating an
> unpredictable permutation function of 32-bit
> values, in other words, a block cipher with a
> 32-bit block. It was important for that
> application that 32-bit values generated over a
> period of time should not repeat. I searched
> around looking for such a cipher, and couldn't
> find one, not surprisingly since it would be
> insecure in the face of a codebook style attack
> (the entire codebook would fit into 16GB).

You could try Schroeppel's Hasty Pudding Cipher, which was submitted
as an AES candidate.

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How to eliminate redondancy?
Date: 20 Mar 2001 01:50:13 GMT

[EMAIL PROTECTED] (Joseph Ashwood) wrote in <eezqX3NsAHA.273@cpmsnbbsa07>:

>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>[snip]
>>    So then what kind of padding to you use care to descibe it.
>
>I never said I used padding either. I said I (most often) use transforms
>other than compression. I will choose not to reveal more about it than
>that. 
>                    Joe
>

  If I read that correctly "will choose" implies at some time in
the future. If that is what you mean what do you use now or have
in the past.


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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


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