Cryptography-Digest Digest #935, Volume #13 Sun, 18 Mar 01 16:13:01 EST
Contents:
Re: Safe Multiple Encryption (John Savard)
Re: IP (David Schwartz)
Re: Random and RSA (John Myre)
Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION (John Savard)
Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION (John Savard)
Re: Defenses Against Compromising Emanations of the Private Key ("Lyalc")
Re: Safe Multiple Encryption (SCOTT19U.ZIP_GUY)
Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION ("Henrick Hellstr�m")
Re: FIPS 140-1 does not adress eavesdropping ("Lyalc")
Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION (Joe H. Acker)
Re: Idea (Sundial Services)
Re: PGP "flaw" (Tom McCune)
Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION ("Henrick Hellstr�m")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Safe Multiple Encryption
Date: Sun, 18 Mar 2001 20:03:41 GMT
On Sun, 18 Mar 2001 19:11:26 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>A stream cipher could, in producing a bit stream to XOR with
>plaintext, have a very large internal state, and at the end of each
>step, only output a fraction of that state - perhaps derived from the
>state in a fashion that resembles a *secure hash function*.
This has suggested to me a new stream cipher mode.
Let the stream cipher have a *very* large internal state.
Perform the state transition function.
Take a small portion of that state by means of a (weak) hash-like
step. (For example, look at what I did when I modified Panama.)
This small portion of the state, though, is still big enough so that
it constitutes the entire set of subkeys for a block cipher.
Use that block cipher on the previous ciphertext block, (so that there
is no autokey propagation problem - the ciphertext doesn't permanently
modify the state of the stream cipher, only its output) and XOR the
output with the current block (plaintext or partial ciphertext) ...
thus we have cipher-feedback mode, with its good propagation
properties, as our stream cipher, except that our subkeys come from
the 'real' stream cipher.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: IP
Date: Sun, 18 Mar 2001 12:01:40 -0800
Vernon Schryver wrote:
> If you use end-to-end security mechanisms and do not expect the
> addresses in IP headers to identify, authenticate, or authorize
> anything, then the only reason to care about too quick IP address
> reassignment are minor.
The problem is, most people don't use end-to-end security mechanisms
that provide this level of protection. Consider, for example, retrieving
your email. What percentage of people aren't at potential risk if their
connection drops while they're in the process of retrieving their email?
DS
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Random and RSA
Date: Sun, 18 Mar 2001 13:06:34 -0700
"Douglas A. Gwyn" wrote:
<snip>
> You might as well say:
> man = human and woman = human, so man = woman.
I forget, what's the name of that particular form of
logical error?
JM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION
Date: Sun, 18 Mar 2001 20:12:47 GMT
On Sun, 18 Mar 2001 14:21:06 -0400, amateur <[EMAIL PROTECTED]> wrote, in
part:
>Why are you talking about plain-text? Is not a cryptanalisis above the
>plain-text?
>Someone can help me?
Yes, cryptanalysis works on the ciphertext, which is later than the
plaintext.
But if the plaintext was just perfectly random bits, the cipher could
not be solved, because there would be no way to say which solutions
are good.
So cryptanalysis, when working on the ciphertext, still needs to know
something about the plaintext to work towards finding out the key -
and the rest of the plaintext.
If the plaintext is well compressed, there is less known about the
plaintext, so the cryptanalyst has much less to work with in the case
where _known_ plaintext is not available.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION
Date: Sun, 18 Mar 2001 20:09:49 GMT
On 18 Mar 2001 19:21:41 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
> Getting back to some of your stuff. I liked the write up on
>the huffman table you did for english letters. I just wished you
>did it with a space as well as the 26 letters.
Well, it certainly can be done with a space, although then the tree
isn't quite as good a fit. I just did this as an example.
Since in English text, you don't have two spaces in a row, and you
have spaces regularly every so many letters, what you *really* should
do for English text is have a second Huffman code table based on the
frequency of different word lengths.
Then you alternate between two states: first, a word length symbol,
then as many letter symbols as the specified word length, and then
back to the word length symbol and so on. This is a better fit to text
than a straight Huffman code including a space symbol would be.
Of course, it isn't as good as using a dictionary of words either, but
for something short to type in as a program, one can add a Lempel-Ziv
type on-the-fly dictionary builder (but this time using *real words*
instead of bit strings!!! and so the pointer would be "n words back",
not "n bits back" or even "n characters back", making it smaller).
I think good compression is worth looking into; I just don't claim
that it is going to solve a lot of problems necessarily, because I
don't want to start arguments.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Defenses Against Compromising Emanations of the Private Key
Date: Mon, 19 Mar 2001 07:22:06 +1100
Gonna be a hard time selling these units, unless the threat is credible
(demonstratable), practical, and the threat emanates from other than
governments, because it's will take several truckloads of money and time to
attack one key.
If we now which SSL key is targetted, then the rest iof us can reast easy
for a while. Maybe the cheaper option is to set up a mailing list to report
anyone seeing several alrge trucks, antenna and portable generators outside
their workplace for several weeks. If you do see this, transfer the SSL
server certificate to a 'honeypot' site, then get a new SSL server
certificate.
Using multiple temporary certificates is no real answer, if this threat is
real. It merely moves the attack to the intermediate or root CA keys, not
the server keys.
I suggest more reading - a lot more - on radio theory, emanations, and EMI
(electro-magnetic interference) to check these theories are worthwhile
approaches.
Hint - look at the thermal noise floor for the bandwidth and temperature you
are using for the source and receiving equipment. Basically, no signal
under that power amplitude can be recovered, from memory.
Lyal
Frank Gerlach wrote in message <[EMAIL PROTECTED]>...
>As a result of this discussion thread, I propose the following
>defenses against eavesdropping on the private key:
>
>-Cryptographic:
> -Temporary Certificates: SSLv3 already supports certificate chains.
> There should be a scheme to allow web site operators to derive
>temporary
> certificates from the certificate signed by the CA, which must of
> course be supported by the applications (e.g. webbrowsers).
> This allows for a dramatic reduction of the private key usage rates,
> resulting in a dramatic reduction of private key signal repetition
>rates.
> The shannon formula can be used to establish the maxium number of
> private key usage counts based on the SNR (see below).
>
>-Electric
> Design and measurement principles as outlined in NACSIM 5xxx should be
> applied to cryptographic coprocessors (called "device" in the
>following).
> Unfortunately, many important details seem to be still classified.
> FIPS 140-1 DOES NOT assure this, as it does not address compromising
> emanations at all.
> Using national security terminology, private keys should be considered
>RED
> signals, while all other signals (including session keys) need
> only lesser security levels. Still, those signals need to be below
> the noise floor.
> Note: It is by no means sufficient to assure that private key signals
>are
> below the noise floor, as the private key will create emanations
>whenever
> it is used in an asymmetric en/decryption process. The maxmimum number
> of repetitions for a given signal-to-noise ratio must be calculated
> using shannon's formula.
>
> -SNR measurements of the asymmetric encryption process: Using similar
> mehods as outlined in the NACSIM 5xxx standards, the device should
> be qualified for a certain maximum SNR of the private key. This SNR
> is to be used for maximum private key usage counts.
> Only noise derived directly from a physical source should be considered
> in that measurements, which mandates a jamming device.
> -no galvanic connections to the host computer: Contrary to current
> commercial designs, galvanic connections (e.g. SCSI or PCI) should be
> avoided, as they are very difficult to isolate from the private key
>signal.
> All communications to/from the device should be through fiber cables
>only.
> Still, the
> farday cage of the device should be grounded effectively (see NACSIM
>5xxx).
> A dedicated ground lead for the device's faraday cage should be
>provided.
> Power supply should be either through a grounded battery or through a
> transformer qualified for Top Secret cryptography. Obviously, the
> transformer must be qualified for isolation performance in the relevant
> private key frequency bands.
> It seems to be a prudent measure to locate the device in a specially
> (physically and electrically) secured room. The fiber connection easily
> allows for that.
>
>
>Especially the software approach of using temporary private
>keys/certificates
>seems to be promising, at least from my view as a software engineer.
>Still, electrical design and qualification (measurement) is instrumental in
>
>securing the private key.
>
>A DEVICE OF UNKNOWN SIGNAL-TO-NOISE RATIOS HAS UNKNOWN SECURITY PROPERTIES
>REGARDING THE COMPROMISING EMANATIONS THREAT.
>
>Users should demand at least very basic emanations measurements for
>cryptographic coprocessors from the vendors.
>
>Resources:
>
>NACSIM 5xxx standards at www.cryptome.org
>
>"SSL and TLS" by Eric Rescorla
>
>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Safe Multiple Encryption
Date: 18 Mar 2001 20:12:28 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>
>It would therefore be very helpful if there were a set of guidelines
>for safe multiple encryption.
>
>Let us look first at the simplest case, applying multiple ciphers to a
>plaintext in order.
>
I think that the FIRST requirement would have to be that each
stage is BIJECTIVE. The reason for this is so that no information
can be added that would make the attack easier.
>It would seem to be true that if the following conditions were met,
>multiple encipherment would be 'pretty safe', provided at least none
>of the ciphers were contrived:
>
>- each cipher step has an independent key (either genuinely
>independent, or made independent through the use of a secure hash
>function; the GGR scheme that David Wagner recently mentioned is also
>applicable here)
>
>- no cipher step is allowed to change the size of the plaintext; where
>an IV is desired, the IV is generated independently of the cipher
>step, and supplied to it from the outside
>
I use to think this was of utmost improtance. But not any more
since this can be taken care of by proper transfroms. Example you
have a file of any lenght. You have a following stage that only
works on 16 byte blocks. It is possilbe to mapp every file of
any number of bytes to a file of 16 byte blocks in a bijective way.
One could do the work on the file in 16 byte chuncks then map
back to blocks size of any lenghts in a bijective way.
As an example of why the plaintext size could stay the same and
the cipher leak infomation. Lets say the cipher is designed for
large file. If all the files tested where typical files one could
compress them and then hide information in the extrac space so
that input and ouput lengths could match and yet infromation to help
break the system was added.
>
>The stages have to be isolated from each other, so that one stage
>can't resemble the decryption of the preceding stage. The
>'bricklaying' version of triple-DES (which would be done in EEE mode
>anyways) is a simple example of something that meets this.
>
>Thus, one attractive idea is to include transposition steps between
>block cipher encryption layers.
>
>Another simpler thing to do is to use stream cipher layers.
>
>And stream ciphers have one property that block ciphers don't. A block
>cipher must pass the entire plaintext through in a form that can be
>decrypted. So everything the block cipher did is 'visible' in a sense.
>
>A stream cipher could, in producing a bit stream to XOR with
>plaintext, have a very large internal state, and at the end of each
>step, only output a fraction of that state - perhaps derived from the
>state in a fashion that resembles a *secure hash function*.
>
Another thing one could do is to make it so that effects progrates
through whole file.
An example which is slow but would work is to use my adaptive
huffman uncompress the file could get 8 times longer. Then
reverse the byte order of the file. And then use something like
Matts BICOM to do adaptive PPM compression with RIJNDAEL to
binary 8-bit byte 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: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION
Date: Sun, 18 Mar 2001 21:27:32 +0100
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Henrick Hellstr�m) wrote in
> <992oit$nme$[EMAIL PROTECTED]>:
>
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> skrev i meddelandet
> >news:[EMAIL PROTECTED]...
> >> Dear folks I know its hard to get most of you motivated.
> >> But would there be interest in making a "perfect english"
> >> encryption using anyone favorite fixed block size cipher.
> >> Such that any wrong key would lead to valid english text.
> >
> >
> >Been there, done that. I made such a component for Delphi a year back. It
> >performs awfully, but it works, and it should still be available for
> >download somewhere.
> >
> >
> >--
> >Henrick Hellstr�m [EMAIL PROTECTED]
> >StreamSec HB http://www.streamsec.com
> >
> >
>
>
> I don't know much about DELPHI except it was part of a
> general motors at one time. I prefer C. Was your code
> perfectly bijective from english to encrypted binary files.
> In otherwords could I take a 2 or 3 byte random file and
> come back with words in such a way that for "any decryption key"
> tested it would generate english words that when reencrypted
> would come back to the same file.
>
> If so way to go. I would be more interested in your
> dictionary file than the code. Since I have all the tools
> necessary to do this in C. Just really lacking a good code
> dictionary. Also I yet to see any fully bijective code
> written for RIJNDEAL except the work of MATTs and the recent
> thing I post where I use a batch stream and several bijective
> programs to create a ture bijective encryption with RIJNDEAL to
> the set of all binary 8-bit files.
>
>
> David A. Scott
> P.S. you never stated the name of the file that has this
> having searched the net for many programs of this type I
> have never come across one that does what your implying
> your does. Also is not the dictionary very large is it
> a seperate file. If so where is at and what is its format.
>
> --
> 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: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 does not adress eavesdropping
Date: Mon, 19 Mar 2001 07:27:38 +1100
Creating a valid threat scenario is useful.
Can the power connection to the FIPS140-1 device be isolated from other
'noise' sources, where noise is signals other than the target of interest?
If not, then do the other noise sources effectively swamp the TOI?
And is there are reasonable 'safe three dimensional perimeter' around the
unit, safe at least 5 m, preferably 20 or more?
Lyal
Frank Gerlach wrote in message <[EMAIL PROTECTED]>...
>In response to the Paul Rubin's reference to the IBM 4758 cryptographic
>coprocessor I have read a paper from IBM, describing the FIPS 140-1
>validation process:
>http://www.research.ibm.com/secure_systems/papers/nfips.pdf
>
>It clearly states that FIPS 140-1 does not even adress power line analysis.
>140-1 just has a different threat model: mainly active attacks conducted
>physically (e.g. opening the device) or through stimuli (e.g. malicious
>commands by application software).
>I consider the stimuli-based threat model very important, but it is not
>related to the threat model in this discussion threat.
>
>A good discussion of a security issue should always define a threat model,
>because discussion will otherwise be virtually useless.
>
>FIPS 140-1 is also a very good sociologic example of how standards can be
>misused. When I talked to some colleagues of mine, who know more about
>crypto coprocessors, the "FIPS standard" was mentioned, as it happened in
>this discussion thread. After looking at 140-1, I conclude that it does not
>adress emanations/TEMPEST at all. It seems that even experienced engineers
>like to believe into simple truths like "this device is FIPS 140-1
>certified - don't worry".
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION
Date: Sun, 18 Mar 2001 21:33:15 +0100
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> If you get access to good dictionary of words and how often
> they occur one could easily do the same thing for ENGLISH text.
> I don't mind coding it if you supply the dictionary or if you
> supply the static starting hufman tree for characters with space
> I would use "_" as space in table so it can be seen. I can
> easily write a condition file for this.
I like your idea as well. Getting wordlists should be no problem, there
are plenty of them available on the Net as well as tools for joining
them into larger ones (search for "wordlist").
To get some frequencies, you might scan large corpora such as books of
the Gutenberg project or random pages on the Internet. You might also
take a look at the work of William Ralph Bennett jr., e.g. "Scientific
and Engineering Problem-solving With the Computer", William Ralph
Bennett, Jr., Prentice-Hall Inc., Englewood Cliffs, NJ, 1976 and "How
Artificial is Intelligence?", in: American Scientist, vol. 65 no. 6,
694-702. He has worked on the Voynich manuskript but also on funny
pseudo-poetry based on relative frequencies. Such relative frequencies
are funny because they can be used to randomly produce text that looks
like ordinary English text at syntactical level and can even look
meaningful sometimes---but still is random garbage like some posts on
Usenet. I think "hidden Markov models" is another keyword you might want
to watch out for.
Regards,
Erich
------------------------------
Date: Sun, 18 Mar 2001 13:39:29 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Idea
:-/ Blunt words from someone who knows, never conceal the truth.
"Pieces of paper" are merely products. They can be lucrative products
to sell. They can be what they are supposed to be -- symbols that you
have actually learned something, symbols that you can prove it -- but
they rarely are.
It's an irrefutable fact (1) that human beings are acutely aware of what
they don't know, and (2) that they seek affirmation from external
sources that they have actually accomplished something. The classical
education system responded to this in a positive way by setting a high
standard for students to cross and rewarding only those students who
were capable of doing so. The "modern" system .. and this applies not
only to traditional scholastics but also to industry training .. simply
ensures that "no one will fail, therefore everyone will buy." It
produces as a work-product a certificate that is actually worth much
less in the marketplace than the person who is touting it believes it to
be.
"Retired engineers who worked on programming inertial guidance systems,"
just like "programmers who learned their craft on university computers
after browsing through the one and only book on programming that existed
in their high school libraries, without knowing what the hell they were
doing," stare at these certifications with disbelief and scorn.
And I suspect that employers, in the long run, do likewise. Somehow, we
have entirely lost the concept of "apprenticeship." We have somehow
espoused the notion that you can "earn a degree" and thus acquire the
same level of =practical= education. But employers simply cannot afford
to risk their businesses on this hypothesis: they are compelled to
produce results, "or else." And well do they know this.
>SCOTT19U.ZIP_GUY wrote:
> I hate it when people think it is necessiary to prove one
> is qualified to do something. Just what the hell does that mean.
> If the guy is alive he is qualifed. Pices of paper usually
> don't mean shit. Qualifications are used to keep the community
> closed. Of couse the pompous assholes will find fault with many
> of so called ametur stuff and use that as an excuse to never really
> check what many ametures are doing.
> Taking teaching as an example. I am a retired engineer worked
> on programming inertial guidance systems on missles and aircraft.
> I used calculus every day. I tutored my kids in it and they passed
> the AP tests and got college credit no sweat California.
> Here in Texas they have a shortage of "qualifed math teachers".
> I spent a month and some bucks trying to get hired since they
> say they need math teachers. First roadblock every time you turn
> around the system wants more money. They wanted my college transcripts
> I give them to them. They asked after I called them a few weeks
> later that I did not have algebra or trig. I started college on a
> math scholarshop and took calculus off the bat. That seened to
> confuse them. Then they sent a list of classes I needed to take
> and a schedule of fees in the thousands of dollars I would have to
> pay. Thats just to get started. On top of that not really sure there
> is a job there though they assure me that one is there. Guess what
> your forced to pay into the teachers retirement fund. You can' get
> full retirement till you work 20 years. Well as you can see I
> was not applying for english teacher. But I was dam good at math
> and I can see why they have a shortage of math teachers. You have
> to go though hell to get the job the pay is shit and math really
> is not that much of a requirement. And if your all ready retired
> they want to humilate you by forceing you to pay into a retirement
> system you wont live long enough to get a dime from. In my case
> I don't mind the low pay. I am retired. I would do it for half the
> pay. But I am short about 4 years of having 40 quarters for SSI
> so way the hell work at a full time job paying into a system you
> can never use. The point is one can chase a carrot only so long.
> It reminds me of a friend where I use to live in CA. They had
> a jewlery store. THe threat of robbery very high. THey tried to
> get a permit to cary a gun. They spent years paying fees getting
> evaluated by shrinks. But they where always one step short. Till
> an insider told then they had the wrong politics and there would
> always be another step. While they gave up until one day a friend
> told they they had a permit from country. The freind inrodcued them
> to the count sheriff. A few days later they got the permit.
>
> SORRY FOR THE RANT
>
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: PGP "flaw"
Date: Sun, 18 Mar 2001 20:37:04 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>The key, I think, is disclosure. I suspect that any employer which is
>prescient enough to use PGP in the first place will also know to
>disclose to employees that encrypted messages can also be disclosed
>using a master, company-held second key. I also see that the PGP
>vendors spoke quite frankly about the fact that this capability existed
>in their software, and that they accurately described the purpose for
>which it was to be used.
Hopefully, the employer would give employees some basic instruction in the
use of PGP - if this occurs, it would be difficult to use PGP without being
aware of an ADK being in use.
>The flaw, as described by Bruce and others, is that Greg (the Gestapo),
>or maybe Chris (the Competitor!!) could exploit this same feature to
>create additional keys .. thus fooling -both- Alice, Bob, and Edward
>(the Employer) into believing that their secret was "safe with the three
>[and only three] of them."
>
>It's really not so bad that a system should permit "more than two"
>people to share communication -- i.e. the third-party being the employer
>-- but how, indeed, DO you construct the system so that a FOURTH party,
>unbeknownst to the other three, could "tap the phone, hear everything
>that was said, and never be detected?"
>
>How, indeed?
>
>It seems to be the usual catch-22 situation. On the one hand, employers
>need to be able to decrypt communications issued under their purview
>(and to do so without rendering other layers of security irrelevant) ...
>yet the three "trusted" parties in such communication ALSO need to
>protect against the nefarious addition of an unknown FOURTH (or fifth,
>or sixth...) party to their number!
>
>After all, the true value of cryptanalysis as a form of
>intelligence-gathering is not merely that the parties believe their
>communications to be secure; but that they are unaware that the
>communications have been compromised.
Actually, this attack would be difficult to go undetected, unless PGP users
are just lacking in basic knowledge and/or careless:
http://www.McCune.cc/PGPpage2.htm#ADKSecurityFlaw
But regardless, as long as PGP 6.5.8 or above is used, it is a moot issue.
Tom McCune
My PGP Page & FAQ: http://www.McCune.cc
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION
Date: Sun, 18 Mar 2001 21:40:26 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> I don't know much about DELPHI except it was part of a
> general motors at one time. I prefer C. Was your code
> perfectly bijective from english to encrypted binary files.
> In otherwords could I take a 2 or 3 byte random file and
> come back with words in such a way that for "any decryption key"
> tested it would generate english words that when reencrypted
> would come back to the same file.
No, not really, but close enough. It created a dictionary tree and assigned
a unique index to each leaf (word in the list). A plain text was coded by
substituting each word for it's index. So if there were 2**16 or less words
in the list, each word was substituted for a 16-bit word, etc. A perfect
transform would have to use arithemtic operations instead of cutting and
pasting bytes.
> If so way to go. I would be more interested in your
> dictionary file than the code. Since I have all the tools
> necessary to do this in C. Just really lacking a good code
> dictionary. Also I yet to see any fully bijective code
> written for RIJNDEAL except the work of MATTs and the recent
> thing I post where I use a batch stream and several bijective
> programs to create a ture bijective encryption with RIJNDEAL to
> the set of all binary 8-bit files.
I did not use a fixed dictionary. The component was designed to parse any
text file and create a dictionary out of it.
>
> David A. Scott
> P.S. you never stated the name of the file that has this
> having searched the net for many programs of this type I
> have never come across one that does what your implying
> your does. Also is not the dictionary very large is it
> a seperate file. If so where is at and what is its format.
Search Google with my name as search word. I named the file fhhsmtri.zip. It
is a zip file, and it contains compiled files for Delphi 4. I will probably
rewrite the code and release it freely when I get the time.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
