Cryptography-Digest Digest #998, Volume #11 Sat, 10 Jun 00 17:13:01 EDT
Contents:
Re: Random sboxes... real info (Simon Johnson)
Re: Call for evaluating and testing a stream cipher program
([EMAIL PROTECTED])
Re: Question about recommended keysizes (768 bit RSA) (Bob Silverman)
Re: Random sboxes... real info (Simon Johnson)
Re: Random sboxes... real info (tomstd)
Re: Random sboxes... real info (tomstd)
Re: Call for evaluating and testing a stream cipher program (tomstd)
Re: Large S-Boxes (tomstd)
Re: Arithmetic Coding (tomstd)
Re: Random IV Generation (tomstd)
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Sat, 10 Jun 2000 19:05:04 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8ht8ii$k62$[EMAIL PROTECTED]>, Simon Johnson
> <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> > tomstd <[EMAIL PROTECTED]> wrote:
> >> at
> >>
> >> http://tomstdenis.com/sboxes.txt
> >>
> >> Is some testing on random 8x8 sboxes... (about 200 or so). I
> >> will leave the test go overnight and see what it comes up
> with.
> >>
> >> This should help settle the futile argument.
> >>
> >> Tom
> >>
> >> * Sent from RemarQ http://www.remarq.com The Internet's
> Discussion
> >Network *
> >> The fastest and easiest way to search and participate in
> Usenet -
> >Free!
> >>
> >>
> >
> >Could you describe the tables please?
> >
> >Here is what i think it means:
> >LPmax - Maximum Probability of Linearness existing
> >MPmax - Maximum Probability of Differenitals existing
> >
> >What the numbers mean i have no idea.
> >
> >Could you describe them fully please, otherwise i can't
> understand them
> >and therefore your time is wasted :)
>
> That would be bad... GHmm at
>
> http://tomstdenis.com/sbox8.txt
>
> is the overnight results from my test. The LPmax means the
> strongest linear bias is 'x'. In this test I group them in 2
> units so if you look at "LPmax = 28: %0.187" that means %0.187
> of all tested 8x8 sboxes have a linear bias of either
>
> p = 1/2 +/- 28/256
> or
> p = 1/2 +/- 30/256
>
> This is usefull obviously in linear cryptanalysis. The DPmax
> means the strong in-out xor pair has prob of x/256 of occuring.
> If you look at the table it says "DPmx = 12: %0.002" that means %
> 0.002 of the tested random sboxes has a maximum probability for
> any pair of 12/256.
>
> Good 8x8 sboxes should have a LPmax of no more then 32
> (preferably lower) and a DPmax of no more then 8.
>
> Tom
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
> The fastest and easiest way to search and participate in Usenet -
Free!
>
>
Sample S-Boxgen input:
S-Box size: 8 8
Linear trait bounds: 0 32
Max diff: 8
Output-Inverse: 1 (does this make the s-box a bijection?)
Number of s-boxes: 1 (just to test :))
SAC:1
SC:1
BIC:1
Is this okay, i would have made the bounds a bit more closed, only i
fear it could take quite a while to generate.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Call for evaluating and testing a stream cipher program
Date: Sat, 10 Jun 2000 12:25:16 -0700
I think you have not read the description. You missed the very principle of the
scheme. The reason I "post-process" (your terminology) the BBS is that it is too
slow. In fact you can download the executable and find out for youself how fast
it is.
Instead of emotional outbursts, do you have any specific idea how to break it?
Cascade Research
tomstd wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >We are offering $200 reward to the person who can break our
> new, fast
> >stream cipher. The details are available on this website:
> >
> >http://CascadeResearch.ebz.com/
> >
> >You can obtain an executable, source code, and description.
>
> You have to be joking right? Your scheme is such a stupid idea
> that it even hurts to read.
>
> You feed three LFG's and a BBS gen into some mixing functions,
> etc... Do you even know what a BBS gen is? It's a very slow
> somewhat secure prng. Why would you post-process it?
>
> How could you put the words 'fast' and BBS together anyways?
>
> What asham.
>
> Tom
> >
> >Cascade Research
> >
> >
> >
> >
> >
> >
>
> * 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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Sat, 10 Jun 2000 19:09:20 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The VAX was a very good number cruncher but really poor performance
as a
> > multi-user system..terminal IO was terrible....
>
> Generalizations like that are useless. If your VAX was equipped with
> a KMC11B loaded with suitable front-end code, terminal I/O was very
> good.
> Even with the lowly DZ11, a carefully written device driver (mine :-)
> would work a *lot* better than a naive one.
>
> The main things that the VAX-11 deserves credit for in the history of
> computing, as I see it, are (1) the "main machine" for development of
> the most fundamental Internet protocols and (2) popularization of
UNIX.
>
> I'm not sure what any of this has to do with cryptology.
I had used the VAX as an example machine from 1977 and compared it
against current PIII's for the purpose of showing that BUS SPEEDS
have *not* followed Moore's law. The VAX in 1977 has a 13Meg bus.
Today's PC's have 133Meg. This is far short of a doubling every
18 months.
Someone else then critcized the comparison, saying (in effect)
that the VAX was a high end machine in 1977 and that it wasn't fair to
compare it with todays desktops.
The problem is, there were no $2,000 computers in 1977 and there were
no desktop class machines so (in some sense) ANY comparison might
be criticized by someone looking for an excuse to be critical.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Sat, 10 Jun 2000 19:35:47 GMT
In article <8hu3gq$5rc$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
> > In article <8ht8ii$k62$[EMAIL PROTECTED]>, Simon Johnson
> > <[EMAIL PROTECTED]> wrote:
> > >In article <[EMAIL PROTECTED]>,
> > > tomstd <[EMAIL PROTECTED]> wrote:
> > >> at
> > >>
> > >> http://tomstdenis.com/sboxes.txt
> > >>
> > >> Is some testing on random 8x8 sboxes... (about 200 or so). I
> > >> will leave the test go overnight and see what it comes up
> > with.
> > >>
> > >> This should help settle the futile argument.
> > >>
> > >> Tom
> > >>
> > >> * Sent from RemarQ http://www.remarq.com The Internet's
> > Discussion
> > >Network *
> > >> The fastest and easiest way to search and participate in
> > Usenet -
> > >Free!
> > >>
> > >>
> > >
> > >Could you describe the tables please?
> > >
> > >Here is what i think it means:
> > >LPmax - Maximum Probability of Linearness existing
> > >MPmax - Maximum Probability of Differenitals existing
> > >
> > >What the numbers mean i have no idea.
> > >
> > >Could you describe them fully please, otherwise i can't
> > understand them
> > >and therefore your time is wasted :)
> >
> > That would be bad... GHmm at
> >
> > http://tomstdenis.com/sbox8.txt
> >
> > is the overnight results from my test. The LPmax means the
> > strongest linear bias is 'x'. In this test I group them in 2
> > units so if you look at "LPmax = 28: %0.187" that means %0.187
> > of all tested 8x8 sboxes have a linear bias of either
> >
> > p = 1/2 +/- 28/256
> > or
> > p = 1/2 +/- 30/256
> >
> > This is usefull obviously in linear cryptanalysis. The DPmax
> > means the strong in-out xor pair has prob of x/256 of occuring.
> > If you look at the table it says "DPmx = 12: %0.002" that means %
> > 0.002 of the tested random sboxes has a maximum probability for
> > any pair of 12/256.
> >
> > Good 8x8 sboxes should have a LPmax of no more then 32
> > (preferably lower) and a DPmax of no more then 8.
> >
> > Tom
> >
> > * Sent from RemarQ http://www.remarq.com The Internet's Discussion
> Network *
> > The fastest and easiest way to search and participate in Usenet -
> Free!
> >
> >
>
> Sample S-Boxgen input:
>
> S-Box size: 8 8
> Linear trait bounds: 0 32
> Max diff: 8
> Output-Inverse: 1 (does this make the s-box a bijection?)
> Number of s-boxes: 1 (just to test :))
> SAC:1
> SC:1
> BIC:1
>
> Is this okay, i would have made the bounds a bit more closed, only i
> fear it could take quite a while to generate.
>
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Any chance of putting the exe on you're site.
I get:
Error: Domain or Range too big
When i select an 8 8 s-box. ( I am using Turbo C Freeware to compile)
Funnly, i compiled it on a linux shell, and it seems to work fine.
Could you give me an approximation to the number of s-boxes the program
usally has to search?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 13:43:36 -0700
In article <8hu3gq$5rc$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> In article <8ht8ii$k62$[EMAIL PROTECTED]>, Simon Johnson
>> <[EMAIL PROTECTED]> wrote:
>> >In article <[EMAIL PROTECTED]>,
>> > tomstd <[EMAIL PROTECTED]> wrote:
>> >> at
>> >>
>> >> http://tomstdenis.com/sboxes.txt
>> >>
>> >> Is some testing on random 8x8 sboxes... (about 200 or
so). I
>> >> will leave the test go overnight and see what it comes up
>> with.
>> >>
>> >> This should help settle the futile argument.
>> >>
>> >> Tom
>> >>
>> >> * Sent from RemarQ http://www.remarq.com The Internet's
>> Discussion
>> >Network *
>> >> The fastest and easiest way to search and participate in
>> Usenet -
>> >Free!
>> >>
>> >>
>> >
>> >Could you describe the tables please?
>> >
>> >Here is what i think it means:
>> >LPmax - Maximum Probability of Linearness existing
>> >MPmax - Maximum Probability of Differenitals existing
>> >
>> >What the numbers mean i have no idea.
>> >
>> >Could you describe them fully please, otherwise i can't
>> understand them
>> >and therefore your time is wasted :)
>>
>> That would be bad... GHmm at
>>
>> http://tomstdenis.com/sbox8.txt
>>
>> is the overnight results from my test. The LPmax means the
>> strongest linear bias is 'x'. In this test I group them in 2
>> units so if you look at "LPmax = 28: %0.187" that means %0.187
>> of all tested 8x8 sboxes have a linear bias of either
>>
>> p = 1/2 +/- 28/256
>> or
>> p = 1/2 +/- 30/256
>>
>> This is usefull obviously in linear cryptanalysis. The DPmax
>> means the strong in-out xor pair has prob of x/256 of
occuring.
>> If you look at the table it says "DPmx = 12: %0.002" that
means %
>> 0.002 of the tested random sboxes has a maximum probability
for
>> any pair of 12/256.
>>
>> Good 8x8 sboxes should have a LPmax of no more then 32
>> (preferably lower) and a DPmax of no more then 8.
>>
>> Tom
>>
>> * Sent from RemarQ http://www.remarq.com The Internet's
Discussion
>Network *
>> The fastest and easiest way to search and participate in
Usenet -
>Free!
>>
>>
>
>Sample S-Boxgen input:
>
>S-Box size: 8 8
>Linear trait bounds: 0 32
It should be "-32 32" not 0 32...
>Max diff: 8
>Output-Inverse: 1 (does this make the s-box a bijection?)
No it makes an inverse with the same properties. The sboxes are
always bijective if the input/output sizes are equal.
>Number of s-boxes: 1 (just to test :))
>SAC:1
>SC:1
Why SC?
>BIC:1
>
>Is this okay, i would have made the bounds a bit more closed,
only i
>fear it could take quite a while to generate.
You normally can find alot of sboxes with
linear trait: -32 32
diff trait: 16
sac: 1
sc: 0
bic: 0
But they are not so super good...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 13:44:35 -0700
>Any chance of putting the exe on you're site.
>I get:
>Error: Domain or Range too big
>When i select an 8 8 s-box. ( I am using Turbo C Freeware to
compile)
>
>Funnly, i compiled it on a linux shell, and it seems to work
fine.
>Could you give me an approximation to the number of s-boxes the
program
>usally has to search?
That's because the tables are too large for a 16-bit model. And
no I won't put exe's up. Pick up DJGPP if you need an msdos
copy ...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Call for evaluating and testing a stream cipher program
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 13:45:45 -0700
You are obviously some kinda of troll. You responded with the
exact same message three times after I asked specific questions.
Bye.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Large S-Boxes
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 13:47:42 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
Ritter) wrote:
>
>On Fri, 9 Jun 2000 22:31:06 -0700, in
><8hsknh$bov$[EMAIL PROTECTED]>, in sci.crypt "Scott
Fluhrer"
><[EMAIL PROTECTED]> wrote:
>
>>Simon Johnson <[EMAIL PROTECTED]> wrote in message
>>news:8hrtja$nte$[EMAIL PROTECTED]...
>>>
>>>
>>> I think i'm flogging a dead-horse here, but i'm after
evidence in 'a
>>> dummies guide to' style to the pro's and con's of randomly
generated S-
>>> boxes.
>>>
>>> I'm thinking 16x16 for a block-cipher i'm devolping (don't
hold u're
>>> breath, i don't have 1/2 a clue what i'm doing :), i just
having fun.)
>>
>>So, you're think about an sbox that will take 128k of memory?
Well, that'll
>>work in the sense that (with high probability) there won't be
any
>>troublesome characteristics, however, an sbox that big won't
fit in a
>>conventional L1 cache. Assuming you're running it on any
modern CPU, any
>>sbox reference will take several cycles while the CPU waits
for the memory
>>(or more likely, the L2 cache) to retrieve it. Since this
will happen to
>>almost every sbox reference, you're performance is likely to
be dreadful,
>>and as has been pointed out, a secure block cipher is actually
pretty easy
>>to design if you are willing to settle for dreadful
performance...
>
>I generally agree. On the other hand . . .
>
>It may be interesting to think that the reason performance
drops when
>using large tables is that table elements are unlikely to be re-
used,
>and so will not be in cache. Yet it is often re-use itself
which
>allows values to be determined by cryptanalysis, resulting in a
broken
>cipher. Thus, the lack of such re-use might be a form of
strength.
>
>In a sense, computer caching is a hostile environment for
>cryptography, in that it encourages constructions which re-use
>internal data and discourages constructions which benefit less
from
>cache.
You should know better.
CAST sboxes are perfect 32x32 sboxes that only take 4kb of
memory. I have no clue how they made them, but Obviously the
same idea could be applied to make 16x16 sboxes that only take
1kb of ram (using two 8x16 sboxes).
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Arithmetic Coding
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 14:03:10 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jack)
wrote:
>[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
>>tomstd <[EMAIL PROTECTED]> wrote:
>>: In article <[EMAIL PROTECTED]>, Tim Tyler
<[EMAIL PROTECTED]> wrote:
>>:>tomstd <[EMAIL PROTECTED]> wrote:
>>:>: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>>
>>:>:>[...] matt's site that has the best info on useful with
>>:>:> source code adaptive unadulterated arithmetic coding.
[...]
>>:>
>>:>: To the best of my knowledge no arithmetic coder adds
anything
>>:>: that doesn't need to be there. So your logic is flawed my
friend.
>>:>
>>:>What if the arithmetic stream does not terminate on a byte
boundary?
>>:>
>>:> Think about it - an arithmetic coding stream is pretty
good -
>>:> but it is only rarely as perfect as you will find at:
>>:>
>>:> http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
>>
>>: While your site looks nice, it's pure crap. [...]
>>
>>It's not my site. It belongs to Matt Timmermans
>>(http://www.timmermans.org/)
>>
>>: Nowhere in any OS does it state that your file must contain
at least
>>: or a boundary of 8 bits of *information*.
>>
>>What is the purpose of this statement? Most modern OSs
enforce an 8-bit
>>*data* alignment. Compression produces a stream of *data*.
It's
>>information-content from the perspective of some observer is
moot.
>>
>>: Note: It is possible to write 7 bits of *information* to a
file
>>: using ms-dos for example, you just end of wasting the last
bit.
>>
>>So - if I have this straight - you're advocating padding out
the file
>>with an "impossible" token that takes the last arithmetic
coding symbol
>>beyond the EOF?
>>
>>This is likely to allow analysts to reject decrypts as being
invalid
>>compressed files - and increases the average length of the
file compared
>>to what's possible with Matt's end-treatment. There seem to
be no
>>compensating advantages.
>>
>>: All real arithmetic coders do is calculate the high/low and
when
>>: they match in the upper decimal (bit) they shift the bit out.
>>: This isn't secret hidden information, it's part of the bloody
>>: number!!!
>>
>>Your objection here appears to be addressing a point nobody
ever raised.
>>
>>The only "problem" with added information in arithmetic coding
schemes
>>occurs at the end of the file.
>
> Writting to little Tommy is a waste of time. I have tried and
>his mind seems so full of crap that obvious facts seem to escape
>him, Tim he is not capable of grasping the obvious facts of what
>this kind of comprssion is all about. It is liking trying to
teach
>a pig. He can't learn and it only wastes your time and the pigs.
>The only way he could even start to understand the concept
would be
>if a phony crypto god talked straight about the concept of
compression
>with encryption and getting and honest discussion out of them is
>pretty much useless since it does not further there goals.
Keeping
>people like tom ignorant is much more inline with there
thinking.
>
>
The irony is you failed to answer my questions. You always fail
to answer my questions. Please enlighten me. If you can prove
your points rationally people will listen. But just saying "The
phony crypto-gods said this so it must be bad" is not prove in
onto itself for your rants.
I mean you don't even support your rants... that's the funny
part. You probably don't even know what you are arguing about.
My point which I will re-iterate for the 100th time is
that "huffman compression is inefficient and can pack less
information per bit of plaintext" which is a very powerful dis-
proof for your theory. Your theory is that the other
compression algorithms leave information about the plaintext
(redundant information) in the compressed data stream. My
counterproof is that this is not possible if they are MORE
EFFICIENT.
For crying out-loud know when you have been beaten, or for
goodness sake prove me wrong. But please don't just
rant "ignorant tommy must be wrong" because it's friggin
annoying and won't get anyone anywhere.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Random IV Generation
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 14:04:08 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
Ritter) wrote:
>
>On Sat, 10 Jun 2000 13:05:21 +0200, in
><[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
>
>>Terry Ritter wrote:
>>
>>> Counter mode with a binary counter seems to be just asking
for
>>> trouble. One alternative would be to use a polynomial
counter, to get
>>> about half the "counting" bits to change on each count,
which should
>>> be a lot less risky.
>>
>>Sorry for my ignorance. What is the definition of a polynomial
counter?
>>Thanks.
>
>Instead of counting in binary sequence, use a finite field.
>Typically, this would be a simple linear feedback shift register
>(lfsr). There is no strength required for the counting
sequence; the
>strength improvement comes from not presenting a sequence in
which
>only one bit changes fully half the time.
Big complicated... use a linear congruetial generator then, no
reason to get all "high" tech ..hehehehe..
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
** 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
******************************
