Cryptography-Digest Digest #979, Volume #12 Sun, 22 Oct 00 16:13:01 EDT
Contents:
Re: Visual Basic ("norman")
Re: My comments on AES (Mok-Kong Shen)
Re: Dense feedback polynomials for LFSR (Tim Tyler)
Re: Help ,Does anybody know ??? (Tom St Denis)
Re: Huffman stream cipher. (Tom St Denis)
Re: Huffman stream cipher. (Tom St Denis)
----------------------------------------------------------------------------
From: "norman" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic
Date: Sun, 22 Oct 2000 20:42:30 +0200
try locknuts from www.kewlstuff.co.za and *read* past postings :-)
binary digit <[EMAIL PROTECTED]> wrote in message
news:ISmI5.126052$[EMAIL PROTECTED]...
> Anyone know where I can find some encryption algorithms that have been
coded
> in Vb and have good documentation on them?
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Date: Sun, 22 Oct 2000 21:23:29 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> :> How about the bit where he wrote (from the URL above):
> :>
> :> ``I believe that within the next five years someone will discover an
> :> academic attack against Rijndael.''
>
> : However, if an academic attack is only of interest
> : academically and not a genuine menace in practice, then
> : that would be only a happy and laudable success of some
> : intellectual endeavour, nothing more.
>
> No doubt it would be an inspiration for those wishing to embark on
> further such intellectual endeavours.
I wouldn't care, as long as the current record of cracking
the algorithm I use needs a time above, say, 2 million years.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 18:51:50 GMT
Joaquim Southby <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
:>Joaquim Southby <[EMAIL PROTECTED]> wrote:
:>Which might be interesting - if you had provided a method of identifying
:>which LFSRs had a large period that does not involve stepping through the
:>states one at a time, and noticing when they repeat.
:>
:>[FWIW, I know such methods exist - but do not know of any useful ones.]
:>
:>Since this appears to be the best approach you've mentioned, the results
:>will not have a guaranteed minimum period greater than what you can step
:>through. Consequently, they are only known to offer protection against
:>attackers with resources less than or equal to your own.
:
: Hmm. I guess I'm making some progress here. In previous posts, you held
: that there was no such thing as a guaranteed minimum period.
Are you sure? I said nothing of the sort AFAICS.
My best guess is that you are mis-interpreting where I wrote: ``You're
never going to get v[e]ry large guaranteed minimum period'' - as meaning
that there was no such thing as a guaranteed minimum period.
It doesn't mean that - it means what it said - any guaranteed minimum
period you get by this method will have a size limited by your ability to
iterate through the LFSR.
:>: One group of behaviours that is dissimilar between the two is how
:>: "random" the output stream looks. The output over a period of a
:>: maximal-length LFSR will *always* have the same characteristics: a) # of
:>: 1's minus # of 0's = 1; [...]
:>
:># of 1s minus # of 0s = n where n = register width?
:
: From Golomb's "Shift Register Sequences": "In any maximum-length shift
: register sequence, there are 2^(n-1) ones and 2^(n-1) -1 zeros." [...]
I detect differences in what is considered the "output" of the generator.
For (e.g.) self-test applications it's common to take the entire state
of the register as the output. You are considering the output to be a
single bit. We are both right in our own ways. I believe this is the
origin of our difference.
:>: b) the number of runs is strictly quantifiable -- 1/2 of all runs have
:>: length 1, 1/4 have length 2, etc.; c) perform a circular shift of some
:>: number less than the period on the output string and then XOR the
:>: result with the original string -- the result of the XOR will exhibit
:>: the same characteristics described in a) and b).
:>
:>: Conversely, the output over a period of a submaximal-length LFSR is not
:>: constrained to these characteristics. (The autocorrelation exhibited in
:>: part c is still very strong, though.) In that regard, this output looks
:>: more like a random stream of bits because it will statistically vary from
:>: the idealized output described above. [...]
:>
:>No! If anything it looks less like a random stream - since it has a
:>shorter period.
:
: Take any random stream of 1's and 0's. Are you guaranteed that (# of
: 1's) - (# of 0's) = 1 in that stream? No. Take the output of a period
: of a maximal-length LFSR. Are you guaranteed that
: (# of 1's) - (# of 0's) =1 in that stream. Yes. Take the output of a
: period of a sub-maximal LFSR. Are you guaranteed that (# of 1's) - (# of
: 0's) = 1 in that stream? No. No (random) = No (sub-maximal); No
: (random) /= Yes (maximal). This logic applies to the other two
: randomness postulates.
Which gets us nowhere. To gather this information you have to step
through the entire period. If you can do this, you can determine the
period of the generator - and all subsequent output immediately becomes
100% predictible - and thus 0% random.
I think you need to present some sort of test to distinguish sub-maximal
LFSR output from maximal LFSR output significantly *before* the period is
reached - since by the time the period is reached any randomness
properties disintegrate and the generator can be trivially predicted.
:>: (Before anyone jumps in with the old "what is random" thread, I did not
:>: say that the output is random -- I said it looks more like a random
:>: stream than that of the maximal-length LFSR.) Can you see any possible
:>: uses for a sub-maximal LFSR now?
:>
:>The idea that its output is less likely to exhibit statistical anomolies
:>than a conventional LFSR appears to be false.
:>
:>Yes, the output over a period is no longer balanced (give or take n 0s)
:>- but try writing a statistical test to detect that. The same goes for
:>the runs.
:
: The tests that would identify the stream as the output of a
: maximal-length LFSR have already been written. They are the three
: randomness postulates I gave in my previous post. A random stream would
: come close to meeting those postulates as would the output of a
: sub-maximal LFSR; the max-LFSR stream meets them exactly.
These are not practical tests. To apply them you need to have the
output from (practically) an entire period to examine. If you can get
that all bets are off.
: If you have a stream that meets all three postulates exactly, would you
: conclude that you'd stumbled onto a perfectly balanced random stream or
: would you suspect an LFSR?
The period has been reached. It would not take much brain power to
distinguish the sub-maximal LFSR from a random stream.
:>You might as well iterate until you've found the period - a
:>test which the non-maximal LFSR will fail first.
:
: Sure. I can see this. Let's find the period of the sub-maximal LFSR.
: Now let's find the period of the maximal LFSR. OK, that settles it --
: the sub-maximal LFSR fails this test. What are you talking about?
I'm not sure what you're talking about by asking me what I'm talking
about. We are agreed that any test requiring data from the entire period
is likely to be failed by the sub-maximal generator first (assuming the
registers are of the same size)...?
:>Both algorithms fall equally to Berlekamp-Massey, of course.
:
: Why "of course"?
Because the system is still completely linear, and Berlekamp-Massey is
intimately related to the linear complexity of the system. It will
certainly detect that a linear system (rather than a random source) is in
use at short notice.
: Have you tried the algorithm against a sub-maximal
: LFSR? Have you ever even tried it against any type of LFSR?
In fact no.
:>: These puppies are a lot more interesting than their maximal-length
:>: brethren simply because of the wider range of behaviour that, AFAIK,
:>: hasn't been explored yet.
:>
:>Nobody's interested in them - but with good reason. Generally the whole
:>point of using an linear counter is to cheaply get some guaranteed long
:>cycles. Miss out this property, and what remains is of low utility.
:
: Everything but your last statement has been disproved already. Many
: people (including some organizations with initials for names) are
: interested in these devices. [...]
Well, LFSRS with non-power of two periods do have their uses, if (for
example) you want to count to other values other than precursors of powers
of two. My "nobody" was undoubtely an exaggeration - however maximal
LFSRs do appear to get significantly more interest.
: They can produce guaranteed long cycles. They can be found as the
: byproduct of testing for maximal-length LFSR's.
That was one method I was thinking of. I did not think it would be
terribly useful - since the utility of the method depends on the size
of the factors of the period - and won't work at all at some register
sizes.
At the end of the day you still have to make sure you're on a long cycle.
It all sounds like a pain in the arse, with no corresponding benefits.
Thinking about it I believe there are probably other methods of
getting large periods - since IIRC, there's a construction for
building a LFSR with period k for all positive k.
If you use such a method (rather than your iterative construction)
many problems are resolved. However, you appear to overstate the
advantages - in particular sequences produced by sub-maximal LFSRs do
not appear to be meaningully more random than maximal ones - despite the
latter's fulfilling of Golomb's randomness postulates - and there's no
advantage in keying these devices.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Help ,Does anybody know ???
Date: Sun, 22 Oct 2000 19:14:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] wrote in <8suute$2m7$[EMAIL PROTECTED]>:
>
> >Does anybody know where i can find the program or " C " component
> >
> >about use the RSA to encrypt the "file" directly.
> >
> > Please help me ,thanks so much.
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
> It is not that hard to code your self. But it
> is not considered a strong method of encryption. It
> has lots of weaknesses. The main use of it is for
> key exchanges in public key cipher. But one would not
> in gerneral try not to do file encryption with it.
What specific weakness are you referring to?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Sun, 22 Oct 2000 19:19:50 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> >
> > [EMAIL PROTECTED] (Richard Heathfield) wrote in
> > <[EMAIL PROTECTED]>:
> >
> > >"SCOTT19U.ZIP_GUY" wrote:
> > >>
> > >> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> > >> <[EMAIL PROTECTED]>:
> > >>
> > >> >SCOTT19U.ZIP_GUY wrote:
> > >> >[snip]
> > >> >> As for the fact a stream is not a file in one sense of the
word
> > >> >> you seemed to use it in other senses like in the case in
adding
> > >> >> an integer to a stream. In reading that problem I took it as
a file
> > >> >> and you did not object. Also I give you an example for that
other
> > >> >> thread. WHere you capaple of following it or what?
> > >> >
> > >> >I have not, and do not plan to, look at your DSC program. If
you can
> > >> >explain the algorithm in clear english, I would be happy, but I
am not
> > >> >going to look at your shitty source code.
> > >>
> > >> You sound like the kind of Jerk that is never happy so why
> > >> pretend that if I did a little more FREE work for your lazy
> > >> ass that you would be happy. I can see by your comment you
> > >> obviously lacked the ability to even follow the simple example I
> > >> did for you.
> > >>
> > >> ... rest of his nonsense dropped.
> > >
> > >I had a quick look at your source code. He's right. It's hard to
read,
> > >it's non-portable (I'd guess it's for DJGPP, but that's just a
guess)
> > >and in at least one place it's incorrect. I couldn't look at it
for long
> > >because it was so tiring.
> > >
> >
> > Thats rude of you. Are you another one of Toms's idenites.
>
> Wise up, brainless. If you'd tried a Deja search before making such an
> asinine observation, you'd know that the likelihood of Tom St Denis
and
> I being the same person is zero minus. For one thing, I can regularly
> type two words together without a letter transposition (sorry, Tom, if
> you're reading...).
Hehehe, I would like to think I don't make that many typos.
> > If you found a mistake at least be honest and say what it is
> > so we can tell if your full of shit or not.
>
> Now who's being rude? If you want a flame war, I think it should be
> taken to email so that other people aren't exposed to your obscene
> language.
>
> But as for the mistakes, please notice that I said:
>
> "I had a quick look at your source code. He's right. It's hard to
read,
> it's non-portable (I'd guess it's for DJGPP, but that's just a guess)
> and in at least one place it's incorrect. I couldn't look at it for
long
> because it was so tiring."
>
> The "at least one place" is:
>
> void
> main()
> {
>
> In C, main returns int, and any other return type invokes undefined
> behaviour.
>
> > Just becasue you
> > don't like the form tough shit.
>
> In my opinion, it's hard to read. If you want people to help you out
by
> cryptanalysing your algorithms, it makes sense to help them out by
> making the code easy to read. If you can't be bothered to take the
> trouble to do that, you shouldn't be surprised if people don't bother
to
> analyse your algorithms.
>
> > Many people say there are mistakes
> > but most are wrong.
>
> I can provide a citation from the C Standard if need be, which shows
> that main returns int.
>
> > LIke I am not god but you contrubute nothing
> > by prestending you found something in the code.
>
> I don't pretend. I don't need to. Your program is broken, not for any
> cryptographic reason (I didn't have to look that far and I lack the
> expertise to do so anyway, because I'm not an expert cryptographer and
> don't pretend to be) but because it breaks the rules of the language.
>
> > Even h2com.exe
> > had a few sneaky mistakes that people found after years of use
> > with no failings.
>
> Furthermore, your program is non-portable. Here's what my compiler had
> to say about it:
>
> Borland C++ 5.3 for Win32 Copyright (c) 1993, 1998 Borland
International
> SCOTT19U.C:
> Error SCOTT19U.C 4: Unable to open include file 'unistd.h'
> Error SCOTT19U.C 5: Unable to open include file 'pc.h'
> Error SCOTT19U.C 6: Unable to open include file 'keys.h'
> Error dstypes.h 2: Too many types in declaration
> Error bit19.h 15: Declaration missing ;
> Error bit19.h 16: Declaration missing ;
> Error bit19.h 17: Declaration missing ;
> Error bit19.h 18: Declaration missing ;
> Error bit19.h 19: Declaration missing ;
> Error bit19.h 20: Declaration missing ;
> Error bit19.h 21: Declaration missing ;
> Error bit19.h 22: Declaration missing ;
> Error bit19.h 23: Declaration missing ;
> Error bit19.h 24: Declaration missing ;
> Error bit19.h 25: Declaration missing ;
> Error bit19.h 26: Declaration missing ;
> Error bit19.h 27: Declaration missing ;
> Error bit19.h 28: Declaration missing ;
> Error bit19.h 29: Declaration missing ;
> Error bit19.h 30: Declaration missing ;
> Error bit19.h 31: Declaration missing ;
> Error bit19.h 32: Declaration missing ;
> Error bit19.h 33: Declaration missing ;
> Error bit19.h 34: Declaration missing ;
> Error bit19.h 35: Declaration missing ;
> Error bit19.h 35: Too many error or warning messages
> *** 26 errors in Compile ***
>
> So much for "years of use with no failings"! Now either go wash your
> mouth out and then apologise, or join yet another killfile (for I
> suspect that you are already killfiled by most right-thinking people).
But isn't DJGPP the only C compiler? hehehehe..
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Sun, 22 Oct 2000 19:21:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I state that is written for DJGPP. If you have other compilers
> you may have to change it. But the above is not an error it complies
> and runs under DGJPP C.
You mispelt "djgpp" on several occasions... hehehe
> >Furthermore, your program is non-portable. Here's what my compiler
had
> >to say about it:
> >
> >Borland C++ 5.3 for Win32 Copyright (c) 1993, 1998 Borland
International
> >SCOTT19U.C:
> >Error SCOTT19U.C 4: Unable to open include file 'unistd.h'
> >Error SCOTT19U.C 5: Unable to open include file 'pc.h'
> >Error SCOTT19U.C 6: Unable to open include file 'keys.h'
> >Error dstypes.h 2: Too many types in declaration
> >Error bit19.h 15: Declaration missing ;
> >Error bit19.h 16: Declaration missing ;
> >Error bit19.h 17: Declaration missing ;
> >Error bit19.h 18: Declaration missing ;
> >Error bit19.h 19: Declaration missing ;
> >Error bit19.h 20: Declaration missing ;
> >Error bit19.h 21: Declaration missing ;
> >Error bit19.h 22: Declaration missing ;
> >Error bit19.h 23: Declaration missing ;
> >Error bit19.h 24: Declaration missing ;
> >Error bit19.h 25: Declaration missing ;
> >Error bit19.h 26: Declaration missing ;
> >Error bit19.h 27: Declaration missing ;
> >Error bit19.h 28: Declaration missing ;
> >Error bit19.h 29: Declaration missing ;
> >Error bit19.h 30: Declaration missing ;
> >Error bit19.h 31: Declaration missing ;
> >Error bit19.h 32: Declaration missing ;
> >Error bit19.h 33: Declaration missing ;
> >Error bit19.h 34: Declaration missing ;
> >Error bit19.h 35: Declaration missing ;
> >Error bit19.h 35: Too many error or warning messages
> >*** 26 errors in Compile ***
>
> I can't help it if you use a poor compiler and don't
> have the smarts to make it fit the tools you have. I write
> for C in DGJPP. If you can't figure out how to mode it to
> work with your complier thats to bad. ALso in case you
> lack the brains to figure it out. THe code is targeted for
> a PC so if you have a MAC to bad.
Furthermore Borland C++ is a IBM PC based compiler. Second if you
wrote your code properly it should compile with little difficulty on
any suitable platform, not just DJGPP for ms-dos.
See if you posted a clear concise description of your algorithm, and it
seems worth it, others might code one for ya...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
