Cryptography-Digest Digest #289
Cryptography-Digest Digest #289, Volume #12 Wed, 26 Jul 00 06:13:01 EDT Contents: Re: TheArgon Site (James Pate Williams, Jr.) Re: Playing with an 8 bit cipher. (Mack) Re: How is the security of Outlook Express encryption ? (Greg) Re: Proposal of some processor instructions for cryptographical applications (Greg) Re: How is the security of Outlook Express encryption ? ([EMAIL PROTECTED]) Re: How is the security of Outlook Express encryption ? (jungle) Re: FAQ (jungle) Re: WinZip (Sébastien SAUVAGE) How to Convert p12 Files to Ascii for certificate installation ([EMAIL PROTECTED]) Re: purpose of final swap in Twofish? (Runu Knips) Re: AESC-stream cipher ([EMAIL PROTECTED]) Re: purpose of final swap in Twofish? (=?iso-8859-1?Q?H=E5vard?= Raddum) Re: How to Convert p12 Files to Ascii for certificate installation (Paul Rubin) Re: CypherCalc - Any good? (Mark Wooding) Small hash checksum ([EMAIL PROTECTED]) Re: Cursory Comments on Recursion (Mok-Kong Shen) Re: Database encryption (Mok-Kong Shen) Re: MD5 Collision Resistance (Mark Wooding) Re: Database encryption (Paul Rubin) Re: News about quantum computer (Mok-Kong Shen) Re: 8 bit block ciphers (Runu Knips) Re: 8 bit block ciphers (Runu Knips) From: [EMAIL PROTECTED] (James Pate Williams, Jr.) Subject: Re: TheArgon Site Date: Wed, 26 Jul 2000 05:15:28 GMT On Tue, 25 Jul 2000 17:07:44 -0400, "George Gordon" [EMAIL PROTECTED] wrote: Hi group, Can anyone help this poor site? I think it's of some value to the community. http://www.theargon.com Regards, George What does the acronym ARGON stand for and why is this site germane to sci.crypt readers? From elementary chemistry we know that argon is an "inert" gas, a.k.a "noble" gas and is used in some lasers and other forms of illumination. ==Pate Williams== [EMAIL PROTECTED] http://www.mindspring.com/~pate -- From: [EMAIL PROTECTED] (Mack) Subject: Re: Playing with an 8 bit cipher. Date: 26 Jul 2000 06:14:20 GMT "Trevor L. Jackson, III" [EMAIL PROTECTED] wrote: If you have MIPS to use instead of memory you could emulate the permutation table with a smaller working set. You'd need a lookup function that, given a single byte of input (virtual array index), would return the contents of the shuffled table that you don't have room to store. The lookup function would have to (laboriously) backtrack the shuffle process until it could determine the contents of the desired slot in the table. This can probably be implemented in only a few bytes, but would take O(N^2/2) operations on average where each operation is a virtual byte swap driven by the RNG controlling the shuffle. Since N is 256, this is not going to be fast. That is why I was looking for 8 bit block ciphers that were reasonbly fast. On the fly calculation with minimal memory. Mack Remove njunk123 from name to reply by e-mail -- From: Greg [EMAIL PROTECTED] Subject: Re: How is the security of Outlook Express encryption ? Date: Wed, 26 Jul 2000 06:10:07 GMT Does anyone know what is the key lenght of Outlook Express's singing/encryption ? Irrelevent. And is it safe enough ? Irrelevent. Outlook Express uses CryptAPI which is in itself unsafe. I developed a piece of software that placed itself between OE and the crypto layer and intercepted the plain text. From this result, you can imagine that the data could be covertly sent over the internet to a clandistine ip address from a virus and you would never know it was happening (well, 99.999% of the population would never know it). Look at my web site for some additional information on this topic http://www.ciphermax.com -- Tyranny is kept at bay by guns and will. Our government knows we have the guns, but they don't know if we have the will. Nor do we. The only lawful gun law on the books- the second amendment. Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Greg [EMAIL PROTECTED] Crossposted-To: comp.arch Subject: Re: Proposal of some processor instructions for cryptographical applications Date: Wed, 26 Jul 2000 06:14:22 GMT At the second level, the swapping is done separately on each half of the word. Analogously for the higher levels. Doing this isn't very difficult either. Consider: mov r14, #ff orr r14, r14, r14, lsl #16 eor r1, r0, r0, lsr #8 and r1, r1, r14 eor r0, r0, r1 eor r0, r0, r1, lsl #8 It can get hard (and a lot of fun too) if you use a RISC that has lots of parallel execution features that can be exploited to make the overall process much faster once you arrange the instructions just right. -- Tyranny is kept at bay by guns and will. Our government knows we have the guns, but they don't know if we have the will. Nor do we. The only lawful gun law on the books- the second amendment. Sent via Deja.com
Cryptography-Digest Digest #290
Cryptography-Digest Digest #290, Volume #12 Wed, 26 Jul 00 12:13:01 EDT
Contents:
Re: Playing with an 8 bit cipher. (Runu Knips)
Re: Proving continued possession of a file ("Rick Heylen")
Re: Rabin's information dispersal algorithm (Wei Dai)
Re: TheArgon Site (John Savard)
Re: Small hash checksum (Anders Thulin)
HTTPS SSL ([EMAIL PROTECTED])
Re: Playing with an 8 bit cipher. ("Trevor L. Jackson, III")
Get Free Software (George Peters)
Re: Steganographic encryption system (Mark Evans)
Re: Steganographic encryption system (Mark Evans)
Re: 8 bit block ciphers ("Scott Fluhrer")
Re: Debating Behaviors in sci.crypt (Adam Durana)
Re: Small hash checksum (Paul Koning)
Re: RC4-- repetition length? (Mark Wooding)
Re: How is the security of Outlook Express encryption ? (Guy Macon)
Re: Question.How to avoid weak curves? (Robert Harley)
Jackboots straw isn't above the law: ("Sam Simpson")
Re: Proving continued possession of a file (Andru Luvisi)
Re: AESC-stream cipher (Jerry Coffin)
Date: Wed, 26 Jul 2000 12:06:13 +0200
From: Runu Knips [EMAIL PROTECTED]
Subject: Re: Playing with an 8 bit cipher.
Mack wrote:
This is to be part of a larger function. Its use is an s-box.
Ah ! Okay.
When using embeded applications with only 64 bytes of
memory it really isn't practical to use all of it for the
encryption.
Yep.
--
From: "Rick Heylen" [EMAIL PROTECTED]
Subject: Re: Proving continued possession of a file
Date: 26 Jul 2000 11:10:46 GMT
There's a mild theoretical problem with this if the file contains repeating
data and the important informational content of the file is the order in
which the repeating pattern occurs. For instance if the file's data is
structured such that the numbers x_1 through x_m only take two values x_one
and x_two then Bob can just store x_one, x_two, the number (t) of x_one
blocks and the sum (u) of all the y values such that x_y == x_one. When
challenged by Alice, Bob's response is
response=x_one^(t*b*r+u*i*r)*x_two^( (m-t)*b*r + (m*(m+1)/2-u)*i*r)
Storing x_one, x_two, t and u requires much less storage for Bob and the
computing time for the response is much shorter.
The reason why we can store it in less space is that most of the
information about the order in which the x_one blocks and x_two blocks
occur in the file has been thrown away. The reason why we can throw it away
but still relply to the challenge correctly is that we can store the sum of
the exponents for all the bases which are the same. The method generalises
to the cases where x_1 through x_m take a number (less than m) of distinct
values.
Rick
--
I've got an allergy to Perrier, daylight and responsibility.
PGP key 512/CA5CADED C/C++, Java and Optical Media Expert
Key fingerprint = 00 00 00 00 00 65 AB 2F 76 EB EF F7 9C 10 FA 88
--
From: Wei Dai [EMAIL PROTECTED]
Subject: Re: Rabin's information dispersal algorithm
Date: Wed, 26 Jul 2000 04:38:10 -0700
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
says...
Generally it's desirable for no information about the message to be
leaked if the attacker has less than n pieces, which is obviously not
the case for this method. However, that could still be achieved with the
same efficiency by applying an AONT to the message before splitting it.
Alternatively, create a temporary random "message" R of size 128*n bits,
split R as described above, and make public the real message encrypted
under hash(R). (This is not quite the same as an information dispersal
algorithm because of the extra public data, but it can be used for some
of the same applications.)
IDA is mostly used for reliability rather than secrecy. In some
applications being able to recover useful partial information with less
than n pieces may actually be a desirable feature.
Besides AONT, there is also an older idea for using IDA as a secret
sharing algorithm, described in the paper "Secret Sharing Made Short"
by Hugo Krawczyk. The idea is to encrypt the message with a random
symmetric key, secret-share the key, and information-disperse the
encrypted message. Append each piece of the encrypted message with a
share of the key to obtain a share of the message.
--
cryptopp.com - a free C++ class library of cryptographic schemes
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: TheArgon Site
Date: Wed, 26 Jul 2000 12:35:33 GMT
On Wed, 26 Jul 2000 05:15:28 GMT, [EMAIL PROTECTED] (James Pate
Williams, Jr.) wrote, in part:
From elementary chemistry we know
And I recall seeing on the web something called "The Eye of Argon",
which was a silly burlesque of stories in the Conan genre.
John Savard (teneerf -)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
--
From: Anders Thulin [EMAIL
Cryptography-Digest Digest #291
Cryptography-Digest Digest #291, Volume #12 Wed, 26 Jul 00 15:13:01 EDT
Contents:
Re: Get Free Software (Mark Wooding)
Re: Playing with an 8 bit cipher. (Mack)
Re: 8 bit block ciphers (Mack)
Re: Proving continued possession of a file (Andru Luvisi)
Re: Question.How to avoid weak curves? (Mike Rosing)
Re: Small hash checksum (Mack)
Re: Get Free Software (George Peters)
Re: How is the security of Outlook Express encryption ? (Mack)
looking for s-box generator ("ET")
Re: How is the security of Outlook Express encryption ? ("???")
Re: Get Free Software (Tom Anderson)
Re: Cryptographic Camouflage ("Joseph Ashwood")
Re: Get Free Software ("Joseph Ashwood")
Re: looking for s-box generator (Runu Knips)
Re: AESC-stream cipher (Tom Anderson)
Re: AESC-stream cipher (Tom Anderson)
MD5 algorithm questions (Scott Long)
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Get Free Software
Date: 26 Jul 2000 16:37:32 GMT
George Peters [EMAIL PROTECTED] wrote:
At www.endecs.com/uenigma.exe an entire suite of encryption products
is available. Because of specilized setup, it is a self-extracting
.exe which you will need to run the setup.exe after extraction.
Oh. This is the sort of `free' software which isn't really free at
all. No source code, no right to modify the software...
The web page http://www.endecs.com/ is a scary place. It's another of
these bizarre `secure mail exchange' things.
: This service will provide you and other people signed up for the
: service the ability to send email and attachments securely.
That's a good idea. So good, in fact, that Phil Zimmerman had it years
ago.
: The chief benefit from using the service is you don't have to worry or
: deal with anyone's personal key.
Oh, dear. Alarm bells are ringing by this point.
: It will work like this:
:
: * You sign up (no setup fees!) for the service. We will create a
: profile for you and send your personal key and software to you
: (similiar to our Eureka Email product). There will only be a $5
: fee a month for personal and $15 a month for corporate accounts.
Wow! They give me my own key, to save me from choosing a bad one! This
must be secure.
No, hang on. How do they send me my key, and make sure that nobody can
read it on the way? I'd recommend using PGP-encrypted email, but that
rather begs the question of why I'd want to prat about with this EnDecs
thing. (GnuPG, which is PGP-compatible is proper Free Software.)
: * You encrypt a message and/or attachments using our software
: (perferrably addressing it to another registered client) and your
: messages will be sent to us for processing.
:
: * We receive the email and using your personal key on file, decrypt
: the message and/or attachments and if the recipient is also signed
: up for the service, we'll encrypt it again using the other
: person's personal key. We'll then send it along for delivery.
: The person you are sending data to does not have to be registered
: with the service if no encypted data is being sent.
Ummm... But then they get to read all of my mail. I have to trust them
not only to write secure software and put proper encryption in it (which
I don't), but also to handle all of my mail which is too sensitive for
me to send unencrypted. For as long as I use the service.
Of course, I could use GPG on my messages before sending them to EnDecs,
but this rather defeats the point.
: * When you receive an encrypted message, you then use your personal
: key to decrypt the data.
:
: Nothing could be easier! Even if you are sending to multiple people,
: each will arrive encrypted with their own personal key. No shared
: keys, no key management, no hassles!
No security!
-- [mdw]
--
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Playing with an 8 bit cipher.
Date: 26 Jul 2000 16:40:35 GMT
"Trevor L. Jackson, III" [EMAIL PROTECTED] wrote
Do you have a definition of "reasonably fast"? What is your desired data
rate?
Can you tolerate variations in the data rate?
I don't know what the limits are going to be in practice. Since only
relatively
small amounts of data are to be transfered the data rate can be fairly low.
The maximum amount of data would be between 64 and 128 bytes.
Each transaction should complete in about 1/10 of a second so the
mechanism you describe might prove useful.
The backtracking mechanism mentioned above would require on average 512
operations
(the original description is wrong), but has a worst case performance of 32K
operations (the frequency of this condition is 1:256!). If you have a low
power
machine at 10 MHz your average throughput would be about 2 Kb/sec.
Mack
Remove njunk123 from name to reply by e-mail
--
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 26 Jul 2000
Cryptography-Digest Digest #293
Cryptography-Digest Digest #293, Volume #12 Wed, 26 Jul 00 20:13:01 EDT
Contents:
Re: purpose of final swap in Twofish? (Eric Smith)
Re: MD5 algorithm questions (Bill Unruh)
Skipjack (David A. Wagner)
Re: purpose of final swap in Twofish? (David A. Wagner)
how to cirucmvent the rip (AskAlice)
Re: AESC-stream cipher ("Trevor L. Jackson, III")
Re: "Symmetric" RSA encryption (Bill Unruh)
Re: MD5 algorithm questions ("Joseph Ashwood")
The Purple Cipher (World War II) (Charles Petersen)
Re: Random Appearance (Future Beacon)
What is DES3mCBCMACi64pPKCS5? (Paul Rubin)
Re: Get Free Software (jungle)
Re: MD5 algorithm questions (Bill Unruh)
Re: RC4-- repetition length? ([EMAIL PROTECTED])
Re: Cursory Comments on Recursion (wtshaw)
Re: "Symmetric" RSA encryption (John Myre)
Re: "Symmetric" RSA encryption (John Myre)
Re: MD5 algorithm questions ("Joseph Ashwood")
Re: Elliptic Curves encryption ("Joseph Ashwood")
From: Eric Smith [EMAIL PROTECTED]
Subject: Re: purpose of final swap in Twofish?
Date: 26 Jul 2000 14:48:58 -0700
[EMAIL PROTECTED] (David A. Wagner) writes:
I would have expected execution time to be affected by
1% and code size to be increased by a few instructions,
On the 6805, the added code size is about five bytes each for
the decrypt and encrypt routines. Admittedly this is not very much.
However, on low-end microcontrollers there may less than 2 Kbytes of
ROM available. I'm currently trying to implement this on PIC
microcontrollers with 1 Kword (by 14 bits) of EPROM/Flash.
If they do, it seems that changing your
algorithm to one designed specifically for constrained environments might
make much more of a difference than any tweaking of the swaps in Twofish.
Twofish is reportedly designed to be suitable for constrained environments.
Choosing another algorithm is only practical if you are in control of both
endpoints of the communications. If you want to interoperate with a host
that does Twofish, you don't implement DES at your end.
Anyhow, I was just wondering what the supposed benefit of the
extra/missing swap was, and it seems to be essentially nothing. I'm
obviously not arguing that it should be changed. I just thought that
there might have been some deeper significance that I'd overlooked.
--
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.security.unix,alt.computer.security
Subject: Re: MD5 algorithm questions
Date: 26 Jul 2000 21:52:02 GMT
In [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes:
Are all unique messages which are SHORTER than the MD5 code length (128
bits) guaranteed to have different MD5 hashes? In other words, does
No.
there exist a 64-bit message that has the SAME MD5 hash as a different
64-bit message? Or is there only a possibility of hash collisions for
Unknown for your specific example of exactly 64 bits (probably they do
not have a collision.) As far as I have seen, the best estimates are to
compare it to a random output of 128 bits. Ie, any a, no matter what the
length has an output which is some uniform random selection from the
numbers less than 2^128. Thus, if you chose all numbers less than say 64
bits, there would be about a 50% probability that two would have the
same hash (Birthday paradox-- which actually does not apply to birthdays
because the probablity of a certain date being a birthday is not the
same for all days of the year).
messages that exceed 128 bits in length? I realize that the probability,
if it exists, is very small.
Also, if I want to fold the 128-bit hash into 64-bits, is it sufficient
to exclusive-or the top 64 bits with the bottom 64 bits? Please note
that I'm NOT using this for any security purposes, and therefore any
security arguments against doing this do not apply; I'm only using MD5
in order to get a good hash code of some data.
Or just throw away the top 64 bits, or the bottom 64 bits, or every
second bit, take a 64 bit CRC of the 128 bits, or
If truncating MD5 in any of those ways gave a bad hash (ie one which
made it easy to find collisions-- or was not uniformly distributed-- then
this would make the whole of MD5 weak-- of course we do not know that it
is not weak, just that no such simple weakness has not been found.
(Note I am not an expert-- the above is based on readings and thinking I
have done. If I have made an error I assume I will get corrected by an
expert)
--
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Skipjack
Date: 26 Jul 2000 14:49:54 -0700
Has anyone looked at the 256-element Skipjack S-box to see if it can
be expressed with less memory? For instance, is there any chance it
is itself expressable as a 4-round Feistel network with some choice of
4-bit S-boxes? Does anyone know of any way to determine whether such
a representation exists, for this size table?
Apart from a factual
Cryptography-Digest Digest #292
Cryptography-Digest Digest #292, Volume #12 Wed, 26 Jul 00 18:13:01 EDT
Contents:
Re: Random Appearance (Future Beacon)
Re: purpose of final swap in Twofish? (Eric Smith)
"Symmetric" RSA encryption (John Myre)
Re: Database encryption (Mok-Kong Shen)
Re: Random Appearance (Mok-Kong Shen)
Re: AESC-stream cipher (Mok-Kong Shen)
Re: purpose of final swap in Twofish? (David A. Wagner)
Re: purpose of final swap in Twofish? (David A. Wagner)
Re: How is the security of Outlook Express encryption ? ("Donald L. Nash")
Re: AESC-stream cipher (David A. Wagner)
Re: Database encryption ("Kevin Crosbie")
Re: Database encryption (Paul Rubin)
Re: AESC-stream cipher (David A. Wagner)
Re: "Symmetric" RSA encryption (Steve Weis)
Re: 8 bit block ciphers (David A. Wagner)
Re: Elliptic Curves encryption ("diana")
Re: 8 bit block ciphers (Paul Rubin)
Re: "Symmetric" RSA encryption (David A. Wagner)
From: Future Beacon [EMAIL PROTECTED]
Subject: Re: Random Appearance
Date: Wed, 26 Jul 2000 15:09:53 -0400
On Tue, 25 Jul 2000, Mok-Kong Shen wrote:
Future Beacon wrote:
I agree with you that if the sentences are to make sense together
in a reasonable context, the problem is enormous; however, I there
is no disproof of the possibility. I believe that there is no basis
for a disproof and that the problem is simply very hard to solve.
For the moment, please consider the problem of making an isolated
sentence or a series of isolated sentences from a string of random
numbers. One approach is to have a data base of characters, words,
and frequently used phrases and for this data base to be shared by
the sender and receiver. The words and phrases would need to be
organized by grammatical function. It should be possible to select
a noun or noun phrase when you want one or to select any part of
speech similarly. You must have a strictly defined grammar which
may not be identical to any of the popular ones (which tend to be a
little vague). Let us call the parts of speech P1 through Pn.
Sentence structures requiring rules of composition might be called
S1 through Sm and the ith one might be
Si = P4 P17 P20 P9 P2.
If you have 4000 words and phrases that function as a P4, you might
use two bytes to encode it. Notice that few words are conveyed
with only two bytes. Few random numbers make for many sent letters.
If disguise were done independent of the encryption, sent files
would be large. For that reason, I feel that the plain text message
should undergo a grammatical analysis in order to benefit from the
compression it would get. I believe that the two processes about
balance out while providing an opportunity for encryption at the
random-like number stage (the intermediate stage).
Requiring the sentences to make sense together is a daunting task.
If vocabulary is restricted as it is in real messages (you are
talking about cars so you don't say car and then house and then
computer, you say car and then car and then car), then the pattern
of repeats cannot be correlated with similar kinds of repetition
in the plain text.
All of this prompts me to suspect that the disguise process cannot
be independent of the encryption process but must be tailored to it
in one sense to make sure that it is independent in the other sense.
There is a factor (a small one) that makes the task less demanding
than it might otherwise be: The relatedness of the sentences in
real messages is not often as high as it is in a mathematical proof
or in a textbook account of a concept. People put paragraph endings
almost anywhere. The wiretapper cannot expect to understand why
things are said unless a long history is involved. If the task is
not to raise suspicion and not to motivate a long historical record,
maybe a little daftness actually helps.
If you just want to have the transform of one single sentence from a
fixed set of sentences to be natural, then, as I mentioned, the task is
trivial.
.
.
.
This is not the idea at all. I am sorry for rushing through
my explanation. I think I will try to explain a smaller piece
of it first.
This a description of compression using grammatical analysis:
You have constructed a formal grammar for English and you have
a number of parts of speech (P1 through Pn). For each part of
speech there is a list of words (let's forget punctuation and
phrases for now). List Pi contains all of the English words that
can function as that part of speech. A given word may appear in
more than one list. The full collection of lists is held by both
the sender and the receiver.
Let us suppose that the plain text is this:
one if by land and two if by sea
For the sake of a concrete image, let us also assume that the
encryption method is the one-time pad. It could be any method.
First, we assign
