Cryptography-Digest Digest #197, Volume #14 Sat, 21 Apr 01 04:13:01 EDT
Contents:
Re: Basic AES question (David Formosa (aka ? the Platypus))
Re: ancient secret writing (John Savard)
On the Validity of Non-Logical Modes of Thought (The Constrained OTP) (John Savard)
Re: XOR_TextBox: Doesn't write to swap file if... (Anthony Stephen Szopa)
Re: MS OSs "swap" file: total breach of computer security. (Anthony Stephen Szopa)
Re: Minimal Perfect Hashing (wtshaw)
Re: newbie: cryptanalysis of pseudo-random OTP? ("Osugi Sakae")
Re: Can this be done? ("Mark Lomas")
Re: digital certs What is the format of the file? ("Bryan Olson")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Basic AES question
Reply-To: [EMAIL PROTECTED]
Date: Sat, 21 Apr 2001 04:23:10 GMT
On Fri, 20 Apr 2001 13:23:51 GMT, Lou Grinzo <[EMAIL PROTECTED]> wrote:
> Thanks to Paul and the others for responding.
>
> As best I can tell from the replies, there doesn't seem to
> be a technical reason for limiting keys to those three
> sizes.
There is a technical reson. If you know the key sizes it makes
protocols design easer.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: ancient secret writing
Date: Sat, 21 Apr 2001 04:43:44 GMT
Although posting binaries to discussion groups is *very* naughty, the
image appears to be of shorthand, perhaps the well-known and
still-used Pitman or Gregg.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: On the Validity of Non-Logical Modes of Thought (The Constrained OTP)
Date: Sat, 21 Apr 2001 05:11:39 GMT
Somewhat offhandedly, I proposed that a "serious" military OTP
application might take the form of a five-step encipherment, wherein
between three applications of some conventional encryption with a
short secret key, one first applied a 'constrained' OTP, and the
second time a truly random OTP:
i.e.
plaintext -> DES -> add COTP -> DES -> add UOTP -> DES -> ciphertext
Someone asked, quite legitimately, if I was kidding. After all, the
chance of a one-time-pad page coming up with all zeroes to the length
of the message is no greater than the chance that this method might
just happen to have the right UOTP page values to, by coincidence,
produce a ciphertext that matches the plaintext.
This is quite true, and I did know that.
In my response, I pointed out that a cipher system might be 'designed
by committee', and the committee members might include people of
varying cryptologic sophistication.
Thus I posited 'General Jones', who wanted the COTP, because he was
uncomfortable without being sure to change the message before
encrypting, 'Dr. Smith', who, recognizing the theory behind the OTP,
insisted on the true OTP, which I distinguished by calling it the
UOTP, or unconstrained one-time-pad, and 'Mr. Robinson', who took
practical considerations into account, and saw that a simple additive
or XOR combiner of an OTP with a message was dangerously simple, and
the massive volumes of OTP key were vulnerable to compromise, and
insisted on also having conventional encryption layers.
But I could go further than that.
For one thing, Mr. Robinson, if he is the NSA representative on the
committee might think as follows about the COTP and the UOTP:
<begin "quote">
In practice, looking for OTP pages that look like LFSR output, for
example, is a waste of time, one won't find them. But on the other
hand, electrical failures that cause an all-zero page come often. So
even the UOTP page producers will have to check, after an all-zero or
all-one page, that something hasn't happened to the device. But even
an electrical failure that goes away, leaving no trace, after the
generation of a page with a large string of zeroes or ones, is vastly
more probable than a truly randomly generated large string.
Thus, instead of a COTP run by people with a sentimental viewpoint,
and a UOTP run by people with a theoretical viewpoint, two OTPs run by
people of a more practical bent would be optimal. However, these two
pads are adequate - and by being generated with different philosophies
help to ensure separate generation and distribution networks, which
are highly desirable from a security standpoint.
<end "quote">
Already we're seeing that practice may vary from theory.
Now then, though, I can understand that the position of General Jones
may seem downright silly, based on the mathematical fact I noted above
- that plaintext is just as likely by accident in this kind of system
as an all-zero OTP page is. Is General Jones, then, like the toddler
who, when asking for another cookie, is satisfied when the one in his
hand is broken in half and a half is placed in each of his hands?
Not necessarily. Let's grant that he was intelligent enough to
understand what was going on in the discussion around him, and let him
speak for himself.
There is a distinction between the plaintext matching the ciphertext
in the proposed system, and in a simple OTP system, because in the
simple OTP system, it can be determined before encipherment that this
will happen (the material from the pad to be used can be inspected to
determine if it is all zeroes), whereas in the proposed system,
particularly if suitable conventional encryption modes are used, a
ciphertext resembling plaintext coincidence would only become apparent
after encryption takes place.
Why would this distinction be of any importance? Let's listen to
General Jones now:
"I understand that what's going to come out of this cipher machine is
a random jumble of letters that could say anything at all, including,
by a coincidence with astronomical odds against it, something that
says what the plaintext does. Things like that do happen, and they
can't be avoided.
But the messages that go out in cipher are about things like the
course travelled by airplanes or boats on missions. Lives depend on
them.
When one of my boys doesn't come home from a mission, I want to be
able to say to his parents or his wife that we did everything we could
to support his mission, and make it a successful one from which he
would return.
If a radioman were to pick up a sheet from a one-time-pad with all
zeroes on it, and use that to encrypt his orders, I couldn't look them
in the eye and say that honestly. Even if the possibility of using
such a page benefited the security of other messages, consciously
doing this would be a deliberate decision to treat this one soldier or
pilot or merchant ship as expendable."
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR_TextBox: Doesn't write to swap file if...
Date: Fri, 20 Apr 2001 22:10:57 -0700
HiEv wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > "Ryan M. McConahy" wrote:
> [snip]
> > > HELLO?!? You don't know much about crypto, do you? XOR is broken! Read
> > > Applied Cryptography! I quoted it earlier, didn't I? It doesn't matter
> > > wether or not it swaps to disk!
> >
> > Offer anyone in this news group $1000 if you cannot break their
> > encrypted messages using XOR then.
>
> Ok, let's say there is a theoretical situation where you could intercept
> someone's XORed output so that you could attempt to crack it. Wouldn't
> that situation also usually allow you to also get the OTP (One Time Pad,
> the file that you use to encrypt your plaintext) that produced the
> cypertext?
>
> And if it doesn't, why wouldn't that person use the method that they are
> using to send the OTP to send the cypertext?
>
> Also, people don't usually send just one message like this, and multiple
> messages make it easier to crack because they either always have to send
> a new OTP or indicate to the receiving party what the OTP is, or they
> reuse the same OTP, which is really dumb because then you've given away
> your key. Many people will do this though, even though they've been
> told not to, because it's easier than always choosing a new OTP.
>
> Furthermore, your software doesn't bother to check for randomness or
> long series of nulls. If I used XOR with a file I didn't realize had a
> large section of nulls I could end up sending a chunk of my message in
> plaintext!
>
> You need to realize that an XORed file, by itself is useless to
> everyone, including the intended receiver, the important part is the
> OTP. If I want to send multiple encrypted files to a friend in, say
> Germany, and the person who I want to receive this may not be the only
> person who sees these messages, how am I supposed to hide what the OTP
> is?
>
> Your claim that someone would need to crack one XORed file to prove the
> vulnerability of the system is ridiculous because it is an unrealistic
> situation. If a person is using an encryption system and because
> someone may be intercepting their messages then a public key system,
> like PGP, is the way to go.
>
> Tell you what though, you send me two XORed files encrypted with the
> same OTP and I'll show you how to decrypt the shorter one entirely, the
> same number of bytes of the longer one, and recover that much of the OTP
> to boot! :-)
I don't get it.
I said that all the XOR_TextBox does is perform the XOR process on
what the user types into the textbox with another file the user
supplies; or it performs the XOR process on two files the user
provides and displays the results in the textbox.
The idea is that the original message is not written to disk in
either case. (This depends on your particular system. See the
instructions in the latest XOR_TextBox Version 1.21 ) That's it.
There are no other claims being made regarding the files used in this
process.
So what you are talking about is other than what the software states
it is about. It's another issue that you may want to start another
thread on.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Fri, 20 Apr 2001 22:29:37 -0700
wtshaw wrote:
>
> In article <_XIC6.22803$[EMAIL PROTECTED]>, "Tom St
> Denis" <[EMAIL PROTECTED]> wrote:
>
> > "wtshaw" <[EMAIL PROTECTED]> wrote in message
>
> > > It does not follow that if a better choice is available why one would seek
> > > a ride in a leaky boat with only a slight hole in it. I doubt you
> > > understand what you advocate nor the limitations of trying to fully
> > > control the effects of a black box.
> >
> > Now repeat your reply in English please.
> >
> > Tom
>
> The basic problem like Jessica Rabbit is that security need not be bad, it
> is just drawn that way. It is not for want of the knowledge of how yo do
> things correctly, just that the prospective has been that insecurity is
> better for national security and discouraging autonomous systems.
>
> The fly in the ointment as far as the power mongers is that different
> teams did not always agree and some designs have turned out to be much
> more secure than others.
>
> Fortunately for them, hype has sold the worse plans to almost everyone.
> People worship quantity over quality. To protect the beast, the code has
> been obscure. Tools have been designed with certain peculiar limitations
> to keep accessory products insecure and under central control. External
> improvements suffer under a poor architecture and a swamp of system code
> to try to figure out. This was all shortsighted because covert faults
> that were touted as good are showing as its Mr. Hyde side.
> --
> Ah, so! Chop suey on a bagel. Now...say, "So Sorry."
He is going to ask you again to say it in English.
If he can't recognize the problem then no matter what he says, he
cannot solve the problem. He's great at trying to trash someone
else's ideas, though.
But I know what the problem is and I intend to solve it at least as far
as my own encryption software is concerned.
I do not plan to signal what my solution is but when it is ready you
will be satisfied with my approach.
I know what needs to be done and I have found all the resources
needed to implement it.
There is a solution and I have figured it out.
I will adhere to the advice I have offered the President: "Don't
talk about it: do it. Don't tell us: show us."
(About 1360 days left and counting.)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Minimal Perfect Hashing
Date: Fri, 20 Apr 2001 23:43:15 -0600
In article <jw7E6.46$ZP6.1452@client>, "Dann Corbit"
<[EMAIL PROTECTED]> wrote:
> >
> > All hashes have collisions. You fill not find what you want for it
> > violates that truth.
> > If you have a hash, the output will have less information in it that the
> input.
>
>
> Unless (of course) it's a perfect hash.
>
> Consider the following hash for 32 bit unsigned integers:
>
> f(u) = u
>
> A perfectly valid hash function.
>
There are some that are exceptions to my second statement. In them the
several outputs could yield the same input, and the output hashed would
still result in itself.
A counted hash of these letters -> acpzovedkbslq jwmftgnhxyiru
acpzovedkbslq jwmftgnhxyiru -> acpzovedkbslq jwmftgnhxyiru
--
Bash a rash hash dashed for cash. Stash in casche mashed clash.
------------------------------
From: "Osugi Sakae" <[EMAIL PROTECTED]>
Subject: Re: newbie: cryptanalysis of pseudo-random OTP?
Date: Sat, 21 Apr 2001 15:08:00 +0900
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, "Leonard R. Budney"
<[EMAIL PROTECTED]> wrote:
> "Osugi Sakae" <[EMAIL PROTECTED]> writes:
>
>> I meant them (1-5) as a sequence for generating a pseudo-random OTP.
>
> Note that "pseudo-OTP" is a term that newbies constantly make up,
> thinking it's an original idea. The term should not be used; it's very
> deceptive. A genuine OTP is 100% unbreakable. Anything else is not a
> OTP, period. So it's a bad idea to give it a name which suggests
> security comparable to a OTP.
Ok, got it. Sorry about the bad terminology.
> What you're doing is generating a pseudo-random sequence, and XOR-ing it
> with the original message. This notion already has a name: it's called a
> "stream cipher". (No, it's not the only kind of stream cipher. But it is
> how most stream ciphers work.)
[snip]
> Your analogy with a caeser cipher is a good one, though. If the key
> sequence is sufficiently non-random, then you could read a message by
> "guessing" the key bits using a similar bias to the cipher. Guesses
> can be checked against a dictionary, so the entire crack can be
> automated if the PRNG is lousy enough.
I don't understand "the key bits using a similar bias to the cipher".
What does that mean?
> Your thinking wasn't bad; it appears you did stumble onto the notion of
> a stream cipher. Your idea amounts to inventing a PRNG which uses a book
> as its input. And it could almost work: you might indeed find a way to
> "bleach" the content of a book into something fairly random-looking.
So that is theoretically possible. that is one thing i was wondering
about.
> However, it would not be practical. Having pointed out the notion of a
> stream cipher, I bet you can see why. The first problem you've already
> addressed: the book must be computer readable--but things like Gutenberg
> texts will serve.
[snip]
Thanks for the help. This is much clearer to me now. Just need a little
more experience (something else?) to make the conceptual jump from
traditional ciphers that manipulate letters in easy to understand ways to
computer ciphers and all the maths involved. Oh, well, if it was easy, it
wouldn't be interesting.
--
Osugi Sakae
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Mark Lomas" <[EMAIL PROTECTED]>
Subject: Re: Can this be done?
Date: Fri, 20 Apr 2001 14:13:43 +0100
If Bob receives two messages, one from Alice and one from Eve, each
containing a different public key, followed by similar messages from both
Alice and Eve all of which are signed as you suggest, how can he tell
whether Eve is duplicating Alice's messages or Alice duplicating Eve's?
You might also consider the case where Alice and Eve send identical
messages (i.e. both claim to know the same private key). Apart from
looking at the times at which each message is delivered, is there any
way to determine which of them really knows the key?
n.b. I regard time as a poor discriminator in the above thought experiment.
Mark
p.s. If I were in Alice's position I might be tempted to generate a message
of the form "My name is Alice" followed by some random padding, hash
and sign it, then send it to Bob with no explanation (i.e. just the hash -
not the message itself). If Eve were ever to replicate this then I would
reveal the message to Bob, with instructions for validating it. It might be
interesting listening to Eve's explanation.
"John Wasser" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [[ This message was both posted and mailed. ]]
>
> Alice sends a message containing her public key (or she can add it to
> one or more of the messges). Alice hashes each message and encrypts
> the hash with her private key.
>
> Bob decrypts the hash with the known public key to find that the
> decrypted hash matches the message. This proves that all messages were
> sent by someone who knows the private key that matches the public key.
>
> The public key
>
> In article <[EMAIL PROTECTED]>,
> Julian Morrison <[EMAIL PROTECTED]> wrote:
>
> > Here's a scenario:
> >
> > Alice sends messages to Bob. The messages are sent in clear, but Alice
> > includes a "check hash" with each message that allows Bob to ascertain
> > that (1) the message matches its hash, and (2) all the messages were
> > generated by someone who knew some unspecified secret, said secret being
> > provably the same for all the mesages.
> >
> > HOWEVER, Bob does not know this secret, he and Alice do not exchange any
> > information (the flow of data is solely from Alice to Bob), nor can he
nor
> > anyone else listening in determine this secret. And, no-one without the
> > secret can forge new hashes that falsely seem to have been created by
> > Alice.
> >
> > The result being: all the messages are proven to come from the same
place,
> > despite that place remaining anonymous.
> >
> > Can this be done? If so, how?
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: digital certs What is the format of the file?
Date: Sat, 21 Apr 2001 07:47:36 GMT
normangrant wrote:
>I have done a few searches of the web for digital certs and find a lot of
>information on how it works etc etc.
>
>The problem is WHAT do you do if you want to write such a file??. Let me be
>pedantic.. If I wanted to write to a x509 cert DER CA cert, what is the
>exact format needed. I really could not believe that this was not readily
>available on the web!! Thanks
The format is complex, and it's a big bunch of work to
program an encoder or parser from scratch. That said, if
you really want to do so there are some excellent references
that you can find for free on the web.
The X.509 standard itself is not (usually) free, but RFC
2459 contains the specification for the X.509 certificate
format and the profile for internet. There are many sources
for RFC's so just use your favorite search engine.
/ASN.1 Complete/ by John Larmouth is clear, reasonably
concise, and nevertheless will tell you more than you ever
wanted to know about ASN.1 and DER/BER encoding. It's
published as a book, and worth buying if you're really going
to encode or parse certificates, but it's also on-line for
free download with registration. Try:
http://www.oss.com/asn1/booksintro.html
Paul Rubin pointed to the "Layman's Guide", which is free
reference popular with cryptographers. Personally I haven't
used it since I got Larmouth's book.
If you actually need to *use* the certificates, not just
encode and decode them, then Peter Gutmann's "X.509 Style
Guide" is required reading:
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
--Bryan
------------------------------
** 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
******************************
