Cryptography-Digest Digest #970, Volume #10 Tue, 25 Jan 00 08:13:01 EST
Contents:
Re: MIRDEK: more fun with playing cards. (Rex Stewart)
Re: Why did SkipJack fail? (Jerry Coffin)
Re: Transposition over ASCII-coded text (wtshaw)
Re: simplistic oneway hash (wtshaw)
Re: What's with transposition? (wtshaw)
Re: Why did SkipJack fail? (Paul Rubin)
Re: Java's RSA implimentation (Paul Schlyter)
Re: McDonald's claims Nobel peace fries (Guy Macon)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: "Trusted" CA - Oxymoron? (Paul Rubin)
----------------------------------------------------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Tue, 25 Jan 2000 05:16:14 GMT
In the last few hours I realised I posted an obvious error in the
paragraph below. Yes knowing the substitution table AT A SINGLE POINT
in time IS THE SAME as knowing the right hand deck. I was still
thinking in the mode of trying to hit a moving target. Knowing 26
points on the table, each one related to a different point in time is
pretty much worthless, but I made the cardinal mistake of posting
something I had not completely thought through - and in the middle of
it I made a leap from logical to ludicrous.
My appology if this sent anyone up a blind alley.
I should have realised when I wrote that last line,
it was too late in my day to post :-)
In article <86i1oc$mrj$[EMAIL PROTECTED]>,
Rex Stewart <[EMAIL PROTECTED]> wrote:
> Reply to Paul Crowley:
> > Redesign time, I think.
> I don't think so. Prove the flaw exists first - it may not.
> As I said in another post, the only way I can see to crack this is to
> recover the state of the RIGHT deck by encrypting 25 separate texts
> differing by only a single letter always occuring in the same position
> - and then 25 more with the positions incremented. And encrypting
> those 25 separate texts with the same key and the same IV. And then
> repeating the ENTIRE process again at a different point in the text to
> recover the other deck after the switch. I can see no way to recover
> the left deck directly. While you would develope a substitution table
> for the left deck I do not think that is the same. You would only be
> able to tell something about the rotations induced on the left deck by
> the right deck.
>
>
> I think I have reached the point where I am beginning to ramble.
> --
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Mon, 24 Jan 2000 23:06:52 -0700
In article <QM7j4.1539$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Greg <[EMAIL PROTECTED]> wrote:
>
> : Can anyone please share their views on why SkipJack failed in
> : the market place?
>
> All this from memory:
>
> o It used a classified algorithm, and hence was not open to public
> review.
>
> o It would have made ciphertext readable by anyone who could
> convince the keepers of the LEAF keys that his was a good
> and noble cause.
Technically speaking, you're talking about Clipper, not SkipJack
itself -- I.e. SkipJack is the algorithm that was going to be used in
the Clipper chip.
I think, however, that this does show one of the reasons very few
people show much interest in SkipJack: it was _badly_ tainted by
association with Clipper. Almost regardless of HOW good a cipher it
happened to be, it would take little short of a miracle to survive
that kind of fiasco.
Worse yet, unless memory serves me particularly badly today, analysis
has shown some degree of weakness in SkipJack. SkipJack use an 80-bit
key. This is large enough to render attack by key-exhaustion
difficult at best today (it provides about 16-million times as many
keys as DES) it still doesn't leave a lot of "headroom."
Worse yet, (from one viewpoint) SkipJack was carefully designed to
require _extremely_ minimal hardware. That makes it easier to include
in minimal hardware like a smartcard.
OTOH, it almost makes it easier to build a truly huge number of
encryption engines on a relatively small number of chips if you decide
to break SkipJack by exhausting the keyspace.
Combining these two factors leaves me, for one, with a feeling that
SkipJack probably doesn't provide particularly good long-term
security. Even in the short term, I'd be quite hesitant to use it for
protecting extremely sensitive data.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Transposition over ASCII-coded text
Date: Mon, 24 Jan 2000 23:20:24 -0600
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
>
> >... Messages can be input in a less redundant form, as in using telegraphic
> > abreviations. The skill in reading such things is easily learned, as is
> > that for writing it.
> >
> > Interestingly enough, many of those in crypto are already well schooled in
> > doing this, almost a complete list of chronic and serious posters in this
> > group. ...
>
> Oh, I don't know.
>
> *Some* posters can be quite redundant.
>
> Or did you mean the posters who are both chronic and serious,
> not both the serious posters and the chronic posters?
>
Chronic posting is taken as being merely habitual. The brotherhood of
hams about is well known to many of us. Some of us even have commercial
telegraphic experience.
In spite of the beauties of the internet and its reasonably dependable
commonication, with the recovery of my right hand being noticable in the
last month, I have dusted off the ole rig and am looking forward to 30m
one day soon. Some things are deep passions, hamming and crypto, to name
two.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: simplistic oneway hash
Date: Mon, 24 Jan 2000 23:30:48 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Dan Day) wrote:
> On 20 Jan 2000 23:43:55 -0500, [EMAIL PROTECTED] wrote:
> >1) It must be simple to code (no more than a couple dozen lines)
> >2) It must be collision free
>
> If you truly need it to be "collision free", then what you're
> looking for is not a hash function, but an encryption algorithm.
>
> Hash functions necessarily produce collisions any time the input
> can have more bits than the hash output.
>
> An encryption algorithm, on the other hand, necessarily produces
> a unique output for every unique input. (And without the key
> in hand, can obviously be considered "one way" -- if it isn't,
> it's a lousy encryption algorithm.)
>
Certain encryption algorithms can produce varieties of ciphertext outputs,
of which each will be decipherable to the same plaintext. This is the
opposite of a hash. Decryption using such algorithms can be the same as a
hash, just start with text as the ciphertext and decript to a hashtext.
Note the clear distinctions between hashtext, plaintext, and ciphertext.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What's with transposition?
Date: Mon, 24 Jan 2000 23:35:03 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> agreed, simple transposition, by itself, is perhaps easily cracked
> but...
> if you have ever played, as a kid or with kids, "How many words can you
> make of the following letters?" then you know that it can be quite
> challenging, especially if you are talking thousands of chars. If you
> transpose AND THEN encrypt (with a good algo) the security should
> increase.
> Peter Rabbit
Obvious increases in strength come from intelligent use of two
complementary primatives rather than just one.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Why did SkipJack fail?
Date: 25 Jan 2000 07:13:26 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>Worse yet, unless memory serves me particularly badly today, analysis
>has shown some degree of weakness in SkipJack. SkipJack use an 80-bit
>key. This is large enough to render attack by key-exhaustion
>difficult at best today (it provides about 16-million times as many
>keys as DES) it still doesn't leave a lot of "headroom."
Skipjack has related key attacks like many other ciphers. The best
published known-plaintext cryptanalysis *almost* shows weakness, i.e.
that the designers gave it as many rounds as it needed but not more.
>Worse yet, (from one viewpoint) SkipJack was carefully designed to
>require _extremely_ minimal hardware. That makes it easier to include
>in minimal hardware like a smartcard.
What viewpoint is that?! For some of us, this is a huge advantage and
is Skipjack's main selling point.
>OTOH, it almost makes it easier to build a truly huge number of
>encryption engines on a relatively small number of chips if you decide
>to break SkipJack by exhausting the keyspace.
It probably needs around the same amount of chip area as DES.
DES was designed for hardware implementation. Skipjack appears
designed for 8-bit microcontroller software implementation.
>Combining these two factors leaves me, for one, with a feeling that
>SkipJack probably doesn't provide particularly good long-term
>security. Even in the short term, I'd be quite hesitant to use it for
>protecting extremely sensitive data.
That is a wise assessment. It still leaves lots of data for which
Skipjack's security is more than good enough. Remember that
distributed.net (the "world's fastest computer") has been crunching a
single RC5-64 message for *years* and has searched only a small
fraction of the 64-bit keyspace. I think it will be a long while
before anyone can break Skipjack messages in "production" volumes.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Java's RSA implimentation
Date: 25 Jan 2000 09:01:09 +0100
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>> In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>>> : B = A;
>>> :
>>> : Will the B = A discard the old B and create a new copy of B?
>>>
>>> B is not now itself a BigInteger object, but a (reference to an) array
>>> of them.
>>
>> Which means arrays aren't "first class citizens" in Java?
>
> Huh?
>
> (define a (vector 10))
> (define b (vector 10))
> (set! b a)
>
> b is now a reference to a (is bound to a). Hence arrays aren't
> "first class citizens" in Scheme?
If there are no way to copy the array (except in a loop where each
array element is copied, one by one), arrays aren't first class
citizens in the language. That's the situation in C and C++.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: McDonald's claims Nobel peace fries
Date: 25 Jan 2000 05:45:31 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Idiot/Savant) wrote:
>
>On 19 Jan 2000 20:56:10 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>
>>Peace on Earth and Big Macs to all men
>>
>>by James Langton
>
>[...]
>
>>New research in America has uncovered a previously unrecognised
>>fact of diplomacy: no country with a McDonald's has ever gone to
>>war with another.
>
> Wasn't there a McDonalds in Belgrade?
>
No.
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 25 Jan 2000 11:02:09 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 25 Jan 2000 08:22:38 -0000
Rex Stewart <[EMAIL PROTECTED]> writes:
> > I strongly suspect that a chosen plaintext attack would choose the
> > plaintext "AAAAA...." since that makes least use of the state of the
> > left deck.
>
> > Oh bugger. If you guess where this letter appears in the left pile,
> > then you can infer the state of the right deck within 25 characters,
> > and thus get the state of both decks in 50. If you're using Mirdek -
> > don't encrypt the sequence "A" x 50 :-)
>
> I don't think this is the case - as you say IF you guess where this
> letter appears in the left pile. And do it 25 straight times.
It's even worse than I'm imagining. If you know the plaintext is a
stream of 'A's, then each ciphertext letter tells you where the A card
was immediately before the letter search. After the letter search, of
course, the A will be as far from the bottom as it was from the top.
So you know where the A is before and after the count cut, from which
inferring the discarded card is trivial. After 51 ciphertext letters
you have the state of the entire deck. No need to guess anything.
What I'd like to do to fix this is to replace the count cut with a
different kind of letter search, but I can't think of a search with
the right properties:
* dependent on the position of the searched-for letter, not the letter
searched for
* reversible, given the searched-for letter
* for each card in the old state of the left deck, every new position
is equiprobable
* ideally it would do some mixing too
Actually, I can think of one but it's unwieldy: just cut cards from
the top to the bottom until the searched-for card is as far from the
bottom as it was from the top (ie one card if it's on the top, three
if it's second, 5 if third etc). Better suggestions would be very
welcome!
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 25 Jan 2000 08:30:46 -0000
[EMAIL PROTECTED] (Paul Rubin) writes:
> In article <[EMAIL PROTECTED]>,
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> >It's not a downside that necessarily applies to randomised stream
> >ciphers where the randomiser is sent along with the message; this is
> >true of Mirdek, and we've heard some ideas about how that could be
> >done for ARC4-52 and ARC4-Rubin (the CRT-based variant).
>
> Um, I don't think there's such a thing as "ARC4-Rubin". The CRT thing
> is just a different way of physically/mentally manipulating the cards
> that's supposed to be a little easier.
This is so only if you use the correct conversion from card to number
in the final output step, which could be tricky to do in your head
unless I'm missing a trick.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: 25 Jan 2000 13:00:05 GMT
In article <6ENi4.12674$[EMAIL PROTECTED]>,
Jim Bennett <[EMAIL PROTECTED]> wrote:
>I have been reviewing the Certification Practice Statements of various
>issuers of X.509 digital certificates for S/Mime email. I have been trying
>to find one that really tries to verify the identity of the certificate
>applicant and will do it for the general public. I haven't been too thrilled
>with what I found.
>
>Why do I care? If you are going to use a personal digital certificate for
>signing an email that has significant legal implications, like a request to
>withdraw $100,000 from your bank and have the funds wired somewhere else,
>you sure as hell want to make sure the person who has signed the message is
>really the person he says he is.
Normally in a situation like that, you'd want some other
authentication besides just the CA, no matter how good the CA is. For
example, the bank would (through secure means) get the checksum of the
customer's certificate and store that in their database. "Secure
means" are generally available when the transactions get that large:
there is usually one-on-one interaction involved. The idea of PKI
is that it makes many-to-many interaction simple. When the interaction
isn't many-to-many, the PKI stuff isn't that useful.
>Now let's see how various vendors have attacked the problem.
>
>VERISIGN (www.verisign.com)- The best you can get from them is a requirement
>that you respond to a challenge email sent to the email address you have
>asserted is yours. Well, whoopee. Anyone with access to your POP inbox can
>assert they are you. Value: minimal.
That's Verisign Class 1 which is better than nothing in some situations,
but certainly shouldn't be considered anything more than low security.
Verisign Class 2 (still offered? I don't know) meant you filled in a
form with some personal info and they looked it up in an online credit
bureau database. Medium security--you can get credit cards online that
way, so it's not totally worthless.
Verisign Class 3 (for companies): you have to register with Dun & Bradstreet
and fax your incorporation papers to Verisign. They call your administrative
contact on the phone for confirmation. This is what you need for SSL web
site certificates from them. The security is nontrivial.
For something like that bank using client certs for $100K customers,
they'd probably use Verisign Onsite, which is a remotely administered
CA (hosted by Verisign) that the bank gets to run themselves through a
web interface. Quite a cool product.
>THAWTE (www.thawte.com)- Your identity must be vouched for by a group of
>people whom Thawte has determined are trustworthy. How does Thawte determine
>this? If you have had your identity vouched for a selected number of times
>by different people, you are considered capable of vouching for other
>people's identity. Better than Verisign, but not much. A group of several
>co-conspirators could vouch for false identities for each other fairly
>easily. Value: still not good enough for a high value transaction.
At first, the only people allowed to sign in this system were lawyers
and public notaries. That is about as good as one could ask for in
this situation. These days, anybody can sign. I wonder if the signer
certificates have any bits indicating that the signer is a lawyer or notary.
If you can tell that from the signer cert, you have a pretty good system.
>USERTRUST (www.usertrust.com) - Better. These guys will do a background
>check on you to try to confirm your identity claims, and will arrange for
>you to buy a fidelity bond to cover people who rely on your certificate. But
>they are currently only doing this for "contracted projects", which to me
>sounds like big jobs.
This sounds kind of strange. When there's a big job, there's generally
enough person-to-person interaction to agree on a set of certificates to
use, rather than relying on any type of public CA.
>PGP - You have to trust the key signers, but if you are dealing with a
>stranger, you are unlikely to know any of the key signers. Value: usually
>zero, occasionally good.
If the key signer is a notary, or a CA like Thawte (which does issue
PGP signatures), the certificates are of some value.
>Does anyone know of a CA who will do what UserTrust claims to do, but on an
>individual basis for the general public?
What exactly do you want them to do?? Run a background check on you
where they investigate your neighbors?! Wow. In-person notaries
generally just look at your drivers' license.
------------------------------
** 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
******************************
