Cryptography-Digest Digest #21, Volume #13 Fri, 27 Oct 00 23:13:00 EDT
Contents:
Re: Why trust root CAs ? (Countersync)
Re: Applied Cryptography software. (Tom St Denis)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: DATA PADDING FOR ENCRYPTION (Bryan Olson)
Re: CHAP security hole question (Thomas Wu)
Re: Questions about DES (Steven Wu)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: Rijndael and PGP (SCOTT19U.ZIP_GUY)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: Questions about DES (Tom St Denis)
Re: ciphertext smaller than blocksize (SCOTT19U.ZIP_GUY)
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Countersync <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sat, 28 Oct 2000 02:18:02 +0100
On Fri, 06 Oct 2000 18:23:06 GMT, [EMAIL PROTECTED] wrote:
>
>OK, so you're off to do some e-shopping. You click on the padlock and
>it says "this certificate belongs to bogus.com" and
>"this certificate was issued by snakeoil CA" (no I don't mean
>the CA generated by OpenSSL, I mean one of the "normal" ones
>like verisign or thawte...).
>
>So, I can discover snakeoil CA's procedures for verifying bogus.com,
>and assure myself that they have checked out bogus.com.
>But how can I trust snakeoil CA itself ?
>I had a conversation with a CA on this subject and the answer was
>"because it's in the browser". But my browser was downloaded off
>the Internet in clear, and besides, do I really trust the browser
>vendor ? Do you trust Microsoft not to lie ? Do you trust Microsoft
>or Netscape to produce secure independantly verified code ?
>I have more faith in PGP/GPG, since the source code is open, I built
>it myself, and I can control who I trust. (OK, I can probably
>build Mozilla and OpenSSL ...)
>
>Is there a chain of trust from any institution that I might trust,
>such as my bank, back to the root CAs ?
>Is there any reason, apart from the fact that they've been operating for
>a number of years now and AFAIK nothing's gone wrong, for us all to trust
>the root CAs ? Apart from a general lack of trust leading the the end
>of e-civilization as we know it ?
>
>As a non-US citizen, I have a slight problem with most of the CAs and browser
>vendors being US corporations. If I were a member of some organization
>or country that the US regards as an enemy (Libya, Iraq ??) I might have
>a more serious problem with it.
Well this actually does interest me. The first thing that popped into
my mind was that the US government would back or prosecute the
corporations producing the certificates. However upon realizing that
the government is currently controlled by processes that are not
secure and reliable ( Hey in general people are stupid, un-informed,
ignorant, intolerant fuck-offs that shouldn't breath let alone bread.
).
Then I realized the same logic could be applied to any other
institution. In the end un-secure methods must be used first, then
those with the most trust are chosen to back the trusting system you
recognize. In the case of corporations and business I think the most
trusty source is "the better business beauro (sp?)" or some
equivalent.
However the sad fact is that there is currently no one that I would
trust to back such a system.
However I do trust one type of company/organisation for one thing. I
trust those that register domain names to track them. It's their pay
check, so they probably keep accurate records on who pays for it. I
could be persuaded to easily trust anyone that my ISP does for name
server accuracy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Applied Cryptography software.
Date: Sat, 28 Oct 2000 01:23:27 GMT
In article <01pK5.4114$[EMAIL PROTECTED]>,
"slak-" <[EMAIL PROTECTED]> wrote:
> Hi, I was wondering if it's legal (I don't want to rip anyone's
honest work
> off) to download the sources from "Applied Crytography" by Bruce
Schneier.
> I'm just a poor student, and spent the last of my cash on the book.
> I do live in America, in case anyone really cares about the NSA.
Please get
> in touch if you can, I'd be very interrested in checking them out.
> Thank you.
Turn to the back of the book and get typing....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Sat, 28 Oct 2000 01:28:42 GMT
James Felling wrote:
>
> Bryan Olson wrote:
[...]
> > I think the approach is misguided, for reasons
[...]
> Agreed. I was merely exploring the idea. I agree
> that this methodology is more trouble than it is worth
> at this point in time.
Understood; I guess I shouldn't have put all that in
a follow-up to one of your posts, since it could
mistakenly suggest disagreement. Thanks for your help.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: Sat, 28 Oct 2000 01:37:33 GMT
Tim Tyler wrote:
> Bryan Olson wrote:
> : [...] can you imagine someone so clueless as to expect his message
> : space won't have enough redundancy to cover a couple hundred (or
> : several thousand) bits of key equivocation?
>
> Surely it is *very* easy to imagine such a case.
>
> What about the man sending short messages, for example?
"Message" yes, that's what the OTP is all about. "Messages"
sounds he doesn't really have a grasp of the requirements for
information theoretic security.
> What about the man who forwards an encrypted message he has
> intercepted back to his HQ for decipherment?
Then he normally wouldn't even have a way to estimate
the redundancy.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: CHAP security hole question
Date: 27 Oct 2000 19:04:54 -0700
[EMAIL PROTECTED] (Vernon Schryver) writes:
>
> As far as I can tell, the claims at http://www.IntegritySciences.com/ are
> over the top. Maybe I'm wrong, but, for example, it strikes me as
> impossible make small secrets unguessable. Small secrets by definition
> need a small number of guesses to discover. It also seems to me that
As others have indicated in this thread, it makes a big difference
whether or not the attacker has to interact with a legitimate party
to test each guess, as opposed to interacting once and carrying out
the guessing attack offline.
> http://www.IntegritySciences.com/password.html gets the notion of
> challenge/response protocols such as CHAP wrong; the authenticatee in a
> CHAP exchange does not learn the secret if it was not already known.
There are many weak methods for password authentication. That page
describes problems with systems like SSH UserAuth or stelnet, which reveal
the password to the other party and risk compromising it if an
adversary tampers with the network or the server.
CHAP is weak in different ways. The ability for passive eavesdroppers to
brute-force passwords is an obvious one, and the plaintext-equivalence of
the server database is another.
> It's not that there are no problems with CHAP, what with the need for both
> parties (instead of only one as in PAP) to keep a private cleartext copy
> of the secret. (For years Microsoft falsely claimed that MS-CHAP does
> not involve cleartext copies of a password.) There are also some
> man-in-the-middle attacks, and other serious attacks involving the
> common practice of using the same secret for both peers.
>
> In other words, beware of technical information from sales people.
I'm curious as to what claims you don't agree with. I think it's pretty
clear these days that weak password systems are rapidly becoming a
weak link in the crypto chain, and that strong password systems should
be phased in to replace them in systems with any serious security
requirements.
> Vernon Schryver [EMAIL PROTECTED]
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Steven Wu <[EMAIL PROTECTED]>
Subject: Re: Questions about DES
Date: Sat, 28 Oct 2000 02:13:25 GMT
In article <8tboq3$cis$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8tbf4u$5lk$[EMAIL PROTECTED]>,
> Steven Wu <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I have some questions about DES:
> >
> > 1) Why DES do 16 iterations, no 15 or 17 ?
>
> Read about the differential and linear cryptanaylsis of DES.
Could you point me to some on-line resources about cryptanalysis?
Tks.
>
> > 2) Why people say, the choice of the primitive functions KS,
S1,...S8
> > and P is critical to the strength of an encipherment resulting from
> the
> > algorithm?
>
> Um because if you choose poor constructions biases could be found and
> exploited.
>
> > 3) Today, what are effective ways to attack DES ?
>
> Yea, brute force the keyspace.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 28 Oct 2000 02:13:54 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in <8tc87m$phb$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>>
>> :> If you folks check at comp.compression you we see a note
>> :> from Matt Timmermans on his super bijective PPM compressor
>> :> with a built in bijective RIJNDAEL in modied CBC mode.
>>
>> [...]
>>
>> :> http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
>>
>> : Perhaps us "know nothing" people prefer to leave our security to
>> : security related algorithms.
>>
>> I believe that's why the product includes a bijective version of
>Rijndael
>> - without that there would be no security at all.
>
>Of course Rijndael is bijective it's a friggin block cipher. You might
>as well qualify it as a Square-Based Symmetric Keyed Bijective
>Invertable Permutation Cipher.
>
Tom you always shot your mouth off with out little thought,
What other implementaion of Rijndael is really bijective.
Example the cipher text output file is one bye 0x13 decrypt
that with a the key of your choice using CBC. You can't unless
you hava similar program to MATTS I doubt you really understand
the concept.
rest of toms whinny useless crap deleted.
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: Rijndael and PGP
Date: 28 Oct 2000 02:23:21 GMT
[EMAIL PROTECTED] wrote in <8tciik$31q$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> I disagree strongly.
>Right there you've given enough information for a reasonable person to
>strongly agree. Of course it doesn't hurt that you have contradicted
>the statements of every major cryptanalyst, made a mockery of yourself,
>and been a pretender to the thrown for as long as I've been around.
>
I'm retired so I don't have to kiss ass. I am still allowed
to tell the truth. I have never been a pretender to the throne
other than the poreclen white goddess when I had to much beer.
But you seldom see real cryptanalyst post here. Unless you belive
the those hawking there own books.
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: BEST BIJECTIVE RIJNDAEL YET?
Date: 28 Oct 2000 02:18:29 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 27 Oct 2000 12:43:31 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote, in part:
>
>> I have never seen you take the middle road.
>>Matts code does both for those that think Rijndael is secure.
>>He has it. For those that want no added crap add to file so an
>>attacker can take advantage of it his has that. It has great
>>compression. It is a great tool of one wants to add others
>>things after it. It is like having your cake and eating it too.
>
>> I suggest you try it. I am sure your socalled middle of
>>the road approach is to badmouth it with out looking since I
>>suspect your quadrathing does not yet exist as working code
>>that is bijective.
>
>Oh, I'm quite happy with Mr. Timmermans. And my scheme isn't
>bijective, since it uses random padding. But that has nothing to do
>with my block cipher designs - which are intended to be instructive
>about cipher design. Clear diagrams and explanations enable them to
>fulfill that purpose.
>
Well maybe some day you can fix it so its a nice stand alone
module that does hide behind the so called "random" features.
However it is easy to add random data to Matts it just is not
a requirement like in your system. Not having it as a requirement
means there is a lot more flexabiltiy in how to add. I have another
post that shows one such way using Matts bijective program as
a vital component.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Questions about DES
Date: Sat, 28 Oct 2000 02:17:31 GMT
In article <8tdco2$ote$[EMAIL PROTECTED]>,
Steven Wu <[EMAIL PROTECTED]> wrote:
> In article <8tboq3$cis$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <8tbf4u$5lk$[EMAIL PROTECTED]>,
> > Steven Wu <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > I have some questions about DES:
> > >
> > > 1) Why DES do 16 iterations, no 15 or 17 ?
> >
> > Read about the differential and linear cryptanaylsis of DES.
>
> Could you point me to some on-line resources about cryptanalysis?
> Tks.
www.counterpane.com/labs.html
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ciphertext smaller than blocksize
Date: 28 Oct 2000 02:55:15 GMT
[EMAIL PROTECTED] wrote in <8tceql$vic$[EMAIL PROTECTED]>:
>[snip how to create smaller block ciphers from large block ciphers]
>Outside of using the full block cipher to create a stream pad, I can
>see no way. I can see no way because of the diffusion involved in the
>cipher, so to reconstruct 1 bit you MUST know all the bits in the
>ciphertext, this makes it fairly improbably that you could reconstruct
>the plaintext from the ciphertext without possession of the full block.
>
>If what you want to do is create a block aligned system, where the data
>may or may not be aligned on the block boundary. That's actually fairly
>simple. There're many ways to do it, from padding out the block with
>randomness, and adding a second block where the only bits that aren't
>random designate how much of the previous block weren't random, to
>padding with a 1 followed by 0s to fill the block, to padding the block
>with the number of bytes in the block that weren't used (adding a full
>block if necessary), to simply putting the length at the head of the
>stream.
> Joe
Putting the lenght in is a waste since it would give information
that is valuable to an attacker. Matt has completely sovled this in
his bicom program it handles all file with unique mappings. No problem
no information added to file.
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: Is OPT the only encryption system that can be proved secure?
Date: 28 Oct 2000 02:45:06 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>Richard Heathfield wrote:
>
>(Sorry to reply to my own post: I forgot to post my source code. Can't
>have Mr Scott thinking the worst, can we?)
I guess your not perfect then.
>
>> "SCOTT19U.ZIP_GUY" wrote:
>> >
>> > The hardest part of scott19u was placing the file in memory and
>> > overlaying on it in various 19bit continuous strurctures that have
>> > different origins that are not offset by 19bits. I really don't
>> > see how to do this in other versions of C.
>>
>> I did in fact make a start on writing my own implementation of your
>> algorithm, reverse engineering it from your source code, but I gave up
>> in disgust. Make of that what you will; your opinion is of no value to
>> me. Nevertheless, before I gave up on it, I had written functions to
>> extract an n-bit integer (for n <= the number of value bits in an
>> unsigned int) from any location in a bit array, and similarly to insert
>> an n-bit integer into any position in a bit array, in 100% portable ISO
>> C. It's not difficult.
>>
>
>Well, I forgot to include the source code for n (<= value bits in an
>unsigned int) bit storage. Here it is, complete with a test driver:
>
>#include <stdio.h>
>#include <limits.h>
>
>#define SET_BIT(a, n) (a)[(n) / CHAR_BIT] |= (unsigned char)(1U << ((n)
>% CHAR_BIT))
>#define CLEAR_BIT(a, n) (a)[(n) / CHAR_BIT] &= (unsigned char)(~(1U <<
>((n) % CHAR_BIT)))
>#define TEST_BIT(a, n) (((a)[(n) / CHAR_BIT] & (unsigned char)(1U <<
>((n) % CHAR_BIT))) ? 1 : 0)
>
>/* Debugging function, used for printing len * CHAR_BIT
> * bits from s.
> */
>int print_bits(unsigned char *s, int len)
>{
> int i, j;
> for(i = 0; i < len; i++)
> {
> for(j = 0; j < CHAR_BIT; j++)
> {
> printf("%d", TEST_BIT(s, i * CHAR_BIT + j) ? 1 : 0);
> }
> printf(" ");
> }
> printf("\n");
> return 0;
>}
>
>unsigned int BitsInUnsignedInt(void)
>{
> static unsigned int answer = 0;
> unsigned int testval = UINT_MAX;
> if(answer == 0)
> {
> while(testval > 0)
> {
> ++answer;
> testval >>= 1;
> }
> }
>
> return answer;
>}
>
>/* This function gets the Indexth n-bit unsigned int field from the bit
>array. To do this, it builds the
> * unsigned int value bit by bit.
> *
> * Example call:
> *
> * unsigned int val;
> * val = Get_nBit_Int(MyBitArray, this is the base address
> * 19, get a 19-bit number
> * 13, get the 14th number (0 to max - 1)
> * 7); skip 7 leading bits at the start of
>the array
> *
> */
>unsigned int Get_nBit_Int(unsigned char *BitArray,
> unsigned int n,
> unsigned int Index,
> unsigned int BaseBit)
>{
> unsigned int Value = 0;
> unsigned int j;
> unsigned int i = Index * n;
>
> if(n <= BitsInUnsignedInt())
> {
> i += BaseBit;
> BitArray += i / CHAR_BIT;
> i %= CHAR_BIT;
>
> for(j = 0; j < n; j++)
> {
> /* Move the populated bits out of the way.
> * Yes, this means that the first iteration
> * of the loop does a useless shift. I think
> * I can live with that. :-)
> */
> Value <<= 1;
>
> /* Populate the low bit */
> Value |= TEST_BIT(BitArray, i + j);
> }
> }
>
> return Value;
>}
>
>void Put_nBit_Int(unsigned char *BitArray,
> unsigned int n,
> unsigned int Index,
> unsigned int BaseBit,
> unsigned int Value)
>{
> unsigned int j;
> unsigned int i = Index * n;
>
> if(n <= 32)
> {
> i += BaseBit;
>
> BitArray += i / CHAR_BIT;
> i %= CHAR_BIT;
>
> j = n;
> while(j--)
> {
> /* Use the rightmost bit */
> if(Value & 1)
> {
> SET_BIT(BitArray, i + j);
> }
> else
> {
> CLEAR_BIT(BitArray, i + j);
> }
> /* Throw the rightmost bit away, moving the next bit into
>position. On the
> * last iteration of the loop, this instruction is pointless.
><shrug>
> */
> Value >>= 1;
> }
> }
>}
>
>int main(void)
>{
> unsigned char test_array[9] = {0};
>
> print_bits(test_array, 9);
> printf("Storing the 19-bit value 0x7FFFF starting at bit 3.\n");
> Put_nBit_Int(test_array, 19, 0, 3, 0x7FFFF);
> print_bits(test_array, 9);
> printf("Retrieving the 19-bit value starting at bit 3: %X\n",
>Get_nBit_Int(test_array, 19, 0, 3));
> printf("Storing the 19-bit value 0x7EDCB starting at bit 3 + (2 *
>19).\n");
> Put_nBit_Int(test_array, 19, 2, 3, 0x7EDCB);
> print_bits(test_array, 9);
> printf("Retrieving the 19-bit value starting at bit 3 + (2 * 19):
>%X\n", Get_nBit_Int(test_array, 19, 2, 3));
>
> return 0;
>}
>
>Here's the Borland C++ compiler output:
>
>C:\scratch>bcc32 -A bitplay.c
>Borland C++ 5.3 for Win32 Copyright (c) 1993, 1998 Borland International
>bitplay.c:
>Turbo Incremental Link 3.0 Copyright (c) 1997, 1998 Borland
>International
>
>Here's the Visual C++ compiler output:
>
>Compiling...
>bitplay.c
>Linking...
>
>bitplay.exe - 0 error(s), 0 warning(s)
>
>Here's the DJGPP output:
>
>C:\scratch>gcc -W -Wall -ansi -pedantic -o bitplay.exe bitplay.c
>
>(i.e. no diagnostics - and it produced the correct binary.)
>
>Here's the gcc output on Linux:
>
>[rjh@arc11] /home/rjh/bitplay > gcc -W -Wall -ansi -pedantic -o bitplay
>bitplay.c
>[rjh@arc11] /home/rjh/bitplay >
>
>
>And here's the program output (Windows console):
>
>C:\scratch>bitplay
>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00000000
>
>Storing the 19-bit value 0x7FFFF starting at bit 3.
>00011111 11111111 11111100 00000000 00000000 00000000 00000000 00000000
>00000000
>
>Retrieving the 19-bit value starting at bit 3: 7FFFF
>Storing the 19-bit value 0x7EDCB starting at bit 3 + (2 * 19).
>00011111 11111111 11111100 00000000 00000000 01111110 11011100 10110000
>00000000
>
>Retrieving the 19-bit value starting at bit 3 + (2 * 19): 7EDCB
>
>
>Here's the output on Linux:
>
>[rjh@arc11] /home/rjh/bitplay > ./bitplay
>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00000000
>
>Storing the 19-bit value 0x7FFFF starting at bit 3.
>00011111 11111111 11111100 00000000 00000000 00000000 00000000 00000000
>00000000
>
>Retrieving the 19-bit value starting at bit 3: 7FFFF
>Storing the 19-bit value 0x7EDCB starting at bit 3 + (2 * 19).
>00011111 11111111 11111100 00000000 00000000 01111110 11011100 10110000
>00000000
>
>Retrieving the 19-bit value starting at bit 3 + (2 * 19): 7EDCB
>[rjh@arc11] /home/rjh/bitplay >
>
>
>As you can see, this is a 100%* portable method of mucking about with
>n-bit numbers. It also obsolesces your p19, op19, pf19 and pb19 types,
>because everything can now be treated as an array of unsigned char (i.e.
>just bits).
>
>I expect you're too advanced a programmer to think of such simple ideas.
>Much cleverer to write absolutely shedloads of overly complex and
>non-portable tripe rather than a few lines of simple portable stuff.
>
>Now, this is the very part of the program that you said was impossible
>to port, and I've proved that it's easy. So go and make your program
>portable and readable, and perhaps then people will consider
>cryptanalysing it. Otherwise, for goodness sake stop crowing about it.
>It's slow, unwieldy, unanalysed, and a pig to use. Even CDX-2 is orders
>of magnitude faster, and I thought /that/ was slow. I fail to see why
>you think it's so great.
>
>
>[*Actually, I haven't proved it's 100% portable at all. I've just proved
>that it's portable to two versions of gcc, two other compilers, and two
>operating systems, with full diagnostic checking providing no
You proved you have a few functions that MIGHT work.
But I agree what you have seems to compile without warnings
which you seem to value highly. Wether they work in my porgram
or not is another question. And wether they are faster is still
yet another question.
>diagnostics at all on any of the platforms. But I challenge you to find
>anything non-portable at all in it.]
>
I can't say it completely works more tests would have to be done.
However if it does work and takes not to much more time wise I may
include something like this as an option to my specail include file.
I saved the file and will look at it when I get to it. But I have to
warn you people made numberous comments on scott16u most where wrong
about how it worked. And what people said would work faster did not.
But I can see that for most C's there will be an implementation
problem in general so this might great help to someone interesting
in converting it to another compiler. Thanks!
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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
