Cryptography-Digest Digest #94
Cryptography-Digest Digest #94, Volume #11 Fri, 11 Feb 00 07:13:01 EST
Contents:
Re: Have you watched the movie "PI" (actually a mathematical symbol PI) of a
mathematical genius .. breaking the code .. ("Dave VanHorn")
Re: question about PKI... ("Joseph Ashwood")
Re: UK publishes 'impossible' decryption law (Anthony Stephen Szopa)
Re: Period of cycles in OFB mode ("Scott Fluhrer")
Re: Guaranteed Public Key Exchanges (Mok-Kong Shen)
Re: UK publishes 'impossible' decryption law ("vrml3d.com")
Re: Somebody is jamming my communications -- this has been happening at least in
three separate communication ([EMAIL PROTECTED])
Re: Somebody is jamming my communications -- this has been happening at least in
three separate communication (Markku J. Saarelainen)
Re: Have you watched the movie "PI" (actually a mathematical symbol PI) (Scott
Ebsen)
Re: I'm returning the Dr Dobbs CDROM (Frank M. Siegert)
PKI's and CA's ([EMAIL PROTECTED])
Which compression is best? ([EMAIL PROTECTED])
Re: Which compression is best? (Thomas Pornin)
Re: Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Persistent vs Non-Per DH for Voice ([EMAIL PROTECTED])
RE: Continually Secure Password/Pin (Gary)
Re: Which compression is best? (Mok-Kong Shen)
Re: Somebody is jamming my communications -- this has been happening at ("Douglas
A. Gwyn")
Re: Period of cycles in OFB mode (Mok-Kong Shen)
Re: Period of cycles in OFB mode (Mok-Kong Shen)
help DES encryption ("mati")
From: "Dave VanHorn" [EMAIL PROTECTED]
Subject: Re: Have you watched the movie "PI" (actually a mathematical symbol PI) of a
mathematical genius .. breaking the code ..
Date: Fri, 11 Feb 2000 06:18:46 GMT
I saw part of it and didn't like it either, but saying so on
alt.politics.org.cia, soc.culture.russian, soc.culture.israel, alt.math,
sci.crypt, and alt.2600 doesn't sound like a very good idea.
I DID trim my reply.
His selection of groups was based on some of the plot points in the movie.
The idea that you can predict the stock market by breaking some sort of
mathematical code hardly qualifies the subject for sci.crypt. It seems
more
at home on the rec.gambling forums where folks debate the merits of
betting
progressions.
That was one thing I didn't like about it.
They also used "the super chip" (almost as bad as "the disk" which is
supposed to fit whatever everyone is after.. :-P )
--
From: "Joseph Ashwood" [EMAIL PROTECTED]
Subject: Re: question about PKI...
Date: Thu, 10 Feb 2000 22:23:15 -
Search Counterpane for the analysis of SSL 3. It has the
details.
Joe
"Palmpalmpalm" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Thank you very much for kind suggestion.
By the way, what do you mean by "SSL is under secure"?
Sincerely,
palm
--
From: Anthony Stephen Szopa [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Thu, 10 Feb 2000 22:32:58 -0800
NoSpam wrote:
Se also http://news.bbc.co.uk/hi/english/sci/tech/newsid_638000/638041.stm
"UK publishes 'impossible' decryption law"
FLASH - FOR IMMEDIATE USE
FOUNDATION FOR INFORMATION POLICY RESEARCH (www.fipr.org)
=
News Release Thurs 10th Feb 2000
=
Today Britain became the only country in the world to publish a law which
could imprison users of encryption technology for forgetting or losing
their keys. The Home Office's "REGULATION OF INVESTIGATORY POWERS" (RIP)
bill has been introduced in Parliament: it regulates the use of
informers, requires Internet Service Providers to maintain "reasonable
interception capabilities", and contains powers to compel decryption
under complex interlocking schemes of authorisation.
Caspar Bowden, director of Internet policy think-tank FIPR said, "this law
could make a criminal out of anyone who uses encryption to protect their
privacy on the Internet."
"The DTI jettisoned decryption powers from its e-Communications Bill
last year because it did not believe that a law which presumes someone
guilty unless they can prove themselves innocent was compatible with the
Human Rights Act. The corpse of a law laid to rest by Stephen Byers
has been stitched up and jolted back into life by Jack Straw"
Decryption Powers: Comparison with Part.III of Draft E-Comms Bill (July 99)
The Home Office have made limited changes that amount to window-dressing,
but the essential human rights issue remains:
(Clause 46): authorities must have "reasonable grounds to believe" the key
is in
Cryptography-Digest Digest #96
Cryptography-Digest Digest #96, Volume #11 Fri, 11 Feb 00 13:13:01 EST
Contents:
Re: Message to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Eurocrypt 2000 (Eurocrypt 2000)
Re: Period of cycles in OFB mode ("Scott Fluhrer")
Re: Twofish vs. Blowfish ("Scott Fluhrer")
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: Period of cycles in OFB mode (Tim Tyler)
Re: Newbie Encrypt question (JPeschel)
Re: Which compression is best? (John Chandler)
Re: Which compression is best? (John Chandler)
Re: Which compression is best? (Jerry Coffin)
Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) (Tim Tyler)
Re: Message to SCOTT19U.ZIP_GUY (DTRuth)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Fri, 11 Feb 2000 17:18:14 GMT
In article 87uuf3$kvf$[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
HERE IS YOUR MESSAGE IN FULL POSTED A WHILE BACKPerhaps you and Tim
or anyone else would care to Comment on IT:
**
I know most of you will never have access to good ciphers. The NSA and
crypto gods will see to that. But it does not
mean that
you can't use some of the weak AES methods and still obtain a
far higher degree of security than what they want. Below is a
procedure that is "not all or nothing" but would allow one to encrypt
by removing the so called error recovery "feature"
that most people are stuck using.
Here it is in a nutshell You need 3 ciphers and 2 one to one
compressions to achieve the results. IF you have access to the
routines them selves it can be done in one pass since each method works
on the data previously processed but I will
explain it as 5 passes.
I am sure I wrote this from the point of view that one is using 3
seperate encryptions in series. And what could one do if one was going
to use 3 seperate encryptions of AES and one still want a way to prevent
the NSA of breaking it in an easy way. I should have added a pass zero
of compression since I usually compress first no matter what. But you
don't have to and what follows is just an easy substitution of a method
if one was going to use 3 seperate passes of AES
Pass one Encrypt with AES using weak 3 letter chaining even ECB
Pass two use Compression A "explained latter"
Pass three Encrypt with different key (with different method if one
wishes} Pass four use Compression B
Pass five Encrypt with different key
For the truely insecure among you. You can make this "all or nothing"
by reversing the byte order in the file after each
compression. But that requires whole file at one time..
yes I like to reverse the file it is a good idea if one can.
Better yet use my compression with just one pass of scott16u or
scott19u. Or failing to do that at least use one of mine with two
other AES methods.
Know for a disccusion of how to implement the Compression.
by Compression A I mean one of my one to one compressions that
uses a "condition file" with all 256 possible characters. This makes a
starting tree that can be greatly varied. But since
compression is one to one no information is added to data stream. Also
the message will as it passes through the
compression will change in length so that it is highly unlikely that
one can know where a block from the previous
encryption layer is passed to next encryption layer and it is highly
unlikely to even be the same length. For Compression B
you use a different "condition file" with all the 256 possible
characters in the file.
The input file should be at least long enogh for a few blocks to be
encrypted or you can reject the file as to short. Notice
also that each compression will most likely make the file longer and
that
the encryption methods should handle short blocks at the end of files.
Most methods already have a way to do this but if
at least one block is encrypted on each pass you can just pass the
short block without doing anything to it. Since the
state of the adapative huffman compressor will be such that the data in
last block will be transformed by the
compression.
Any thoughts on this by my nonadmirers.
David A. Scott
Sent via Deja.com http://www.deja.com/
Before you buy.
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
Cryptography-Digest Digest #98
Cryptography-Digest Digest #98, Volume #11 Fri, 11 Feb 00 15:13:01 EST
Contents:
Re: BASIC Crypto Question (Eric Lee Green)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: Newbie Encrypt question (Ralph Hilton)
Re: I'm returning the Dr Dobbs CDROM ("Bruno Liénard")
Re: I'm returning the Dr Dobbs CDROM ("abe kohen")
Re: Newbie Encrypt question ([EMAIL PROTECTED])
Re: I'm returning the Dr Dobbs CDROM (Ralph Hilton)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
PIII Random Number Generator ("Nick Shaffner")
Re: RFC: Reconstruction of XORd data (Jerry Coffin)
Re: I'm returning the Dr Dobbs CDROM (Paul Koning)
From: Eric Lee Green [EMAIL PROTECTED]
Subject: Re: BASIC Crypto Question
Date: Fri, 11 Feb 2000 12:23:44 -0700
[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.
They operate upon a stream of data (whether that stream be composed of bits,
8-bit bytes, or multi-byte blocks depends upon the particular algorithm). The
actual content being encrypted is not a concern at the cipher level.
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...
Correct.
So for an email text with an attachment,
You are not talking about encryption here. You are talking about MIME
encapsulation of multi-part messages. If the parts of the message happen to be
encrypted files, so be it, MIME doesn't care what the contents are, it merely
hands it off to the appropriate decoder for that particular MIME type.
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?
Bits are bits. About the only thing to consider is that stream ciphers
(whether implemented via a block cipher and CFB, or not) are easier if you're
talking about network streams, whereas block ciphers tend to be more secure
due to the keys issue. If you're talking files, though, a data length word at
the beginning and then chopping off the result at that # of bytes will take
care of that for block ciphers.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
--
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: 11 Feb 2000 18:35:35 GMT
Reply-To: [EMAIL PROTECTED]
In article 87ohue$jt9$[EMAIL PROTECTED], "r.e.s." [EMAIL PROTECTED]
writes:
"Michael Wojcik" [EMAIL PROTECTED] wrote ...
: [re generating Latin Squares with three permutations P (one
: column), R (an ordering of rotations of P), and T (a final
: permutation of rows)]
: Question: Is the inverse of a PRT-form square always itself a PRT-
: form square? More generally, are all Latin Squares in PRT-form?
"No" to the 2nd question -- we can see that not all
Lsquares are of your PRT form, by simply comparing
with the known number of Latin Squares of given order.
Since each Lsquare created by your PRT method is the
product of three permutations of 1..N, that method
produces N!^3 distinct Lsquares. E.g. for N=10,
that's ~10^20; but there are in fact ~10^25 order-10
Lsquares. The discrepancy grows rapidly -- there're
"only" ~10^36 PRT Lsquares of order 15, compared to
an estimated ~10^86 total.
Source:
McKay, B. D. and Rogoyski, E. ``Latin Squares of Order 10.''
Electronic J. Combinatorics 2, N3 1-4, 1995.
http://www.combinatorics.org/Volume_2/volume2.html#N3
Thanks - just what I was looking for. Dan Oetting has already
supplied the construction principle for fast generation of the
inverse of a PRT square, but these questions remain interesting for
other reasons.
The relatively small number of order-256 squares that are PRT squares
(the "PRT penalty", so to speak) may not be an issue in practice,
since there are still around 10^1520 or 2^5051 PRT squares of order
256. Other weaknesses may certainly exist, but at least that's a
large enough space to make searching prohibitive. (Determining some
elements does narrow down the search, but quite a few would have to
be leaked to make the search space reasonable. Even for a PR-form
square, if we determine an entire column we have 256! possibilities
to check; if we know which column it
Cryptography-Digest Digest #97
Cryptography-Digest Digest #97, Volume #11 Fri, 11 Feb 00 15:13:01 EST Contents: Re: Compression cannot prevent plaintext recognition (was Re: is (Anton Stiglic) Re: Twofish vs. Blowfish (John Myre) Re: Bounding (p-1)(q-1) given only knowledge of pq (Anton Stiglic) Re: Newbie Encrypt question (Jerry Coffin) Re: Persistent vs Non-Per DH for Voice (Mike Rosing) Re: Period of cycles in OFB mode (Mok-Kong Shen) Re: Encryption protocol questions (Mike Rosing) Re: Newbie Encrypt question (Mike Rosing) Re: Do 3 encryptions w/ a 40-bit key = 120 bits? (Mike Rosing) Re: Do 3 encryptions w/ a 40-bit key = 120 bits? (Jerry Coffin) Re: Which compression is best? (Mok-Kong Shen) BASIC Crypto Question ([EMAIL PROTECTED]) Re: RFC: Reconstruction of XORd data (Mok-Kong Shen) Re: Using Gray Codes to help crack DES ([EMAIL PROTECTED]) Re: Twofish vs. Blowfish (Eric Lee Green) Re: PKI's and CA's (Ralph Hilton) Re: Twofish vs. Blowfish (Eric Lee Green) Re: Newbie Encrypt question (Email forms are lame) Re: UK publishes 'impossible' decryption law (David Crick) Re: Hill Climbing (Mok-Kong Shen) Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik) From: Anton Stiglic [EMAIL PROTECTED] Subject: Re: Compression cannot prevent plaintext recognition (was Re: is Date: Fri, 11 Feb 2000 12:55:31 -0500 Tim Tyler wrote: Anton Stiglic [EMAIL PROTECTED] wrote: : Wooo, this is deviating again. Let me make this as simple as possible: : E_k: encryption algorithm using a key k, : D_k: decryption algorithm using a key k, : Z: compression function, : U: uncompression function : m: a plaintext message : So, encrypting m, would be done as follows: : -first compress m, : -then encrypt the result : That gives E_e(Z(m)), where e is the encryption key : Now, if you are testing out a decryption key d, you do : y - D_d(E_e(Z(m))) : Now, if you have the correct key y=Z(m), so you simply : unzip y , call the result x (x - U(y)), if you have the right : decrypiton key, x = m. So an attacker will simply look : for the headers in x. What if all x (such that x = U(f) for some f) have the headers the attacker is looking for? I.e. what if the information about message content available to the analyst is the same as the information about message content which was available to the author of the compressor - and the latter designed a scheme to correctly exploit it? Ah well that would be great! I'd want to be the first one to use it! But this is no longer a problem about compression functions, this turns out to be a problem of picking a function that only works on a specified subset of a larger set, this is sounding to be more like an NP-complete problem?? Anton -- From: John Myre [EMAIL PROTECTED] Subject: Re: Twofish vs. Blowfish Date: Fri, 11 Feb 2000 10:57:17 -0700 Scott Fluhrer wrote: John Myre [EMAIL PROTECTED] wrote in message snip Later in the development process, when you have an alpha or beta or something that sort of works, you can replace RC6 (if necessary) based on more recent information (like an AES decision). Umm, I don't know if that is legal. I believe that RC6 is patented, and so use of it (without RSA's permission) is illegal. If it does become the actual AES algorithm, then the patent issues go away, but that hasn't happened yet, and may never. Why wouldn't it be legal to use during development? AFAIK, patents are only relevant once you start to sell it (or the equivalent). 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. The important aspect I wanted to address is that allowing a change in algorithm is useful because it allows you to postpone your "final" choice, even if you don't anticipate allowing flexibility in algorithm choice as one of the product requirements. JM -- From: Anton Stiglic [EMAIL PROTECTED] Subject: Re: Bounding (p-1)(q-1) given only knowledge of pq Date: Fri, 11 Feb 2000 13:03:29 -0500 So I haven't read your post completly, but here is a quick reply: (p-1)(q-1) will have approximatly the same size as pq = n. So if you have, let's say, a 1024 bit RSA modulus, (p-1)(q-1) will be about a 1022 bit modulus. This only tells you that p-1 and q-1 is a BN of size 1022 (there are 2^1022 of them!, not much info at all). -- From: Jerry Coffin [EMAIL PROTECTED] Subject: Re: Newbie Encrypt question Date: Fri, 11 Feb 2000 11:10:07 -0700 In article 8814vm$7lv$[EMAIL PROTECTED], [EMAIL PROTECTED] says... I've been looking into data encryption lately. I want to write my
Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #11 Fri, 11 Feb 00 16:13:01 EST
Contents:
Re: "Trusted" CA - Oxymoron? (Sander Vesik)
Re: Newbie Encrypt question (Jerry Coffin)
Re: Using Gray Codes to help crack DES (Paul Schlyter)
Re: NSA opens up to US News (Email forms are lame)
Re: Have you watched the movie "PI" (actually a mathematical symbol PI) of a
mathematical genius .. breaking the code .. ("Androcles")
Re: help DES encryption (Hideo Shimizu)
Re: UK publishes 'impossible' decryption law (Mike Eisler)
Re: I'm returning the Dr Dobbs CDROM ([EMAIL PROTECTED])
Re: Message to SCOTT19U.ZIP_GUY ("Peter K. Boucher")
Re: I'm returning the Dr Dobbs CDROM (Paul Koning)
Re: Guaranteed Public Key Exchanges (Paul Koning)
Re: Period of cycles in OFB mode (Paul Koning)
Re: encryption export question (Paul Koning)
From: Sander Vesik [EMAIL PROTECTED]
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: 11 Feb 2000 20:07:56 GMT
In sci.crypt Brian Hetrick [EMAIL PROTECTED] wrote:
"Sander Vesik" wrote...
snip
Aha. I see your point. But completely delinking from the known is,
I suspect, impossible.
Incidentally, getting a circle of false notaries is a little more
cumbersome than you describe: you need to be a notary before you can
make an identity assertion. You would need a minimum of 5 identities
going through a minimum of three notarizations each to get a circle
of notary identities sufficient to get Thawte to issue a certificate
in the name of a completely fabricated identity. (An identity
assertion is specific to a notary/asserted identity pair; a new notary
can issue only 10 identity points; a notary can issue a maximum of 35
points; a minimum of 50 points is needed for an identity to be
considered "verified;" a minimum of 100 points is needed to become a
notary.)
An attempt to verify the fabricated identity would fail, of course, as
No. It would not. It would just point at another person whose face
looked different, who possibly never had even used a computer and
who has a good alibi. A false ID that didn't verify is no good.
in the described scenario all the "notaries" would have been frauds.
But the second generation notaries -- the minimum of three "good
faith" notaries -- would have copies of the falsified identity
documents of the five fradulent notary identities. While the names,
addresses, document serial numbers, and so forth, on the falsified
documents might not be of any use, the photographs are known good --
the notaries made sure they bore a "reasonable resemblance" to the
actual persons appearing before them.
How much does it cost to have a druggy go and get himself set up as a
notary using false ID?
Get a fresh asian immigrant / inner city youth to get the notary papers
and then sell them to me?
So at least you have a collection of photographs of the person(s)
involved in the fraud, at least if the fraud is detected within five
years of it starting.
Which are probably no good. It helps only against a very small and very
undetermined adversary.
To get two or more generations of fraudulent notaries, you would
need to start with ten identities, rather than five, as you would need
ten new notary identity assertions to get enough identity points to
create a notary.
And I would not doubt Thawte is watching the patterns of which
notaries are asserting which identities, with an eye to catching
exactly such attempts to build fraudulent identities. If they weren't
before, they certainly are now. :-)
Good to hear. but if you don't want a whole second gen ring, it is a
lot harder to note. Unnoticeable second gen notaries are just slightly
more expensive than those in whose case a slight suspicion might rise.
But the whole second gen. ring is not needed. you need just some second
gen notaries.
On the whole, I suspect it would be simpler to get one set of fake
IDs than five -- and simply going to "good faith" Thawte notaries
to get a minimum of two identity assertions with a single fake ID is
substantially easier than going to "good faith" Thawte notaries a
minimum of fifteen times with five fake IDs, or thirty times with ten
fake IDs.
Assuming the selection of the Thawte notaries is wide enough and that
they are sufficently apoart geographically, that's no problem. The scheme
can work in parallel and there is no way - at the time it is done -
to in any way say that some kind of (future) fraud is involved.
The only advantage of creating fradulent notaries as a step in
creating a fradulent identity is that the fradulent identity does not
have an accessable photograph on file. But, of course, the
photographs of the person(s) involved in the fraud _are_ on file, so
I do not see the advantage there.
See above - it need not be so. The people presenting the
Cryptography-Digest Digest #100
Cryptography-Digest Digest #100, Volume #11 Fri, 11 Feb 00 18:13:01 EST
Contents:
Re: RFC: Reconstruction of XORd data (zapzing)
Re: PIII Random Number Generator (John Savard)
Re: Twofish vs. Blowfish (Albert Yang)
Re: Period of cycles in OFB mode (John Savard)
Re: help DES encryption (John Savard)
Re: Newbie Encrypt question ([EMAIL PROTECTED])
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Terry Ritter)
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("Tony T. Warnock")
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("Tony T. Warnock")
Re: new standart for encryption software.. ([EMAIL PROTECTED])
Re: Using Gray Codes to help crack DES (Mok-Kong Shen)
Re: Which compression is best? (John Chandler)
Re: Guaranteed Public Key Exchanges (Mok-Kong Shen)
Re: Eurocrypt 2000 (David A Molnar)
Re: Bounding (p-1)(q-1) given only knowledge of pq ("Joseph Ashwood")
Re: Newbie Encrypt question ("Joseph Ashwood")
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: help DES encryption (Paul Koning)
Re: Period of cycles in OFB mode (Paul Koning)
Re: Somebody is jamming my communications -- this has been happening at (Paul
Koning)
Re: "Trusted" CA - Oxymoron? ("Brian Hetrick")
From: zapzing [EMAIL PROTECTED]
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 20:59:53 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Mok-Kong Shen wrote:
Ian Clarke wrote:
The algorithm is simple, I take the initial data, and XOR each
byte with
the previous byte (the first byte is left unchanged). This moves
forward through the string compounding the XOR at each stage (ie.
each
byte is actually XORd with all previous bytes).
The following piece of java does this: (Data is in char[] strC):
for (int x=1; xstrC.length; x++)
{
strC[x] ^= strC[x-1];
}
This is a form of what is in classical terminology termed auto-key
encryption. One can simply try all possible values of the first byte
to decrypt.
Addendum: In the present special form, the 'key' is known, namely
the first byte.
M. K. Shen
It does seem as if it could be done better.
What if one used a reasonably large-ish block,
encrypted the data in a known key, then split
the block into first half and last half,
wouldn't that do it? Wouldn't it help if
random noise were included in the block?
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: PIII Random Number Generator
Date: Fri, 11 Feb 2000 14:22:25 GMT
"Nick Shaffner" [EMAIL PROTECTED] wrote, in part:
So did the PIII ever ship with that cryptographic quality RNG that they
promised? If so, anyone know where I can find information on getting access
to it? www.intel.com doesn't seem to mention anything about it, and a
couple of web searches didn't turn up anything...
There is stuff about it on the Intel web site, but the RNG is not part
of the Pentium III chip; it's part of the 810 chipset. So it is
available to some Celeron users as well.
John Savard (jsavardatecndotabdotca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: Albert Yang [EMAIL PROTECTED]
Subject: Re: Twofish vs. Blowfish
Date: Fri, 11 Feb 2000 21:23:13 GMT
Thanks, Understand what you are getting at.
I was thinking the same thing, I will have a pretty common API so I can
change the backend at will and not effect the program.
I might go with Serpent, but it's slow compared to Twofish.
I was thinking about just doing a quick 10 liner XOR encryption and
decryption algorithm as a stub, but I thought, shoot, then I can plug
RC5 or RC6 in there for just a few lines more! So that's what I might
do.
But I'm hoping to finalize on an algorithm..
When's AES suppose to be picked again?
Albert
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Period of cycles in OFB mode
Date: Fri, 11 Feb 2000 14:32:06 GMT
Tim Tyler [EMAIL PROTECTED] wrote, in part:
In researching such questions, I uncovered what /appears/ to be an error
in Schneier's "Applied Cryptography".
On P.205, in a section called "Security problems with OFB", he writes:
``When the feedback size equals the block size, the block cypher acts as
a permutation of m-bit values (where m is the block length) and the
average cycle length is 2^m - 1.''
I believe the expected cycle length will be 2^(m - 1), and *not* 2^m - 1.
The proof of this is not quite trivial. I'll provide it only if it is needed.
I think you're right. (2^m) - 1 for an average cycle length for m-bit
values does seem a bit high. However, I would have thought the
Birthday Paradox would make
Cryptography-Digest Digest #101
Cryptography-Digest Digest #101, Volume #11 Fri, 11 Feb 00 21:13:01 EST
Contents:
Re: Bounding (p-1)(q-1) given only knowledge of pq (David Hopwood)
Re: Guaranteed Public Key Exchanges (David Hopwood)
Re: Using Gray Codes to help crack DES (David Hopwood)
Advanced Network Authentication ("Joseph Ashwood")
Re: Using Gray Codes to help crack DES (Mok-Kong Shen)
Re: RFC: Reconstruction of XORd data (Jerry Coffin)
Re: Which compression is best? (Tim Tyler)
Re: Bounding (p-1)(q-1) given only knowledge of pq (Anton Stiglic)
Re: Which compression is best? (Tim Tyler)
Re: Which compression is best? (Tim Tyler)
Re: need help with a basic C++ algorithm ([EMAIL PROTECTED])
Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
Re: Which compression is best? ("Douglas A. Gwyn")
Re: Message to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Which compression is best? (SCOTT19U.ZIP_GUY)
Re: help DES encryption ("Douglas A. Gwyn")
Re: Which compression is best? (SCOTT19U.ZIP_GUY)
Re: Which compression is best? (SCOTT19U.ZIP_GUY)
Date: Fri, 11 Feb 2000 06:10:36 +
From: David Hopwood [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Bounding (p-1)(q-1) given only knowledge of pq
=BEGIN PGP SIGNED MESSAGE=
Joseph Ashwood wrote:
For let me say that I'm not sure this information is new,
but to the best of my knowledge it was never told to me.
Note that finding (p-1)(q-1) is provably equivalent in difficulty
to factoring pq. So, although it is possible to put (rather loose)
bounds on (p-1)(q-1), this doesn't help to break RSA.
- --
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
iQEVAwUBOKOnxDkCAxeYt5gVAQFEmwf/X/72IDfm0JV76HipRiT0YUWMFgizWc5b
Rm3RJj7j2zegSRaJmeQ1cvhcA8TxssE2pzPeB5FtZdM8x/QKpw1ohOp/sITHRHyl
QHHVFdgfwPxPOSLmr9472BtpRY92j6xVmfyQOLwgdUBQTc5rRFEE9lsfp+7zlNmU
2Gc1D4YekmvUsAQWGVmF46w2B/r+KvBvGxaWsOx0OmHr/hlz1F/XRQoN656WeYoA
NdXK5hnh2/JZmxJLmfahEwnl9hD2F/7cpaFHDZyx3bolRYxJ8Ebq/SJp+IEV0Pkw
7RTACgI8LIvSlGm65qAjXHQj/PfvvgO9Z7WAXB1SQHKBWLawrl5SzA==
=Y1gS
=END PGP SIGNATURE=
--
Date: Fri, 11 Feb 2000 05:38:51 +
From: David Hopwood [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Guaranteed Public Key Exchanges
=BEGIN PGP SIGNED MESSAGE=
Dan Day wrote:
On Thu, 10 Feb 2000 02:29:58 +0800, No Brainer [EMAIL PROTECTED] wrote:
I was hoping there was a new protocol of some type that would allow me to
exchange public keys with integrity and take the middle man "out of the
loop" (without the need for another secure channel of course).
[...]
Well, I've got at least a partial workaround... As one of your
first messages, send your recipient an attached EXE file of a popular
sort, such as the "gerbil in the microwave" animation.
If you're sending executable files, the man-in-the-middle has another type of
attack: replace the .exe with a trojan that installs a back door, and then
runs the original executable (using the same techniques as are used by
viruses). Then even if you discover the switched public keys, the attacker
still has a back door into your system.
But at least it's a step in the right direction.
No, probably a step backwards.
- --
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
iQEVAwUBOKOgUTkCAxeYt5gVAQHw4QgAi+0qAgKsRqZ+9Gy/Hq3WzUwf6j4Qg6X6
yEr9xbXUzYNaLP5Fd8qOD0EGh1Ixm7AafrxKX1WN2rhxK03wRnkWLtqyB8G1Z7Zy
rG5kYISUdhvzQfP9Pt9BaX6WocN4hZ7keRU70uN3LfuQ8d6XfBZjhPb+lMjnJsh5
OkfpPdSlSlPL7F9s11QTmq3oz/4admrM1BgOdBN5urixMiJx3CuVx02m1H7dBa+0
BP8XhOYvh6hMrcA2VerzZ6AFdV4nbhpDHULDU2RHLSRIGjEOc4H02dif9GCpITux
/2mqWayKGbcQ1xZZ8Ot5Mouwp2DU/lnxDIWyN48tbGd8zUM4/vAIdA==
=r5cG
=END PGP SIGNATURE=
--
Date: Fri, 11 Feb 2000 05:05:57 +
From: David Hopwood [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Using Gray Codes to help crack DES
=BEGIN PGP SIGNED MESSAGE=
Dan Day wrote:
On 8 Feb 2000 23:24:52 GMT, [EMAIL PROTECTED] wrote:
count = count + 1
greycode = count ^ (count 1)
Hey, that's really slick. But I'll be damned if I can
Cryptography-Digest Digest #102
Cryptography-Digest Digest #102, Volume #11 Fri, 11 Feb 00 23:13:00 EST
Contents:
Re: Newbie Encrypt question ("Douglas A. Gwyn")
Re: Latin Squares (was Re: Reversibly combining two bytes?) (zapzing)
Re: Do 3 encryptions w/ a 40-bit key = 120 bits? ("Douglas A. Gwyn")
Re: RFC: Reconstruction of XORd data ("Douglas A. Gwyn")
Re: UK publishes 'impossible' decryption law (zapzing)
Re: Bounding (p-1)(q-1) given only knowledge of pq ("Joseph Ashwood")
Re: Bounding (p-1)(q-1) given only knowledge of pq ("Joseph Ashwood")
Re: Newbie Encrypt question ("Joseph Ashwood")
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("r.e.s.")
Re: need help with a basic C++ algorithm ("Douglas A. Gwyn")
Re: Bounding (p-1)(q-1) given only knowledge of pq (David Wagner)
Re: Period of cycles in OFB mode (David Wagner)
Re: Period of cycles in OFB mode (David Wagner)
Re: Twofish vs. Blowfish (David Wagner)
Re: Twofish vs. Blowfish (David Wagner)
Re: permission to do crypto research (Wim Lewis)
Re: Twofish vs. Blowfish (David Wagner)
Re: RFC: Reconstruction of XORd data (David Wagner)
Re: permission to do crypto research (David Wagner)
Re: Period of cycles in OFB mode ("Scott Fluhrer")
Re: Persistent vs Non-Per DH for Voice (David P Jablon)
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Newbie Encrypt question
Date: Sat, 12 Feb 2000 01:46:19 GMT
Jerry Coffin wrote:
Yes, DES includes both shifting and XORing, but those are NOT the
primary elements of the security -- though it's somewhat difficult
to talk about bits and pieces of a cipher and still say anything
meaningful, I think it's safe to say that one of the single most
important elements in the security of DES is in the S-boxes.
Indeed, the S-boxes are the only nonlinear components of DES.
The notion (of the original poster, not Jerry) that security
lies in shifting and XORing is analogous to a notion that the
operation of a computer program depends on NANDing. Undoubtedly
there is a lot of NANDing going on at a very low level in the
computer hardware, but it is the way that that activity is
organized and coordinated that actually accomplishes the useful
higher-level functions. If one tried to deal with computing by
exclusively thinking at the lowest (logic-gate) levels, one
would never be able to achieve the higher functions.
--
From: zapzing [EMAIL PROTECTED]
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Sat, 12 Feb 2000 01:36:12 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Latin squares are really only useful if the input alphabet and key
alphabet are the same size. The DES S-boxes don't have the same sizes
but seem to work OK.
Well. actually that is true by definition,
since a latin *square* must be square.
But your post gives me an interesting idea.
What if we generalize it to a latin *rectangle*?
For example, the message symbol could be
one eight bit byte, and the encrypting
symbol could be *two* eight bit bytes.
The latin rectangle would be a
256 X 65536 array of bytes,
arrainged so that every column
has one instance of every byte, and
every row has 256 instances of every byte.
OK so maybe that is a bit large for memory,
but you get the idea.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Do 3 encryptions w/ a 40-bit key = 120 bits?
Date: Sat, 12 Feb 2000 01:57:05 GMT
Mike Rosing wrote:
[EMAIL PROTECTED] wrote:
Given that 40 bit encryption is considered insecure, what about the
scenario if you take a file and use 40-bit encryption to encrypt it
3 times, would that not give it an effective key length of 120
bits, and therefore be secure?
It'll give you 41.5 bits of security.
The notion of "bits of security" is nonsense. If a random key has 40
bits, then the expected number of trial decipherments for success in
a brute-force key search against a single ciphertext is 2^39,
regardless of the complexity of each decipherment.
What gkare suggests can be read as either C = E(E(E(P,K0),K0),K0) or
C = E(E(E(P,K0),K1),K2). Brute-forcing the former is a 40-bit search;
brute-forcing the latter is a 120-bit search. But that is no
guarantee that the latter system requires 2^80 times the resources to
crack, because brute-force key search is not the only way to attack
systems. (Counterexamples are easy to find.)
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: RFC: Reconstruction of XORd data
Date: Sat, 12 Feb 2000 01:59:53 GMT
Mok-Kong Shen wrote:
One can simply try all possible values of the first byte to decrypt.
That presumes that one has both strings.
The correct answer is that it is secure (under the assumptions)
for *random* plaintext data.
