Cryptography-Digest Digest #103, Volume #11 Sat, 12 Feb 00 02:13:02 EST
Contents:
Re: Message to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Twofish vs. Blowfish (SCOTT19U.ZIP_GUY)
Re: Eurocrypt 2000 (Hideo Shimizu)
Re: Twofish vs. Blowfish (David Hopwood)
Re: BASIC Crypto Question (David Hopwood)
Secret sharing/threshold schemes (was ... Reconstruction of XORd data) (David
Hopwood)
Springer-Verlag CD-ROM (was Re: I'm returning the Dr Dobbs CDROM) (David Hopwood)
Re: Newbie Encrypt question (Johnny Bravo)
Re: Which compression is best? (David Hopwood)
Re: RFC: Reconstruction of XORd data ("Rick Braddam")
Re: Bounding (p-1)(q-1) given only knowledge of pq ("Joseph Ashwood")
A QuickBASIC Cryptographer ("Brian Bosh")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Sat, 12 Feb 2000 05:52:09 GMT
In article <[EMAIL PROTECTED]>, DTRuth <[EMAIL PROTECTED]> wrote:
>So how would this work.
>
>You compress with Compressor A
>Encrypt with Block Cipher A ( Key kA)
>Compress with B
>Encrypt with Cipher B (Key kB)
>Compress with C
>Encrypt with Cipher C (kC)
>
>
>Then to decrypt:
>Decrypt with Cipher C (kC)
>Decompress with Compressor C
>Decrypt with Cipher B
>Decompress with Compressor B
>Decrypt with Cipher A
>Decompress with Cipher A
>
>
>Hopefully you are back where you started ??? Right???
That would be nice since that is what is hoped for.
>
>
>And what about the Compressors A, B,C
>
>Is it the same Compressor?
They could be the same compressors as long as they
are one-one compressors. And even better if they can reverse the
byte order of the file.
>
>And why three Encryption's, why not two or five layers or chains???
I guess I felt 3 good enough. I still think the whole thing was in
response to some comments that occured at the time about using
multiple encryption. One has to be careful that an attacker can't strip
off the layers of encryption indepently.
Better yet learn how to do "wrapped PCBC" in which case just compress
intially and do at least 3 passes of the "wrapped PCBC chainning useing
your choice of AES block ciphers with independent keys.
Part of the whole point of this is that one does not need to get tricked
into using the AES ciphers as a standalone encryption where it will be
easy for the NSA to break. IF one is stuck using them one should try
to find a way of using them in a way not to make it easy for the NSA
to break it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Twofish vs. Blowfish
Date: Sat, 12 Feb 2000 06:03:40 GMT
In article <882k0i$b7l$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
>> Actually I suppose that you could get the same sort of developmental
>> behavior by using an "encryption algorithm" that you make up yourself
>> and is trivial. It doesn't have to be secure; it just has to have
>> the right interface and scramble the data at least a little, so as
>> to support testing.
>
>From a software-engineering point of view, this is pretty scary advice.
>The lesson of the Kerberos -- and Netscape -- key generators is that
>you *will* forget and leave it in your published product once, and if
>you're particularly unlucky, noone may realize it for years.
>
>(In case you hadn't heard of the Kerberos case, they initially put in
>a really insecure key-generator just to get things working. They knew
>it was bogus and had intended to replace it. Indeed, they even did replace
>it in one code base. But somehow the patch that installed the secure
>key-generator got lost or overlooked somehow in the shuffle, and so it
>turned out that Kerberos had been using the insecure key-generator for
How would one prove that the key-generator got lost or overlooked
is it not possible this over sight occured due to the NSA greaseing the
right palms. I think it is a safe bet that many of the "flaws" in the micro
soft junk is there becasue the NSA wants them there.
>years. It was only discovered after flaws were found in the Netscape
>key-generator and someone thought to check out Kerberos to see if it was
>safe. And that was before the time pressures of "Internet time"!)
>
>I often find the creative ways that Murphy's Law finds to bite you in
>the butt quite awe-inspiring. Why take chances?
If you don't want to take chances then would you use or trust
the AES stuff with your life. You might want to take that chance
or maybe like your boss you may have to say you would. But I
would not trust it with any thing that needed to be secure.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Eurocrypt 2000
Date: Sat, 12 Feb 2000 14:07:58 +0900
David A Molnar wrote:
>
> Eurocrypt 2000 <[EMAIL PROTECTED]> wrote:
> > A provisional program (list of accepted papers), and all
> > registration details and accommodation information can now
> > be found on the conference web site:
>
> > http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
>
> One title leaps out at me :
>
> "Cox-Rower Architecture for Fast Parallel Montgomery Multiplication"
>
> Can't wait to read that one! :-)
I have read preliminary version of their paper in Japanese.
They develop new improvement for parallel computation algorithm for
Montgomery multiplication using residue number system (RNS).
Their algorithm can achive about 1Mbps for 1024bit RSA.
Please don't ask me why so fast. I do not understand their architecture.
Hideo Shimizu
TAO, Japan
>
> -David (a 3 seat)
>
> also "How to Break a Practical MIX and Design a New One" - given the
> authors, wonder if it has anything to do with subliminal channels??
------------------------------
Date: Sat, 12 Feb 2000 04:39:05 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Twofish vs. Blowfish
=====BEGIN PGP SIGNED MESSAGE=====
Eric Lee Green wrote:
>
> John Myre wrote:
> > Why wouldn't it be legal to use during development? AFAIK, patents
> > are only relevant once you start to sell it (or the equivalent).
More precisely to distribute it (free products can infringe patents), or
to use it to provide a service to others.
> No. Mere possession of a patented item without a license is illegal,
> whether or not you intend to sell such item.
This is wrong; implementation of patented technology for your own use or
during development is not illegal, under most countries' patent laws
(including EU countries and the US).
(OTOH, I quite agree that it would probably be better to use Twofish, or
possibly Rijndael, for development instead - for a start I think these
have a better chance of winning. Rijndael is as easy to implement as RC6.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKS6XTkCAxeYt5gVAQFA2Af+JoUSsI7gTLP4PjUZXes3e6j7YDju5emM
9H6wmYDrwr5J7ggJhlghuZ8vbxrAu/aZRl1nhalRoLZUFEvfdAE+ss5JjI1eoEn5
giO8lpWWmgnIkpkDNKv1RcXqhUnG1gbr1eeCtul6vwsTfPOlPd/ulFSDWNqmGFUt
jkdaj/9E+kcYYfk5iJIhCAI/vapCJB77q3q/Q0ctrPYlquv20WqCy1Fc/GhFcMet
gouqoRS2pFYgSu6v5t2PB17XdEaoQhnrxI5vrTwv2qRl1rEqV5OTcdhaf7F574FP
xpb1RwYzIW6GqwSeQD4O8oT/vX3Z/3wY5eGQHRFvM2Bgip8Pho4Ssg==
=bUcN
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 12 Feb 2000 05:45:13 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: BASIC Crypto Question
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>
> Am I right to assume that Ciphers (Block and Stream Ciphers) work at
> the bit level, regardless of what the data structure/format is of the
> document file.
Technically, most use plaintext, ciphertext and keys that are sequences
of octets, where an octet is an 8-bit byte. The ordering of bits within
octets is transparent - i.e. it doesn't matter - for most programming
languages and operating systems designed since Unix.
> This would imply that with the same cipher (DES, IDEA, Blowfish), I can
> encrypt documents, images ( .jpeg, .jif, .bmp ) , .wav files, email
> attachments, word documents, .xls documents, .pdf, .ps,
> .tar, .gz, .zip...whatever... is that right? The cipher only sees
> bits...
Yes.
> So for an email text with an attachment, I would encrypt both separately
> and lump them together? or should one merge two files of different
> formats together in one file?
You would do whatever the standard you're working to says. E.g. the most
commonly used standards for email encryption are OpenPGP (or PGP/MIME)
and S/MIME.
PGP/MIME and S/MIME encrypt the whole MIME message apart from the header;
for versions of PGP not compatible with PGP/MIME there is no easy way to
encrypt or sign a message that includes attachments, unless you encrypt/
sign them separately.
> Are there some ciphers more suited to say image and formated documents
> encryption, whereas others more suited to text...Or is it all bits and
> bits...nothing else to consider?
It is normally just octets (for ciphers designed for use on computers,
anyway).
That's not to say that the encoding of the plaintext is completely
irrelevant to security; if you have a choice of plaintext format, it's
best to choose one that is not excessively redundant (i.e. does not
contain too much unnecessarily predictable information), and compressing
the plaintext may help slightly. However, this advice applies equally
to all ciphers.
There are one or two computer ciphers that allow arbitrary bit sequences
rather than octet sequences (e.g. HPC), but it's an absolute pain to
design interfaces that make use of this. In the very few cases where bit
sequences are needed, it's generally better to handle them in a higher-
level standard (i.e. have that standard define a convention for padding
the last 0 to 7 bits), rather than making it part of the cipher.
There are also some computer ciphers that work on words (e.g. SEAL uses
32-bit words for plaintext and ciphertext), without defining a byte order,
i.e. big- or little-endian. In the case of SEAL this is for efficiency, to
allow an application or higher-level standard to choose or negotiate the
most efficient order for the hardware being used (whether this is really
a good idea is debatable).
> Obviously data mapping is important...
Data mapping is important, but if you're just implementing an application,
it's usually a good idea to rely on some existing standard to define it
wherever possible.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKTy/zkCAxeYt5gVAQHGgAgApBzsnNwbrakhqY66rbeExv45tBmigsOw
EjUvFywx1L3VYxxeTYZunSc4liujNm3Cu68ULg41JKNTuPQfYHnFliLsq+SCdA0H
8GqpHMbiEyz+oNtbwhkHR4gQ3NhfNMNL/REdr96iWsJfdrd66HkiTMGY5Hpi1sTU
Riu8Qx575nwyA3L3Ishp7uXlXVrHH2wZ4SSuEf8HLUTi8P7pA1UuJ4B7UZ6NcMqo
oGPXm0cqHCSpvClNX3A6MRFqmdl4y0kKNRhWM47DQUmM4tuFnRXpxTLK87Kwcitw
9syfy4i5RGwbzKaFbmtBDsFowLGp30/NVyHtUt3t4tE6NpnLIZJe5Q==
=UjYR
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 12 Feb 2000 04:38:21 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Secret sharing/threshold schemes (was ... Reconstruction of XORd data)
=====BEGIN PGP SIGNED MESSAGE=====
Ian Clarke wrote:
>
> Hi,
>
> In an attempt to split data into several parts in such a way that each
> part would be useless without the others, I came up with a simple
> algorithm which I would like to expose to public scrutiny.
It sounds like what you're trying to do is secret sharing, a.k.a. a
"threshold scheme"; it's a well-studied problem (since at least 1979,
and arguably much longer). The algorithm you proposed is completely
insecure for this purpose, though.
A better method is to generate a cryptographically random sequence of
bytes of the same length as the data to be protected (read RFC 1750 for
information on generating cryptographically random sequences; it is not
at all trivial, and it's a good idea to use an existing random number
generator designed for that purpose, such as /dev/random on Linux or
FreeBSD, or "Yarrow" on Windows).
Suppose the data is M and the random sequence is R1, the two pieces of
the data (called "shares") will be R1, and R2 = R1 XOR M (i.e.
corresponding bytes of R1 and M are XOR'd, giving an output of the same
length as R1 and M).
If you need n shares, generate random sequences R1, ... R{n-1} each the
same length as M, and let Rn = R1 XOR R2 XOR ... XOR R{n-1} XOR M.
To recover the data, just XOR together all the shares.
If it is inconvenient for the shares to be as long as M, you can use a
secret key in place of M in the secret sharing scheme, and encrypt M
using this key (e.g. using a block cipher in CBC mode). The ciphertext
does not have to be kept secret; unless an attacker has access to all of
the shares, he/she will only be able to find the length of M, not its
contents.
For the scheme described above, all of the shares are needed to reconstruct
the original data. There are ways to construct provably secure "n out of m"
threshold schemes, in which there are m shares, but only n of them are
needed in order to reconstruct the data (the first to be designed, and
the most widely known of these is Shamir's threshold scheme). If it is
possible that one or more of the share holders might try to cheat, by
lying about their share so that they will be the only participant(s) to
recover the data, there are also schemes that can prevent or detect this.
Other things you might want are the ability to add or remove shares
after the scheme has been set up, or access requirements that are more
complicated than "n out of m".
If any of these extra properties would be useful, give us more information
about the application, and we can recommend something suitable.
> This is a small part of a much larger project called "Freenet", learn
> more at http://freenet.sourceforge.net/.
I'd strongly recommend that you discuss the design of any cryptographic
parts of this project on sci.crypt.
- - --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKTjNDkCAxeYt5gVAQG2UggAtxTGk3UJQI1uQREOIn9yfFTcAHh3/2O1
+Y5wfgSEVJFeO8mMtV2w/JNctEuOZCvdZ6tHtaOx6Cc3/GrFApmjBA0X50KRHX55
gjIftd6MsG6Eu9Kp501+j8/5R3FmlSypgykb8dQeh7ufutQHnM+o0k6frZiku/g6
9zSTozJlAAxobdsCxmK1LY3F/z2ZbByWlsPm4o/Pa+cOKHRuVxFUDhHzILQloBYO
yOOcQV1sOZaJR+6/qorBEzPkdHBiSw1pw2dCpK4w4udhWRnnCCKZ0Et/VEhS/wNd
KUkRSsN4YLDHLw42vhgHsJwLTnc0KdYr/ShbMFZRc32CJvrHiXZaNg==
=STL9
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 12 Feb 2000 00:31:04 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Springer-Verlag CD-ROM (was Re: I'm returning the Dr Dobbs CDROM)
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>
> Paul Koning <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
>
> >> In my briefcase I can carry [...] the about 20 years of CRYPTO and
> >> EuroCrypt proceedings (CD-ROM available through Springer-Verlag),
>
> > How did you get that one? I tried to order it via their website, and
> > the order was redirected to some random company I'd never heard of
> > somewhere in the US, and I've never heard anything since.
>
> Both Amazon.com and BN.com (Barnes & Noble) list it. Despite some
> serious reservations about giving business to amazon, that's where I
> got mine because they said they could ship within 24 hours -- bn.com
> said it might take several weeks...
Same here, except that it didn't appear to be available from the UK or
US sites, so I went through their German site (amazon.de). However,
amazon.de said they would ship it in 2-3 days, and actually took a couple
of weeks. I'd advise trying again with Springer-Verlag directly first.
The scanning is well done; there are a few minor glitches but nothing
that prevents reading any of the papers (although I would have preferred
that they use generated rather than scanned PDF for the papers that were
originally prepared using LaTeX). Printing and the Java text search applet
work fine, although text can't be cut-and-pasted.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKSpfDkCAxeYt5gVAQERkgf+JKVKAL5YiCIVN95xD5LwxOkYnZnDNAxk
K5KJxmbUbPQv1AtUw7N2+JjAvX6Sj8LrGnL4wJ6DdH2uLleMu8a+8AMIZ7cXH8C7
BibJi2217c8c5ITRgwlzJpjeOgLDVdC8WZHH2+GI85lE+4Kbawf6H+rMrIJ9VP9T
8LUJp90u4i/HB9smU53jyyQj9u7nIq3UfPf+rCV1wUjeyzHFbz3FXNi7cJ5x4wVl
uIS01V1Ql8kVek0OyeCKVDwpmfttHmImUuqEbr7x3ftyQtevOdn74t3ddz0QlfjD
7yQ2VzmMN/scB2nH0lu9TcIP8iy3h8juAL8DS/hQ4dAunft2J+ktfA==
=tAba
=====END PGP SIGNATURE=====
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Newbie Encrypt question
Date: Sat, 12 Feb 2000 01:05:18 +0000
On Fri, 11 Feb 2000 21:30:29 GMT, [EMAIL PROTECTED] wrote:
>Let me ask this then (last question I promise, at least for today :-))
>I found some source code to RC5. Question is, is that patented stuff?
>Or can I use it/play with it for my own use?
Since you wanted to write your own, try CipherSabre, it's ARCFOUR (RC4).
The CipherSabre page explains exactly how it works and lets you write your
own source code, with pages to help understand exactly what is going on.
It also explains some of the security concerns. It should take less than
one evening to get a working implementation, there are test files
available on the site as well to ensure it is working correctly.
http://ciphersaber.gurus.com/
Best Wishes,
Johnny Bravo
------------------------------
Date: Sat, 12 Feb 2000 06:23:30 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Which compression is best?
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>
> As I've read here, it's good to compress before you encrypt the data.
As a general rule it is, unless the data is very small. Certainly it's
pointless to compress *after* you encrypt the data, since ciphertext
is normally incompressible.
> Now I've got 2 questions about this:
>
> 1) From a security perspective, how important is compression?
Hardly important at all. There *is* a security improvement from
compression, but it should be looked at as just a bonus that doesn't
relax the requirements on the encryption algorithm. Also if there are
sound reasons not to use compression in your application (for example
severe memory or time constraints), don't worry about this weakening
security. This assumes that you are using a well-respected modern
cipher such as Blowfish, CAST-128, Triple-DES, or a 2nd round AES
candidate, in a mode such as CBC that hides patterns in the plaintext -
which you should be doing anyway.
> Is prior compression just a kind of "weak enhancement" or is
> considered it an integral part of the encryption process as a whole?
The former.
> 2) Are there special compression algorithms that are specifically well-
> suited in combination with block cyphers?
There are a couple of regular posters to this newsgroup that have a bee
in their bonnet about this, and will no doubt answer that you should
use their favourite compression algorithm or technique (in fact I see
that David Scott has already done so).
Don't, for the following reasons:
- although possibly less so than cryptography, compression is still
a specialist field in which it is very difficult for newcomers to
design an efficient or effective algorithm.
- "one-on-one" or "bijective" compression doesn't actually achieve
the theoretical security benefits that are claimed for it in a
typical (or arguably any) practical application.
- the current algorithms and implementations of these techniques are
very inefficient and not well-tested.
I would use DEFLATE (described in RFC 1951). It has a robust, well-
documented free implementation (the zlib library, at
http://www.cdrom.com/pub/infozip/zlib/), and is quite fast and
effective for byte-oriented data. Also, although the importance of
avoiding known plaintext is sometimes exaggerated, it is still a valid
consideration, and DEFLATE lacks headers that would introduce extra
guaranteed known plaintext.
Note that for any adaptive compression algorithm, the compression ratio
tends to improve as you process more data under a single compression
context; this is something to consider when designing your system.
(The flip side of that is that you normally have to decompress data
compressed under a single context sequentially, starting from the
beginning.)
> Is any of the standard algorithms as good as the other? (I don't mean
> in compressing of course, but in security matters dependant on my
> first question).
There are security and other advantages in using a standard algorithm
and a well-tested implementation (in particular one that is robust when
given invalid compressed data); also, if you are in a highly speed-
constrained environment, using a fast algorithm might give you more time
for the cryptography. Other than that, it doesn't really matter very much.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKT8HjkCAxeYt5gVAQGuBQgArdsfUwBVTUTxkwutznAGaoMgluyPIy3O
unMTOqZr6/2LUYo6VPPN9W7NAABWHkUN9347pDKJ7MAg6jiExpXZstptC/Ee6iWi
VXlhGLvt+zY5BhNCYP5oEmq9bxb1FdFFvf3w2sLEvvj9RjSV060QgWTT8JHrUfNK
58UF5pSunbnASnsvFfaZk2DvVs5CYpib/JoEEtrOuPTN2ZePLRWsdFbTH5O31DJU
E/ir/ugl6C2Mb99hBTxWQiL/hJenK6bw+tjtEqM7Gntywc4PNq7e1jZzjBrK9X7E
kc/s/e8RqeRHa9OrsgSzEwzjbVySDmMct87g4NfUhZnUGtU3RuYChw==
=9p9R
=====END PGP SIGNATURE=====
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Sat, 12 Feb 2000 00:12:27 -0600
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:882k6a$b89$[EMAIL PROTECTED]...
]
] Experiments show that English has only a few bits of entropy per
] character (the figure I remember is 2 bits, but I could be
misremembering).
] Consequently, speaking from a purely information-theoretic
perspective,
] one would expect that either of those strings is more than enough to
] reconstruct the plaintext.
What do you think of this, David? I came up with it to spread out the
bit changes in ASCII text. The high-order nibble of 8-bit ASCII is 4, 5,
6, or 7 a large part of the time, while the low-order nibble goes
through all 16 values (some values used much more often than others,
though).
The description is in terms of x86 assembler, because the carry bit (cy)
can be used to hold bits shifted out of a source register(src1, src2),
and supply bits shifted into a destination register (dest1, dest2). SHR
shifts a register right, shifting cy into the MSB and shifting the LSB
into cy. SHL shifts left in the same way...cy->LSB, MSB->cy. Half the
bits in src1 and src2 will be interleaved into dest1, the remaining bits
into dest2. src1 is shifted right and src2 shifted left. We also need a
register for counting bits (cntr) and a constant (cnt) =
RegisterBitWidth/2. It goes like this:
clc ; clear the carry flag. Not really
needed.
mov src1, [data]
mov src2, [data + 4] ; use 2 for 16 bit regs, 4 for 32 bit regs, 8 for
64 bit regs
mov cntr, cnt ; we'll be moving 2 bits per iteration to dest
regs
loop1:
shr 1, src1 ; shift LSB of src1 into carry
shl 1, dest1 ; shift carry into dest1
shl 1, src2 ; shift MSB of src2 into carry
shl 1, dest1 ; shift carry into dest1
dec cntr
jnz loop1
mov cntr, cnt
loop2:
shr 1, src1 ; same as for dest1
shl 1,dest2
shl 1, src2
shl 1, dest2
dec cntr
jnz loop2
end
The calling function would be responsible for padding source strings to
a multiple of the register length. If we assume null-terminated strings,
the padding could be nulls (0).
I've run this on Ketman's assembly-language interpreter. How's that for
quick and dirty testing, just like Basic, only better. The output don't
look much like ASCII. The first two bytes of dest 1 come from the last
byte of src1 (counting left to right) and the first byte of src2. They
could be the reverse-interleave of a digraph. The next two bytes come
from bytes separated by two bytes, the first two of dest2 come from
bytes separated by four bytes, and the last two bytes of dest2 come from
bytes separated by six bytes.
Well, that's it. I haven't tested this with files yet. I am hoping that
if there is any reason why it wouldn't work, someone here would tell me
and I wouldn't have to waste a lot more time by running files through
it.
I don't expect this would help much on binary files, but it seems like
it should hinder analyzing the ciphertext of text files, perhaps as a
whitening step for a classical cipher. Would this be any good for
anything?
Rick
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Bounding (p-1)(q-1) given only knowledge of pq
Date: Fri, 11 Feb 2000 22:28:28 -0000
> Can you mention one?
While I can't think of one off hand that would be of this
type. If the real d was known to be contained in a list of
numbers, it may require less compute power since much of the
overhead of my observation does not require d and could
therefore be done once far all possibilities. The result is
that two multiplications and 2 divides are needed for each d
plus some fairly static beginning computations. Even given
an exponent of 2^16+1 requires 16 multiplies (O(nlogn) and
one add (O(n)). Since division can be done quite quickly in
binary using trial subtraction (O(n^2) perhaps there's a
faster way that doesn't come to mind right now, as e grows
the variables tip to the favor of my observations. The
number of d is of little consequence except in being able to
ignore the setup time, but the size of d does matter.
The trial exponentiation takes:
O(length(d)*length(e)*nlogn + E) time
where 4 <= E <= length(d)*length(e)*n
The method I proposed takes
O(2n^2 + 2nlogn) time
considering that e has to be increased as pq are increased,
the algorithm will become of more use.
Joe
------------------------------
From: "Brian Bosh" <[EMAIL PROTECTED]>
Subject: A QuickBASIC Cryptographer
Date: Sat, 12 Feb 2000 00:00:25 -0700
Can someone please review this, and tell me of any errors or bugs you find?
It's encrypting is based of ASCII Values. E-Mail me for more into.
http://becubed.cjb.net/tsh
Brian
------------------------------
** 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
******************************
