Cryptography-Digest Digest #72, Volume #13 Thu, 2 Nov 00 05:13:00 EST
Contents:
Re: Really Strong Cipher Idea? (John Savard)
Crypto Export Restrictions (Anthony Stephen Szopa)
Re: CHAP security hole question (Thomas Wu)
Re: Crypto Export Restrictions (David Schwartz)
Re: Is RSA provably secure under some conditions? (D. J. Bernstein)
Re: Emacs hack for OpenSSL encryption (David Rush)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: BENNY AND THE MTB? (Richard Heathfield)
Re: Crypto Export Restrictions (David Schwartz)
Re: Crypto Export Restrictions (Richard Heathfield)
Re: BENNY AND THE MTB? (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Really Strong Cipher Idea?
Date: Thu, 02 Nov 2000 04:52:46 GMT
On Wed, 01 Nov 2000 10:22:47 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Have it more than twice as large as a message segment, then after
>transposition and encryption, XOR together two parts the size of a
>message segment,
With some small changes, the scheme is now illustrated at
http://home.ecn.ab.ca/~jsavard/crypto/co041205.htm
with a diagram, just after the "large-key brainstorm", since it is
another way to use a large key.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 00:13:20 -0800
Crypto Export Restrictions
I seem to do some very good thinking when I get good and mad.
I've been getting good and mad again, lately.
New software will be available for direct download worldwide, and
soon, at ciphile.com
You may recall that I developed OAP-L3: Original Absolute Privacy -
Level3 encryption software.
I then read the latest BXA info restricting the export of such
encryption software.
I determined that there was absolutely no restriction on random
number generation software.
So I simply removed completely the encryption capability from the
source code and recompiled the software and renamed it OAR-L3:
Original Absolutely Random - Level3 random number generation
software. It is exactly the very same software as OAP-L3 except it
has no encryption capability and there is no way to activate it
since the new compilation was done after removing the encryption
capability source code.
Anyone can directly download shareware OAR-L3 from
http://www.ciphile.com and going to the Downloads Currently
Available web page. Scroll to the bottom of the page and click
on the blue "OARL3_41.zip" hyperlink.
You can also request shareware OAP-L3 encryption software by
clicking the blue "email" hyperlink at the top of the Pricing
and Ordering web page.
I've been getting good and mad again lately.
New software will be available for direct download worldwide, and
soon, at ciphile.com
AS
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: CHAP security hole question
Date: 02 Nov 2000 00:28:32 -0800
[EMAIL PROTECTED] (Vernon Schryver) writes:
>
> There is a problem unrelated to presentation with schemes with the aim in
> http://www-cs-students.stanford.edu/~tjw/srp/whatisit.html
>
> SRP is a secure password authentication protocol. It solves the
> problem of authenticating clients to servers securely, in cases
> where the client must memorize a small secret (like a password) and
> carries no other secret information, and where the server carries
> a verifier which allows it to authenticate the client but which, if
> compromised, would not allow someone to impersonate the client.
>
> That problem is that description applies when a human needs to memorize
> a single password. Set asside the fact that much authenticating involves
> two computers, no humans, and so much less need for ideas like EKE and
> SRP. (Computer can memorize secrets that are immune to dictionary attacks,
> and nothing can be done to completely protect computers from having their
> memories opened and their secrets read.)
But as long as humans must authenticate themselves over networks using
secrets stored in their heads, strong password protocols are useful.
And aren't humans really the ultimate endpoints for all these fancy
cryptographic technologies?
> Many people now should have many distinct passwords, and eventually most
> will need many passwords. You need a password for each of many web sites,
> from newspapers to stock brokers to merchants and banks. It would be even
> worse to use a single common password that to write down a bunch. So what
> can you do? You can use a a few shared passwords for throw-away accounts
> such as free newspapers, but you really shouldn't share a password among
> your 401K, on-line bank, medical, and stock broker accounts. You could
> buy PKI snake oil and put all of your authentication eggs into a PKI
> vendor's single basket, but people who think see that PKI can reduce the
> number of secrets but not enough to be managable by most human memories.
I'm not sure what you mean by "PKI snake oil", but once again the aim of
strong password protocols is to improve network security without further
inconveniencing the user. While it is not good practice to share passwords
between sites, for example, some users will do it, and I don't think there's
a easy way to prevent it. If zero-knowledge password protocols are in use,
however, it makes it that much harder for, say, a rogue admin from one site
to harvest passwords that he can try elsewhere.
> A reasonable smart card containing passwords would solve such problems
> better than zero knowledge schemes. The problem of authenticating the
> user to a smart card is nontrivial, and never mind whether it would
> involved biometrics, a 100 digit PIN, or one of the zero knowledge schemes
> that do not require computers at both ends. There's also the problem of
> losing the smart card. Still, a smart card containing dozens of good
> (big) passwords makes far more sense than using SRP or EKE to let one to
> use dozens of poor passwords kept straight in human memory.
>
> In the long run, perhaps smart cards will contain GBytes of stable
> storage, have heads-up displays, and be called PC's.
When we get cheap, powerful, universal, interoperable, secure smartcards
into everyone's hands, you might have a point. But that utopia may
never materialize. Why bet on it?
> In other words, there are good reasons why zero knowledge schemes have
> not taken the Internet by storm, ...
Reasons, maybe, but not particularly good ones. I'd attribute it mostly
to a combination of ignorance and inertia. But even that is changing
these days.
> but are far from cutting-edge brand new
> (contrary to Integrity Sciences). That doesn't mean they're not valuable,
> just as the snake oil from the "unbreakable one time pad random number"
> vendors does not imply that every encryption scheme other a one time pad
> is junk.
>
>
> Vernon Schryver [EMAIL PROTECTED]
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 00:39:17 -0800
Anthony Stephen Szopa wrote:
>
> Crypto Export Restrictions
>
> I seem to do some very good thinking when I get good and mad.
>
> I've been getting good and mad again, lately.
>
[snip]
> I then read the latest BXA info restricting the export of such
> encryption software.
Have you even _read_ the current policy? It places practically no
restrictions on crypto export to Austria, Australia, Belgium, Canada,
Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary,
Ireland, Italy, Japan, Luxembor, Netherlands, New Zealand, Norway,
Poland, Portugal, Spain, Sweden, Switzerland, or the United Kingdom. In
anby event, your algorithms look suspect, so it's just as well that
you're not peddling them as suitable for encryption.
DS
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Is RSA provably secure under some conditions?
Date: 2 Nov 2000 08:44:47 GMT
Philip MacKenzie <[EMAIL PROTECTED]> wrote:
> The question is, when non-cryptographers ask
> about a scheme that has a proof in the
> random oracle model, what do you tell them?
Tell them the truth.
The attacker's success chance depends on the hash function. We don't
know whether any particular hash function is safe, but we do know that
if the _average_ success chance over all functions is high then the
attacker can factor public keys.
In my experience, the phrase ``generic attack'' is much more helpful
than nonsense like ``ideal hash function'' or ``magic hash function.''
---Dan
------------------------------
From: David Rush <[EMAIL PROTECTED]>
Subject: Re: Emacs hack for OpenSSL encryption
Date: 02 Nov 2000 08:50:56 +0000
[EMAIL PROTECTED] writes:
> David Rush <[EMAIL PROTECTED]> wrote:
> > I find it dismaying how little free (speech) software exists for
> > securing files (as opposed to email). Here's my US$0.02. I'm hoping
> > that someone finds it useful.
>
> To be fair, most of those "email" packages can also work on files
> painlessly. (ie, pgp or gpg with the -c option)
Indeed, but command-line tools really aren't very secure. Encryption
needs to be integrated into end-user editing tools (e.g. emacs,
StarOffice) or you end up making quite a few insecure copies. Ok, if
you remember top delete them, but since editting sessions tend to be
long-lived those 'temporary' files still hang around for quite a
while.
> As to the rest, I suspect most people find encryption at the file
> system level more convient.
And far less portable, otherwise I wouldn't be whinging.
> (ie, scramdisk,
^^^^^^^^^ - 'doze
> encrypted loopback mounts,
^^^^^^^^^^^^^^^^^^ - Linux-only as far as I have found
> CFS, etc)
^^^ - difficult to obtain, interoperation issues with existing NFS
If there's a good way around these problems, that will run on
Slowlaris, Linux, &cet, and is available outside the US (as CFS should
be now that crypto restrictions have been eased) I'd appreciate a
pointer and will probably switch.
Also, ssl-hacks.el now lives at
http://cryptognome.sourceforge.net/ssl-hacks.el
david rush
--
>From the start, when it was the instrument of the wood-god Pan, the
flute has been associated with pure (some might say impure)
energy. Its sound releases something naturally untamed, as if a
squirrel were let loose in a church." --Seamus Heaney
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 00:54:11 -0800
David Schwartz wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Crypto Export Restrictions
> >
> > I seem to do some very good thinking when I get good and mad.
> >
> > I've been getting good and mad again, lately.
> >
> [snip]
> > I then read the latest BXA info restricting the export of such
> > encryption software.
>
> Have you even _read_ the current policy? It places practically no
> restrictions on crypto export to Austria, Australia, Belgium, Canada,
> Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary,
> Ireland, Italy, Japan, Luxembor, Netherlands, New Zealand, Norway,
> Poland, Portugal, Spain, Sweden, Switzerland, or the United Kingdom. In
> anby event, your algorithms look suspect, so it's just as well that
> you're not peddling them as suitable for encryption.
>
> DS
Suspect?
Anyone who would make such a claim and not support it is clearly a
nasty person.
------------------------------
Date: Thu, 02 Nov 2000 08:30:08 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >Tim Tyler wrote:
> >>
<snip>
> >>
> >> I don't think "256 messages" comes into it. The interceptors have
> >> received a *particular* byte. They are not considering what messages
> >> could be transmitted by *any* single byte value, but the message that
> >> is *actually* transmitted by one specific byte - the one they have
> >> intercepted.
> >
> >If this is only one byte out of many, then I withdraw my bafflement -
> >it's just a partial ciphertext, and that puts a completely different
> >complexion on things.
>
> It might be better to wait for Tims words if mine inflame you.
> But I can;t resest the temptaion to try. But in the example the
> ciphertext which just happened to be "8 bits" for the compressed
> encrypted message. For the key I used the actaul message was 19
> bytes ( words) So ever got it would have to go to the code dictionary
> to find the actually message whicj would contain 19 words.
If a message compresses to 8 bits, then it can only be uncompressed in
256 different ways, for any given algorithm and any given key. I agree
that, if Eve doesn't know what the key is, then there are 2^(key_bits +
8) different possible decompressions from her point of view. But from
Bob's point of view (for he /does/ have the key), if this is the only
octet in the ciphertext, then there are only 256 different ways to
interpret it.
<snip>
> >Perhaps my source of confusion is a relativistic one.
> >
> >From Bob's point of view, the incoming byte can only convey one of 256
> >messages (if it is indeed a complete ciphertext - obviously, if it's a
> >partial ciphertext, this doesn't apply).
>
> No both know that the byte can only contain one of 256 possible
> patterns. But I think what your missing is that the bijective compression
> and encryption can not add information to the data it is working on.
> Many methods like PGP do things so one can check to see if the correct
> key is used. That does not happen in this kind of compression encryption.
> NOTHING IS ADDED. But it may seem like a paradox that since the byte
> can only be one of 256 message then the attacker in your mind ought to
> be able to limit it down to 256 possible message. The key though
> is that the attacker has no idea what key was used this key has many bits
> long. Almost any key used will give a new possible message.
This seems to accord with my guess that you (and Tim) discuss this in
terms of attack rather than in terms of Bob's message space (if I am
using that term correctly).
> But what is true. Is that if the attacker knows what key was used.
> He could consturct in advance what the possible message are. And for
> a given key there are only 256 possible messages for one byte.
If I understand you correctly here, then my confusion is resolved. There
are, indeed, only 256 possible messages for one octet, when the key is
fixed. If the key is not known then, of course, those 256 bit patterns
could be hooks into any message at all. I understood that before. It
would appear, then, that there is no ambiguity after all.
<snip>
> It seems strange only because people have been expertly
> psychologically conditioned to do compression and encryption
> the wrong way so that groups like the NSA remain in control
> and can break and read your code. I don't think Im smarter
> than every one else. Many its the way my brain operates that
> has given me partial immunity to this expert conditioning.
> That has so much seemed to have inflected havic on the
> open crypto community. It is so good that the misinformation
> spreads just like a cult religon. Look at Tommy and the crap
> he spreads I think he actually means well but he has this
> software brain virus in a bad way I think.
Right up until this paragraph, I was thinking "Good Lord, Mr Scott has
actually written an intelligent and informative reply". It is a great
shame that you had to spoil it with misplaced paranoia and ad hominum
attacks.
Nevertheless, I thank you for confirming that I had merely misunderstood
the context in which you were claiming > 256 messages for one octet.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 01:18:29 -0800
Anthony Stephen Szopa wrote:
> Suspect?
>
> Anyone who would make such a claim and not support it is clearly a
> nasty person.
I'll let people judge for themselves, but the following statements on
your web site are not exactly encouraging:
"Uses no mathematical equations"
"We claim that messages properly encrypted using the full implementation
of OAP-L3™: Original
Absolute Privacy - Level3 © (patent pending) encryption software are
practicably unbreakable. If you
can demonstrate a generally practicable systematic method for
consistantly breaking these encrypted
messages within 180 days from your date of purchase you will recieve a
full refund."
"The next upgrade, Version 4.3, will include three new routines to
process the random array files called
MixFiles: 1) a shift routine where the user may decide to shift each
element value within an array left or
right by 1 to 9 elements, 2) a "flip" routine that will reverse the
order of array element values in each
array, 3) an add routine where each array element value consisting of a
digit from 0 - 9 will have a user
determined number from 1 - 9 added to it, with any result exceeding 9
having 10 subtracted from it."
"Let me emphasize again using the first example above: your key will
generate 2920 data bytes. And
these 2920 data bytes will have a security level equivalent to 2000 bits
and enable you to encrypt
9.2E15 bytes. Can you spare the space on your hard drive to store 2920
bytes?"
"Okay. So now you have generated the original encryption data file
containing all 3,628,800 possible
ten-digit permutations of the digits 0 - 9 with no repeats in ascending
order. How will this file be used?
To generate the random numbers that will ultimately be used to create
the OTP files, three files
containing 3,628,800 ten-digit permutations of the digits 0 - 9 with no
repeats are required. They will
be called MixFile1.otp, MixFile2.otp, and MixFile3.otp. Each of these
files must be thoroughly shuffled.
That is to say, the permutation order must be randomly rearranged in
each file. There are several
processes the software uses to shuffle the permutation order in each
MixFile(X) individually, and one
that shuffles the MixFile(X)s all together."
If course, the biggest problem is that no explanation is given of where
the randomness actually comes from. You can mix numbers to get random
numbers, but you need randomness in order to mix. Where does the initial
randomness come from? No clue.
DS
------------------------------
Date: Thu, 02 Nov 2000 09:49:33 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.hacker
Subject: Re: Crypto Export Restrictions
[Bit of a massive crosspost, isn't it? alt.freespeech snipped - my news
server doesn't like it - I wonder why not? :-) ]
David Schwartz wrote:
>
> Anthony Stephen Szopa wrote:
> >
[snip]
> > I then read the latest BXA info restricting the export of such
> > encryption software.
>
> Have you even _read_ the current policy? It places practically no
> restrictions on crypto export to Austria, Australia, Belgium, Canada,
> Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary,
> Ireland, Italy, Japan, Luxembor, Netherlands, New Zealand, Norway,
> Poland, Portugal, Spain, Sweden, Switzerland, or the United Kingdom. In
> anby event, your algorithms look suspect, so it's just as well that
> you're not peddling them as suitable for encryption.
Is the US Government aware that its crypto export policy is a
laughing-stock across the world?
a) Some non-US people are capable of inventing cryptographic techniques
***outside*** the USA (gasp!) - I think I'm right in saying RSA falls
into this category (although my being mistaken on this specific example
would not disprove the general point). But even if this were false:
b) The beans spilled out of the can some years ago. Source code in
electronic form is widely accessible all over the world, for most USA
cryptographic techniques. But even if this were false:
c) Source code in /printed/ form is also widely available, and my
understanding is that the USA's First Amendment was (rightly)
instrumental in allowing American cryptographic techniques to be
disseminated in this way. Does the US Government think that terrorists
are incapable of typing, or of hiring (or coercing) a programmer to type
for them? The books are on the shelves, all over the world. But even if
this were false:
d) What makes them think we want their crypto anyway? If they won't let
us use theirs, we (and I use this word in the general sense - I myself
am no cryptographer!) are perfectly capable of developing our own, thank
you. (It has just occurred to me that this is the same point I was
making in (a) above. Oh well, that's life...)
Just my eight farthings.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 2 Nov 2000 09:57:57 GMT
[EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] wrote:
:> Your conclusion appears to be false and - AFAICS - your supporting
:> argument was not coherent ;-/
: The argument is fairly simple. If you chop all but 8-bits of a Rijndael
: block, the decryption is one of 2^120 possibilities. Therefore is
: Matt's version of "Rijndael" can in fact encrypt to a block of 8 bits
: (more importantly decrypt that block) there is no possible way for it
: to be the Rijndael that was reviewed as a part of the AES process,
: unless he has found a major flaw in Rijndael.
Well, putting it like that the argument is indeed fairly simple.
As is it's refutation: your premise is wrong - Matt does *not* "chop all
but 8 bits" from a Rijndael block.
If you want a description of what he /does/ do, it's probably more like
"postprocess the Rijndael output, using a bijective map from the set of
128-bit granular files (possible outputs from Rijndael) and the set of all
8-bit granular files."
I really think you ought to look at the program some more before
commenting further.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
** 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
******************************
