Cryptography-Digest Digest #550, Volume #12 Sun, 27 Aug 00 20:13:01 EDT
Contents:
Re: Encryption tool ([EMAIL PROTECTED])
Re: RSA Security Conference for 2001 (Samuel Paik)
Re: New Site, Purple/Enigma/Sigaba/Russia Emulators (Charles Petersen)
Re: PGP 6.5.8 test: That's NOT enough !!! (Olaf =?ISO-8859-1?Q?Schl=FCter?=)
avalanche characteristic (Future Beacon)
Re: avalanche characteristic (Ichinin)
Re: avalanche characteristic ([EMAIL PROTECTED])
Re: On pseudo-random permutation (Bryan Olson)
Re: Bytes, chars, and I/O (Mark McIntyre)
Re: On pseudo-random permutation (Bryan Olson)
Re: Destruction of CDs (Guy Macon)
Re: PGP ADK Bug: What we expect from N.A.I. (Ed Reppert)
Re: PGP ADK Bug: What we expect from N.A.I. ("gleu")
Re: avalanche characteristic (Terry Ritter)
Re: My (New) New algorithm ("Scott Fluhrer")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption tool
Date: Sun, 27 Aug 2000 19:58:35 GMT
In article <[EMAIL PROTECTED]>,
No User <[EMAIL PROTECTED]> wrote:
> Put your own encrption algorithm in here:
>
> http://homepages.go.com/~psychlcentral/cipher.html
>
> (source is completely viewable)
Here is my magical puzzle
iz nq u0 0ad tw lx 9rm6 ih 0qp 1ev0aj4a y9s bf0 pmyh ko3t
I used the output of rand() mod 26 + 'a' as the vigenere key.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: RSA Security Conference for 2001
Date: Sun, 27 Aug 2000 13:30:11 -0700
[EMAIL PROTECTED] wrote:
> The 15 pages I can handle (the TC5 paper was 20 pages I think) but I
> don't know much of LaTex at all.
>
> Can somebody please help me get some Latex tools for win98 and how to
> use them?
A commonly recommended TeX for Win32 is MiKTeX
http://www.miktex.org/
There are others. You may want to check the TeX Users Group site.
They seem (unverified) to use teTeX for their TeX Live CD
http://www.tug.org/
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
------------------------------
From: Charles Petersen <[EMAIL PROTECTED]>
Subject: Re: New Site, Purple/Enigma/Sigaba/Russia Emulators
Date: Sun, 27 Aug 2000 13:33:44 -0700
>From what I've been told, they're all relatively weak, so superencipherment
probably wouldn't help all that much. Though I really don't know, anyone
else have comments?
Mok-Kong Shen wrote:
> Charles Petersen wrote:
> >
> > I thought you all might like to check out my new site.
> >
> > http://dev.thinkquest.org/C004911/
> >
> > It has a simulation and explanations of the cryptography used by the
> > major powers of World War II. This includes java applets that emulate
> > the Purple, Enigma, Sigaba, Russian Espionage Cipher, and a public
> > domain Bombe. In addition, there is a public forum reminiscent of
>
> Just curious: If a message is superenciphered with a couple
> of these machines, how vulnerable is it in the time of modern
> technology?
>
> M. K. Shen
------------------------------
From: Olaf =?ISO-8859-1?Q?Schl=FCter?= <[EMAIL PROTECTED]>
Date: Sun, 27 Aug 2000 20:16:39 GMT
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Reading the Senderek report got me stunned. I was very amazed about the
existance of a data part in a public key information record unprotected
by a signature. Is there anything that should go into the non-hashed par=
t
of a public-key block ? From what I see so far the part not protected by=
a signature should remain empty and a warning should be issued if
anything is in there. Why is there even such a thing as the non-hashed
part ?
Here is a list of security issues raised by unsigned parts of a security=
relevant information:
- X.509v1: algorithm parameters outside the signature of certificate. Th=
e
recommendation is now to ignore them and leave them empty upon creation.=
- SSL v2: downgrading attack. List of acceptable algorithms transmitted
without signing or MACing it. Resolved in SSL v3.
- PGP: see senderek report
Probably not complete. S/MIME pending, as there is also an unsigned
information part in PKCS#7.
But should have been enough to learn the lesson.
>>>>>>>>>>>>>>>>>> Urspr=FCngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.08.00, 16:30:03, schrieb "Michel Bouissou" zum
Thema Re: PGP 6.5.8 test: That's NOT enough !!!:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> "Keith" a =E9crit dans le message news:
> [EMAIL PROTECTED]
> >
> > There is no way for PGP to detect a forged key. That is what a
> > signature and trust values are for. As long as PGP removes and/or
> > doesn't recognize the forged ADK on a tampered key, which will lead
> > to the encryption of a file or message to the forged ADK, then that
> > is the proper action.
> You're wrong.
> An ADK should NEVER sit outside of the hashed part of the
> self-signature.
> An ADK sitting in the non-hashed part clearly indicates that this ADK
> has been forged, and PGP *SHOULD* blow sirens when such a situation
> occurs.
> [EMAIL PROTECTED]
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>=
> Comment: Corrigez le bug PGP ADK. Installez PGP 6.5.8 ou plus recent.
> iQA/AwUBOafGW47YarFcK+6PEQL8/gCgziGyjPrAgXW2jTzb25kZaSY4IrgAniiK
> m3qMC/TkmjkeqQtWQwCuhmdO
> =3DA5Bc
> -----END PGP SIGNATURE-----
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: avalanche characteristic
Date: Sun, 27 Aug 2000 17:01:51 -0400
Would sombody please explain what avalanche characteristic means?
Thank you for your help.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: avalanche characteristic
Date: Sun, 27 Aug 2000 12:24:23 +0200
Future Beacon wrote:
>
> Would sombody please explain what avalanche characteristic means?
It's a garantee that (aproximately) 50% of the output bits change
whenever an input bit changes. (If i've understood this right this
applies to both Plaintext and User entropy)
Regards,
Glenn
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avalanche characteristic
Date: Sun, 27 Aug 2000 21:54:15 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Future Beacon wrote:
> >
> > Would sombody please explain what avalanche characteristic means?
>
> It's a garantee that (aproximately) 50% of the output bits change
> whenever an input bit changes. (If i've understood this right this
> applies to both Plaintext and User entropy)
Not exactly. It states that "bit i" of the input will flip "bit j" of
the output 50% of the time when "bit i" is flipped. It doesn't relate
to the # of bits that flip, only the connection between two bits.
If the above holds then yes "50% of the output bits" do change, but
that's not what SAC means.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Sun, 27 Aug 2000 22:36:03 GMT
Mok-Kong Shen wrote:
[...]
> If the collision resolution is chosen such that the first
> element of the pair is always considered less than the
> second, then indeed there is a bias. The effect is however
> dependent on the chance of collision, which is practically
> negligible when the space of the random numbers is large,
> e.g. 32 bits.
Specifically, the when the space of the random numbers is
large compared to the number of elements being permuted.
> One can on the other hand use a random
> choice rule to resolve collision, in which case no bias
> can occur.
False for any of the usual sorting algorithms. Remember
that collisions are not limited to two elements. You could
achieve zero bias (assuming a perfect RNG) by recursively
applying the procedure to each non-singleton collision set.
Though the recursive procedure terminates with probability
one, it is technically a non-terminator. Given a generator
of perfect random bits as the one and only source of
randomness, can you find any procedure for generating
perfectly uniform random permutations (of more than two
elements) that strictly terminates? Can you show that no
such procedure exists?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, chars, and I/O
Date: Sun, 27 Aug 2000 23:55:26 +0100
Reply-To: [EMAIL PROTECTED]
On 27 Aug 2000 14:59:02 +0200, [EMAIL PROTECTED] (Paul Schlyter)
wrote:
>In article <[EMAIL PROTECTED]>,
>Mark McIntyre <[EMAIL PROTECTED]> wrote:
>
>> This is an old debate. The quotes from the standard merely ensure that
>> C compilers must return 1 for sizeof(char). How many bits are in the
>> object pointed to, the standard does not say. It does say how many are
>> used tho - CHAR_BITS. The implementation could use 23 bits for a char,
>> and still return 1. even if CHAR_BITS were 8.
>
>On such an architecture, memcpy() would be quite useless to copy memory
>blocks.....
Why do you think so? memcpy copies objects by obtaining their address,
and copying as many "char" objects as it's told to from that location
to the new one. It doesn't know how large the char is nor does it need
to.
You could not however rely on tricks like copying 4 chars into a long,
and expect to get any sort of meaningful answer. However that's always
been implementation defined so...
--
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Sun, 27 Aug 2000 23:03:17 GMT
Benjamin Goldberg wrote:
> Here's a foolish question: What if you simply sorted your original
array
> using (random()%2 ? 1 : -1) as your comparison function? While I'm
> certain that there has to be something wrong with this (because it
> sounds so simple and noone seems to have suggested it), I don't know
> what it is... especially if your sort routine tries to do the minimum
> number of comparisons.
>
Not a foolish question, but it doesn't quite work. It fails
obviously for typical O(n^2) sorts like bubble sort, and
subtly for O(n lg(n)) sorts.
Consider, for example, merge-sort. When merging two lists,
the un-merged portions of the lists need not be the same
length. If there are m items left in the first list, and n
in the second, we want to take the next element from the
first list with probability m/(m + n).
There's also the trivial problem that many sorts will index
out of bound, or perhaps infinitely loop, if the comparison
operation is not transitive and consistent.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Destruction of CDs
Date: 27 Aug 2000 23:18:26 GMT
Mack wrote:
>
>>Thomas W. Barr wrote:
>>>
>>>How about CD-Rs, is there any equipment of software to roast the disc,
>>>by flipping ALL the data are along the track to its burnt state, not
>>>its blank state? This would add yet another layer of security to the
>>>data and you could then use some of the methods shown earlier in this
>>>thread.
>>>
>>>I, for one, would use a CD-RW for my one-time-pads and then go through
>>>an erase cycle, write 650mb of junk data (make sure you overwrite the
>>>FAT), and erase that. This would remove ALL remnants of data that could
>>>be left behind in the walls of the tracks.
>>
>>Unless your tracking is perfect (it isn't), I can recover most of
>>the original data (laboriously, one bit at a time) with an Atomic
>>Force Microscope. My particular setup (which is for investigating
>>the physics of DVD-RW, not for crypto) would fail to recover anything
>>if you were to repeat your write random/erase cycle 8 or 10 times on
>>the same drive that wrote the original data.
>>
>>It would be cheaper and more secure to use a CR-R and burn it
>>(I mean in a fire pit, not a drive!) afterwards.
>
>Since you are investigating RW disks maybe you can answer a question.
>What temperature (in an oven) should a R or RW CD be heated to
>effectively destroy the data contained? ie. if you overwrite it once and
>then bake at say 400F for 1 hour or something like that?
>
>This has been a recurring topic and it would be nice to get a definitive
>answer.
The metal in CD-RW discs melts at around 600 °C (1,112 °F) depending on
the exact formulation. The crystallization temperature is much lower,
roughly 200 °C (392 °F), which is enough to destroy the data.
CD-Rs are more complicated. The cyanine, phthalocyanine, and Metal Azo
dyes used in CD-Recordable discs are organic photosensitive compounds,
much like those used in making photographs (which explains why Fuji
and Kodak are in the business.) When a CD-R is recorded, the dye is
heated by the writing laser and becomes opaque (or absorptive).
This is due to a combination of the photosensitive effect, chemical
changes related to reaction to the heat, mingling with nearby melted
polycarbonate, a depression in the dye layer caused by a deformation
of the reflective layer beneath, bubble creation, and texture change.
Unlike the CD-RW, the CD-R sets the laser power by doing a test write,
so the actual temperature at the writing point varies widely, and there
is no good method of determining the exact temperature.
Polycarbonate starts to soften and deform at around 130 °C (266 ° F),
is quite soft at 150 °C (302 °F). We mold CDs, CD-Rs and CR-RWs at
271-293 °C (520-559 °F).
I believe (but cannot prove) that the temperature at the CD-R writing
spot is above the melting temperature of Polycarbonate. The temperature
that will make the CD-R unusable will be much lower (does someone care
to do some kitchen oven experiments and post the results?), but the
temperature at which a determined attacker cannot distinguish the
laser written spot from the rest is almost certainly higher than the
melting point of polycarbonate. In fact, I doubt that any amount of
heat will mimic the photosensitivity effect of a laser. For that, I
would look for a way to turn the laser of a CD-R writer full on and do
a 1X burn with it.
(If anyone wants to hire an expert on this sort of thing, my resume
may be found at [ http://users.deltanet.com/~guymacon ] )
CD-R trivia: Take a new blank CD-R. Put it in your CD-R drive and
try to read it. Repeat 101 times. The disc is now unwritable.
If you know why, wait a day before posting the answer so those who
don't know can take a few guesses.
------------------------------
From: Ed Reppert <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP ADK Bug: What we expect from N.A.I.
Date: Sun, 27 Aug 2000 23:17:31 GMT
In article <8oam4g$om$[EMAIL PROTECTED]>, "Michel Bouissou"
<[EMAIL PROTECTED]> wrote:
> - - N.A.I. should integrate into the next PGP releases an option to
> globally desactivate ADK encryption, even if this means refusing to
> encrypt anything to a recipient key which has an attached ADK.
>
> - - And we wish that N.A.I. should release a freeware PGP version which
> is completely ADK-free.
If I understand this whole thing (and I'm not sure I do) ADK is a means
for a third party to require that its public key be included in the
public keys of certain parties (employees, in the one somewhat unclear
reference to ADK I've seen, and perhaps citizens, in a country which
requires that agencies of its government have access to all encrypted
data transmitted to or from its citizens or locations {eg, RIP in the
UK, or similar efforts in the US) so that anything destined for that
party can be decrypted by the third party. While I can see the interest
in such a capability, it seems to me to violate the spirit of the whole
concept of personal privacy in communications. However, that's a
political question more than a technical one, and I have some technical
ones.
I have downloaded the freeware 6.5.8 version (for MacOS) that was put up
at mit on Friday. Looking at it, the pgp 6.5 manual that came with it,
and at the previous version (6.5.4) of the freeware package, I can find
no reference to how to include an ADK in a public key. I infer that this
capability is *only* in the commercial version of the software. Is that
correct?
Freeware 6.5.8 does have a flag which would indicate if an ADK is
present, but not, if I understand correctly, whether it is inside or
outside the encrypted "envelope" of the key file. IOW one can tell if an
ADK is present, but not if it breaks confidence in the privacy of the
encryption (assuming one doesn't care -- or is resigned to accepting it
-- if a known third party can decrypt the message). Is this correct?
Assuming these conclusions are correct, it seems to me that (1) the
inclusion of a mechanism to allow a third party to require that he be
privy, whether the two primaries want him to be or not, to their
communication is a violation of the very concept of privacy through
encryption, (2) that vendors of encryption software should not (and
certainly not on their *own* initiative) make such a mechanism
available, and (3) having compromised the integrity of their product,
such vendors should, as quickly as possible, do whatever is necessary to
remove the mechanism or, at the very least, to ensure that it cannot
compromise private communications without the knowledge and consent of
the primary parties concerned.
If the above is a correct assessment of the situation, then I agree with
M. Bouissou, and in particular with the two suggestions cited at the
beginning of this message.
If my assessment is flawed, please tell me how. :-)
------------------------------
From: "gleu" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP ADK Bug: What we expect from N.A.I.
Date: Mon, 28 Aug 2000 00:29:38 +0100
John Berger <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> - ----------------------------------------------------
> They 'did' write up something on the CERT webpage, and said that they
> found nothing abused by this bug. It is simple to see 'now', because
> it's been explained to us and those with more understanding about
> this stuff see it as more <cough> disastrous, than say, someone like
> me.
>
> Since they say that it hasn't been exploited on any of the 1.3
> million or so keys on the server, then a 'disaster' hasn't really
> occurred, but maybe more like 'averted' before a dishonest person of
> Ralf's knowledge found out what he did and used it for the wrong
> thing.
>From a commercial perspective, it IS disastrous for PGP and NAI. As an
individual user, I will continue to use PGP because I only need a mundane
level of privacy ... in the same way or reason that I usually post my
letters wrapped in envelopes and also because I believe the flaw is
difficult to exploit. But if I was doing business online or communicating
confidential information at work electronically, there is NO WAY that I
would trust or recommend PGP now irrespective of whether the vulnerability
has/has not been exploited yet. Why would I put an alarm system in my house
which would protect everything except for that little back window ... and be
told it's OK, the window is not broken and therefore you can carry on
trusting the alarm system.
I applaud Mr Bouissou for the effort he has put in to test, clarify and
explain the exact nature of the vulnerability and wholly support his
proposals - get rid of the bloat, subject PGP to peer review. Although I
understand NAI's reticence in making the source code of a commercial product
open to public scrutiny, security through obscurity is an unacceptable
choice for a crypto system. At the very least, they should now allow expert
independent cryptographers to review the product (indeed this could only be
done by experts!) and give it a clean bill of health.
...snip
> Y'all be good and take care,
>
> Johnny B
> - --
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: avalanche characteristic
Date: Sun, 27 Aug 2000 23:32:17 GMT
On Sun, 27 Aug 2000 17:01:51 -0400, in
<[EMAIL PROTECTED]>, in
sci.crypt Future Beacon <[EMAIL PROTECTED]> wrote:
>Would sombody please explain what avalanche characteristic means?
See, for example:
http://www.io.com/~ritter/GLOSSARY.HTM#Avalanche
Avalanche
The observed property of a block cipher constructed in layers or
"rounds" with respect to a tiny change in the input. The change of a
single input bit generally produces multiple bit-changes after one
round, many more bit-changes after another round, until, eventually,
about half of the block will change. An analogy is drawn to an
avalanche in snow, where a small initial effect can lead to a dramatic
result. As originally described by Feistel:
"As the input moves through successive layers the pattern of 1's
generated is amplified and results in an unpredictable avalanche. In
the end the final output will have, on average, half 0's and half 1's
. . . ." [p.22]
Feistel, H. 1973. Cryptography and Computer Privacy. Scientific
American. 228(5): 15-23.
Also see mixing, diffusion, overall diffusion, strict avalanche
criterion, complete, S-box, and the bit changes section of the Ciphers
By Ritter / JavaScript computation pages.
Avalanche Effect
The result of avalanche. As described by Webster and Tavares:
"For a given transformation to exhibit the avalanche effect, an
average of one half of the output bits should change whenever a single
input bit is complemented." [p.523]
Webster, A. and S. Tavares. 1985. On the Design of S-Boxes.
Advances in Cryptology -- CRYPTO '85. 523-534.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: My (New) New algorithm
Date: Sun, 27 Aug 2000 16:13:17 -0700
Slava K. <[EMAIL PROTECTED]> wrote in message
news:8oaf1l$kkd$[EMAIL PROTECTED]...
> I have thought of another encryption algorithm. Please tell me what you
> think
> (Again, the algorithm is described in generalized programming terms):
>
> 1. A password of length n is entered (Passwords of 2 bytes of smaller make
> the
> algorithm inadequate, so using them should not be allowed).
> 2. Two random values are generated: r1 and r2.
> 3. Two copies of the password are saved in memory: p1 and p2.
> 4. p1 is advanced by r1 characters for each byte/bit it encrypts.
> p2 is advanced by r2 characters for each byte/bit it encrypts.
> 5. A byte/bit is read from the input file. It is then encrypted like so:
> c = p (XOR p1[r1] XOR p2[r2])
Question: what do you mean "p1 is advanced by r1 characters"? What
algorithm do you mean to advance a random value?
>
> The obviouse problem with this algorithm is that the entire password is
not
> used. This means that another password could generate the same results.
> However, if the password is long enough, the possibility of the program
> selecting the same random numbers when a password with the exact same
bytes
> in the exact same locations is entered is negligible.
>
> - NOTE - In order to enable the decryption of the file, r1 and r2 should
be
> saved along with the file.
>
> <EMail me your comments to [EMAIL PROTECTED]>
>
>
------------------------------
** 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
******************************
