Cryptography-Digest Digest #17, Volume #13 Fri, 27 Oct 00 15:13:01 EDT
Contents:
Re: Is OPT the only encryption system that can be proved secure?
([EMAIL PROTECTED])
Re: How do I detect invalid passwords? ([EMAIL PROTECTED])
Re: Perfect Compression Possible? (Tim Tyler)
Re: Is OPT the only encryption system that can be proved secure? (Tim Tyler)
Re: ciphertext smaller than blocksize ([EMAIL PROTECTED])
Re: MD5 / SHA1 on SQL Server 7.0 ("Arnold Shore")
Re: CHAP security hole question (David P Jablon)
Re: Software with embedded keys (Eric Murray)
Re: Symmetric cipher ([EMAIL PROTECTED])
Re: Is OPT the only encryption system that can be proved secure? (Bryan Olson)
On introducing non-interoperability (Mok-Kong Shen)
Re: Rijndael and PGP ([EMAIL PROTECTED])
Re: End to end encryption in GSM (Steve Cerruti)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Fri, 27 Oct 2000 16:55:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] wrote in <8tc2bi$k4e$[EMAIL PROTECTED]>:
>
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >> [EMAIL PROTECTED] wrote in <8tbhk0$7b8$[EMAIL PROTECTED]>:
> >>
> >> >Tim
> >> >Thanks for your esoteric reply, but I dont think that Scott had
this
> >in
> >> >mind when he referd to PK and PGP.
> >> >
> >>
> >
> >Please read your last message.
>
> No quote what you want
> >
> >You claim that there is some inherent weakness in Public Key crypto
in
> >reference to PGP
>
> Many of the weakness are well known and I have commented many
> times on them,
What are you talking about?. Weaknesses of what?. If you talking about
Public key crypto systems, then please give us your wisdom oh wise
one...
Look them up as you want be to do with the Hasy
> Pudding cipher.
>
> >
> >
> >> Not sure what you are talking about. But Tim writes my
> >> on thoughts as what gets communicated far than what I usually
> >> write as they get mangled in others peoples minds. So assume
> >> he was better at explain what he thought I meant than what you
> >> thought I meant.
> >>
> >> >Perhaps he will answer directly...I also have been meaning to ask
him
> >> >about his cipher, whether its a conventional product/feistel
network
> >> >cipher .....
> >>
> >> It is my own design I prefer to call it a cipher that is
> >> based on a single cycle look up table 19 by 19. The key is
> >> such that any single cycle table is possible. The users password
> >> can be any size for any key. Since the key used for message is
> >> actully encrypted by the password and stored in a encrypted key
> >> file. THe sturcture is like comparing IDEA to a BLock except the
> >> WHOLE file is treated as a single block. What words you wish to
> >> call it is up to you. However if you go to Horsts description of
> >> it at me webpage you can see it explained or look at the source
> >> code.
> >
> >Sounds the same as the AES hasty pudding cipher....have you checked
that
> >one out?
>
> Obviously you haven't looked at both. They are not the same.
>
> >>
> >> Aparrently its not conventional our maybe Mr wagner would not have
> >> shot his mouth off is quickly to say the slide attack would destroy
> >> it. He was proved wrong and one time admitted he could not follow
> >> the code even though it was source code.
> >>
> >> David A. Scott
> >> --
> >> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> >> http://www.jim.com/jamesd/Kong/scott19u.zip
> >> Scott famous encryption website **now all allowed**
> >> http://members.xoom.com/ecil/index.htm
> >> Scott LATEST UPDATED source for scott*u.zip
> >> http://radiusnet.net/crypto/ then look for
> >> sub directory scott after pressing CRYPTO
> >> Scott famous Compression Page
> >> http://members.xoom.com/ecil/compress.htm
> >> **NOTE EMAIL address is for SPAMERS***
> >> I leave you with this final thought from President Bill Clinton:
> >>
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
> >
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
> http://radiusnet.net/crypto/ then look for
> sub directory scott after pressing CRYPTO
> Scott famous Compression Page
> http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do I detect invalid passwords?
Date: Fri, 27 Oct 2000 17:07:21 GMT
Everyone who replied: thank you!
-Abu Wawda
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > >A. Is there a better (i.e. safer) way to do this?
> > >
> > > Yes if password is shorter than the key
> > > why bother to hash it at all. I assume you
> > > are saving neither the hash or the password.
> > > Also why use something fishy like blowfish
> > > use the approved AES cipher would impress
> > > your boss and customers more.
> >
> > You are right, I am saving neither the hash or the password. The
> > reason I am planning on hashing the password is because most users
> > will NOT enter a 16 byte password (i.e. 128-bit). Let say that the
> > average person uses an 8-byte password. I don't want to pad the
other
> > 8-bytes with 0s or something else that is fixed. This would reduce
the
> > number of possible password combinations to 64-bits. I assume the
> > hashing will help fix this. Is this right?
>
> Although hashing the password is a good idea, your reasons are
wrong.
> If the password can only be 8 bytes, then no matter how good the hash
> is, there's only 8 bytes of entropy in your key. That is, hashing
> doesn't prevent brute-forcing of the password/key. An attacker using
> brute force (or more likely, a dictionary search) will go through the
> 2**64 possible passwords, hash each, and try it as the encryption key.
>
> The reason that hashing the password is a good idea, is that if the
> encryption key is gotten by some other method than brute force (eg,
> known/probable plaintext in the encrypted file), you don't want him to
> be able to go from the encryption key back to the original password.
> The reason you don't want that, is because people tend to re-use
> passwords.
>
> The best way to foil dictionary attacks on passwords is to require
> instead a passphrase, with some minimum length. A simple way of
picking
> a passphrase it to make up a pangram, or a poem, or whatever. I
> wouldn't suggest having the system any particular requirements on the
> passphrase, other than it be over a particular length. *This* is
where
> hashing is especially important... My made up passphrase might be
> (should be) longer than the cipher key size, so hashing securely
shrinks
> it. Since users will, if possible, pick bad passwords, (like having
> "aaaabbbbccccdddd" to get 128 bits), I would advise measureing the
> order-0 entropy (H value) per byte of the string, and require
> (H*numbytes >= 128) rather than (8*numbytes >= 128). Using this
> measurement, "aaaabbbbccccdddd" will have 2 bits per byte, and will be
> considered to contain 2*16=32 bits of entropy, and be considered too
> short, whereas assuming 8bits/byte would make it seem as if it had
> 8*16=128 bits of entropy, which would be sufficiently long.
>
> > > >B. How do I detect an incorrect password? I don't want to decrypt
> > > >the
> > >
> > > If you really want to do this I would encrypt the password
> > > the user entered the first time. When the user enters a
password
> > > to get his data decypt the file that has his encrypted password
> > > if they match then his in. But I would make this a very slow
> > > operation if he guesses wrong so that he can't sit there and
> > > guess quickly. That is if you do it at all I think not doing
> > > anything and giving him garbage may be best.
> >
> > Let's say I still use the hash, then should I:
> > 1. Get the password from the user.
> > 2. Hash the password.
> > 3. Encrypt the password from step 1 (not the hash) along with the
data
> > using the hash from step 2 as the key for the symettric cipher.
> > 4. When the user wants to access the data, he/she will give me a
> > password.
> > 5. Take the password from step 4 and hash it.
> > 6. Use the hash to decrypt the password that I originally encrypted.
> > If it is the same as the password that I got from the user in step
4,
> > I will continue to encrypt the rest of the data. Otherwise, the
> > password is invalid and quit.
>
> This method seems unnecesarily complicated. I would suggest:
> 1. Get the password (call it P).
> 2. Hash the password (call it HP).
> 3. Hash HP (call this HHP).
> 3. Write HHP to the file.
> 4) Encrypt the data with HP, and write it to the file.
>
> --
> "Mulder, do you remember when I was missing -- that time that you
> *still* insist I was being held aboard a UFO?"
> "How could I forget?"
> "Well, I'm beginning to wonder if maybe I wouldn't have been
> better off staying abo-- I mean, wherever it was that I was
> being held." [from an untitled spamfic by [EMAIL PROTECTED]]
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Perfect Compression Possible?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 27 Oct 2000 17:10:11 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
: I was wondering if it was possible to generate a perfect compression
: algorithm using the Berlekamp-Massey algorithm. If you took an normal
: piece of plain-text, and let the algorithm chew away for a long while
: eventually it would produce an LFSR that would exactly reproduce the
: plain-text right?
This isn't a "perfect compression algorithm". This is an algorithm that
works well on linear sequences, and not very well on non-linear ones.
Linear shift registers can represent sequences that have linear
representations well - but can be hopeless on other types of
sequence.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ ILOVEYOU.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 27 Oct 2000 17:22:12 GMT
[EMAIL PROTECTED] wrote:
: Thanks for your esoteric reply, but I dont think that Scott had this in
: mind when he referd to PK and PGP.
I do. Perhaps I err, though.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Organic: Church music.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ciphertext smaller than blocksize
Date: Fri, 27 Oct 2000 17:42:47 GMT
[snip how to create smaller block ciphers from large block ciphers]
Outside of using the full block cipher to create a stream pad, I can
see no way. I can see no way because of the diffusion involved in the
cipher, so to reconstruct 1 bit you MUST know all the bits in the
ciphertext, this makes it fairly improbably that you could reconstruct
the plaintext from the ciphertext without possession of the full block.
If what you want to do is create a block aligned system, where the data
may or may not be aligned on the block boundary. That's actually fairly
simple. There're many ways to do it, from padding out the block with
randomness, and adding a second block where the only bits that aren't
random designate how much of the previous block weren't random, to
padding with a 1 followed by 0s to fill the block, to padding the block
with the number of bytes in the block that weren't used (adding a full
block if necessary), to simply putting the length at the head of the
stream.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Re: MD5 / SHA1 on SQL Server 7.0
Date: Fri, 27 Oct 2000 14:05:57 -0400
Could the original poster re-post? I'm interested, and it somehow never
made it to my news server. Thanks.
Arnold Shore
Annapolis, MD USA
"Albert Yang" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You have ASP call a program that computes SHA1 or MD5, and then pass it
> to the database, or avoid SQL Server like the plague it is altogether!!
>
> Is there not an innate hash function?
>
> Albert
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: CHAP security hole question
Date: Fri, 27 Oct 2000 18:09:08 GMT
In article <8tb3q7$nsd$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, David P. Jablon wrote:
>> To resist offline brute-force attacks on network messages,
>> regardless of the size of the password, look at the protocols in
>> the class of EKE, SPEKE, SRP, SNAPI and AMP. These are documented
>> in a number of papers linked at <www.IntegritySciences.com/links.html>.
Vernon Schryver wrote:
> As far as I can tell, the claims at http://www.IntegritySciences.com/ are
> over the top.
[ Please bring any specific examples to my attention. -- dpj]
> Maybe I'm wrong, but, for example, it strikes me as
> impossible make small secrets unguessable.
Yes, you are wrong.
A small secret is guessable only if one gets the opportunity
to verify the requisite number of guesses. All CHAP-style protocols
provide this opportunity to any eavesdropper. EKE-style methods do not.
My posted statement about "offline brute-force attacks on network
messages" is, as far as I know, accurate.
> Small secrets by definition
> need a small number of guesses to discover.
Absolutely. But the big questions are "how small is small", and what kinds
of attackers get the opportunity to perform that number of guesses.
Prior to EKE, noone knew how to build a password-only network protocol
that proved knowledge of a password, but prevented a network attacker
from using the network messages to validate an unlimited number of
guesses.
The big difference with EKE, SPEKE, and SRP is that the enemy
must resort to either stealing the password data from one of the
participants, or making on-line guesses. On-line guessing is detectable
by both parties, and thus in a well-designed system, can be limited before
the guessing goes "too far".
> It also seems to me that
> http://www.IntegritySciences.com/password.html gets the notion of
> challenge/response protocols such as CHAP wrong; the authenticatee in a
> CHAP exchange does not learn the secret if it was not already known.
No. You've misunderstood. That page starts out with a breezy discussion
that does indeed gloss over the difference between a hashed password and
a clear-text password. However, if you look at the middle of the page
you'll find a crucial conservative assumption -- that the password is small.
Under this assumption, a hashed password is essentially equivalent to
the password. And therefore, so the argument goes, CHAP is crap.
Here's how a malicious authenticatee learns the password in CHAP:
He sends a random value R, and receives Hash(password, R).
In one failed run of the protocol he can verify an unlimited number
of guesses for the password off-line, by comparing the response to
Hash(guess_1, R), Hash(guess_2, R), etc., until guess_i == password.
> It's not that there are no problems with CHAP, what with the need for both
> parties (instead of only one as in PAP) to keep a private cleartext copy
> of the secret. (For years Microsoft falsely claimed that MS-CHAP does
> not involve cleartext copies of a password.) There are also some
> man-in-the-middle attacks, and other serious attacks involving the
> common practice of using the same secret for both peers.
>
> In other words, beware of technical information from sales people.
Hey, I too strongly recommend being wary of "sales people". But if you or
anyone has a specific problem with the information at
www.IntegritySciences.com, please let me know.
Also, out of courtesy, please "Cc" me directly too, when you choose
to post your comments to the world at large.
======================================
David Jablon
Sales Person & occasional cryptographer
www.IntegritySciences.com
------------------------------
From: [EMAIL PROTECTED] (Eric Murray)
Subject: Re: Software with embedded keys
Date: 27 Oct 2000 11:11:27 -0700
In article <[EMAIL PROTECTED]>, BillW <[EMAIL PROTECTED]> wrote:
>This is something of a newbie question; in part, the problem is that I
>lack the correct terminology to even begin researching the question.
>Basically, there are cases where encryption is used to tie data to a
>licensed application (i.e., so that the data file cannot be exported to
>and used by another vendor's application, or otherwise operated on). An
>example of this would be the (failed) DVD CSS. The point here is that
>encrypted data is being made available to a user through an intermediary
>device (software or hardware) where the user isn't required to provide a
>key. I have looked through the FAQ and some of Bruce Shneier's works,
>but haven't found what I'm looking for.
>
>The question is, is there actually a way of doing this that is actually
>(reasonably) secure, especially for a software implementation? It seems
>to me that to accomplish this, keys have to be kept with the data and/or
>the decrypting software/hardware. The keys themselves may be encrypted,
>but then of course, one needs another key to decrypt those -- at some
>point, a key must be stored in plaintext form that makes the whole thing
>a house of cards (e.g., by looking at the program executable with a
>disassembler). To explain my purpose here, I'm trying to convince
>someone that this is a bad idea, but I need some facts.
>
>I hope my question makes sense; as I mentioned, even providing me with
>terminology (what is this type of crypto application called?) or
>references would be tremendously helpful.
What you're looking for is commonly called software tamper-resistance.
There's a number of companies that sell schemes that are supposedly
tamper-resistant. The less cautious among those claim that they're
tamper-proof. There's two basic methods, which are often combined--
1. hide the secret, and 2. keep the attacker from debugging or watching
the software that controls where the secret is and how it's hidden.
Even the best of these schemes are not very secure. When the attacker
controls there's only so much obfuscation that you can do to slow him
down. Sometimes that's enough if the fruits of the attack are minimal
(i.e. the attacker takes a day to break the tamper-resistance and by
doing so gets one key to one copy of a $.50 song). But making sure
that's really all that happens takes quite a bit of thought.
Generally, the answer to "is there actually a way of doing this that is
actually (reasonably) secure" is No.
--
Eric Murray Consulting Security Architect SecureDesign LLC
http://www.securedesignllc.com PGP keyid:E03F65E5
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Symmetric cipher
Date: Fri, 27 Oct 2000 18:05:48 GMT
I guess it's my turn to give it a go.
I assume you have a basic understanding of Algebraic notation (i.e. you
know what f(x,y) and f'(x,y) mean)
A symmetric cipher is a function z=f(x,y), where an inverse y=f'(x,z)
in known, and generally easy to compute. One of the simplest to
comprehend is the One-Time-Pad, which is very simply, take a random
string the size of your plaintext and XOR it with the plaintext.
Decryption is very much the same, take the same random string the size
of the ciphertext, XOR it with the ciphertext, and the plaintext is
revealed.
I'll also go along with the others and tell you what assymetric ciphers
(also called Public Key Ciphers) are. Assymetric ciphers are a set of 3
functions x=g(a), z=f(x,y) and y=f'(a,z) . The best known example of
this is the RSA algorithm. It is also very simple:
p is a prime
q is a prime (different from p)
n = p*q
e is a random number
d is from solving the equation de = 1 mod (p-1)(q-1)
the public key (x above) is the pair (e,n)
the private key (a above) is the pair (d,n)
Encryption is
X = M**e mod n
Decryption is
M = X**d mod n
There are various speed improvements, and various requirements that I
have ignored (like n has to be sufficiently large to avoid factoring,
and strong primes are generally preferable for p and q, don't choose
e=3, etc)
I hope this helped.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Fri, 27 Oct 2000 18:11:29 GMT
Terry Ritter wrote:
> Bryan Olson wrote:
>
> >Terry Ritter wrote:
> >
> >> The mathematically-proven OTP depends upon various
> >> assumptions which cannot be provably achieved in practice.
> >
> > True.
> >
> >> And proof based on
> >> unprovable assumptions is ultimately no proof at all.
> >
> >Nonsense. Of course it's a proof. A huge mass of concerns
> >vanishes, and one only has to look at how well his system
> >fulfills the assumptions.
> >
> >Do right triangles exist in practice? Is the Pythagorean
> >theorem "no theorem at all"? Is it useless to engineers?
>
> Actually, I think that makes my point for me. An inability to
> distinguish between theory and reality seems quite common in
> mathematical cryptography.
Absolutely. The inability to figure out the practical
benefits from the OTP theorems is just as clueless as
believing it solves all a systems security problems.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On introducing non-interoperability
Date: Fri, 27 Oct 2000 20:54:52 +0200
Interoperability is the generally acknowledged benefit of
standardization and is commonly to be strived at as best
as possible. However, for a non-trivial amount of crypto
applications, where there is a fixed communication path
between two given partners, the interoperability needs
only to exist between these alone, without requiring the
same desirable property being extended to any third party.
In fact, to the contrary, it is evidently very much to
their benefit, if the opponent's system turns out to be
not interoperable with theirs.
I like therefore to describe a simple scheme to introduce
non-interoperability for third parties that, as may be
expected, is trivial to implement, at least in software.
Let the given (standard) block cipher have n rounds with
size of round key of m bits. Let n secret m-bit sequences
Gi (1<=i<=n) be shared by the communication partners. In
the encryption algorithm we xor the Gi with the round keys
computed from the key scheduling of the algorithm. All the
other processing steps of the cipher remain unchanged. The
Gi may be left constant or be updated with time as desired.
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Rijndael and PGP
Date: Fri, 27 Oct 2000 18:46:46 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I disagree strongly.
Right there you've given enough information for a reasonable person to
strongly agree. Of course it doesn't hurt that you have contradicted
the statements of every major cryptanalyst, made a mockery of yourself,
and been a pretender to the thrown for as long as I've been around.
In this case I would say that we will see RC6, MARS, Twofish, Serpent
and Rijndael/AES all around for a long time, simply because more people
are becoming aware that having multiple strong ciphers makes it more
difficult to attack a system. And more importantly the people who
actually do proper reviews of ciphers for products (last time I checked
you weren't one of them), realize that there are occassions where
Twofish will be better than Rijndael (alternately insert you favorite
and not so favorite algorithm). As the awareness rises there will be
demand for products supporting multiple strong ciphers, and for that I
would right now recommend Rijndael (because of the buzz mostly),
Twofish, Serpent, Triple-DES, Blowfish, and MARS. I see no reason to
limit ourselves from using the other strong ciphers that abound simply
because one has been given a blessed name.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Steve Cerruti <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Fri, 27 Oct 2000 18:46:23 GMT
In article <8tcboj$sq1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > It doesn't get around the basic problem that the requested
> functionality
> > would have to be installed between where the voice was digitally
> sampled
> > and where it was encoded without changing the basic characteristics
of
> > the human voice.
> >
> The Javasim toolkit is not low level enough to get at the sampled
voice?
I haven't read GSM 11.14 so I can't answer this. It really comes down to
if any existing phones support routing the sampled unencoded voice to
and from the SIM card. I haven't heard of any examples of this being
done. I would look for it in phones that support voice commands.
>
> > I also have some doubt that a JVM on a SIM card would have enough
> > throughput to process a real time audio stream. Have you got
> performance
> > metrics?
>
> 32 bit Java simcards are now available ....
Typical cards are run at 1 to 5 MHz as far as I could tell. I doubt that
they could simultaneously encrypt/unencrypt two voice streams in real
time. Has anyone done the math?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
