Cryptography-Digest Digest #66, Volume #13 Wed, 1 Nov 00 08:13:01 EST
Contents:
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: how i decode this? (Andre van Straaten)
Re: Really Strong Cipher Idea? (John Savard)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: Really Strong Cipher Idea? (John Savard)
Re: BENNY AND THE MTB? (Richard Heathfield)
Re: frequency analysis (Richard Heathfield)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: Give it up? (Tom St Denis)
Re: DATA PADDING FOR ENCRYPTION (Tim Tyler)
Somebody help me out of using openssl~ ("Verd")
Re: Is RSA provably secure under some conditions? (D. J. Bernstein)
Re: Give it up? (Tim Tyler)
Re: BENNY AND THE MTB? (Tim Tyler)
Re: Arbitrated signature scheme (conventional cryptosystem) (Jan Fedak)
----------------------------------------------------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 11:14:34 +0100
Dan Oetting <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> wrote:
>
> >
> > Mike Connell wrote:
> > > Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> > > Xa, Xb are random blocks of data of the same size as the public keys.
> > >
> > > 1. a -> b : Pa
> > > 2. a <- a : Pb
> > ^ I assume this should be b
> >
> > > 3. a -> b : (Xa)Pb
> >
> > The number of passes could be reduced to 3 by eliminating message 1
> > and making this "Pa, {Xa}Pb". (A can still go first by swapping A and B.)
> >
> > > 4. a <- b : (Xb)Pa
> >
> > In the other responses to this thread, there seems to be some confusion
> > because the original description did not say whether public keys were
> > certified or known before the protocol starts. There are three cases:
> >
> > 1. If the public keys are certified, then messages 1 and 2 should be
> > explicitly sending certificates, not unsigned public keys.
> >
> > 2. If the public keys are not certified, but they are known to be correct
> > for some other reason (for example because key fingerprints, i.e.
> > hashes, have been exchanged over an authentic channel), then it is
> > redundant to send them in the protocol. It would be more efficient
> > and clearer to send the fingerprints instead in messages 1 and 2
> > (since a mapping from a fingerprint to a public key is assumed to be
> > known).
> >
> > 3. If the public keys are not certified or otherwise known to be correct,
> > then there is obviously a MITM attack.
> >
> > Also note that the protocol does not provide forward secrecy, or explicit
> > key confirmation. IMHO this makes it a bad choice for new applications
> > even in cases 1 and 2.
> >
>
> You also leave open the ability of B to control the outcome of the
> shared secret. This can be easily fixed and reducing the protocol to a 2
> step process with bidirectional communication: [Assuming the public keys
> are certified or already known and trusted]
>
> 1. a -> b : Pa,(Xa)Pa
> a <- b : Pb,(Xb)Pb
>
> 2. a -> b : (Xa)Pb
> a <- b : (Xb)Pa
>
> In the first step A and B exchange which keys to use and proof of the
> seeds to be exchanged. In the second step the seeds are exchanged. This
> two step protocol seems so basic it probably already has a name. The
> protocol also expands easily to handle more than 2 parties.
>
This seems like a nice touch. I'm not exactly sure when it helps -
afterall, B is the person you want to talk to, but it still seems
right that no one party controls the key (which is partly the intent
of the two X blocks in the first place).
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: how i decode this?
Date: Wed, 01 Nov 2000 09:44:30 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>>
>> In article <8teiah$ifv$[EMAIL PROTECTED]>,
>> Simon Johnson <[EMAIL PROTECTED]> wrote:
>>
>> > We can't be expected to even attempt to solve the encrypted cipher text
>> > without knowledge of the algorithm.
>>
>> So you mean it's a good idea to use secret enryption algorithms?
> I think there's a difference between using a secret algorithm and using
> an algorithm secretly.
The practical effort for most attacks is greater.
Finally, you will like to run a ciphertext attack with a program which is
algorithm specific.
The more difficult it is to guess which algorithm has encrypted the
message, the more trials you have to run with different programs (for
different algorithms).
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
> If your algorithm relies on its secrecy for its security, that's a Bad
> Thing, because someone's bound to find out sooner or later if it's
> important enough. But consider this:
> Alice has a choice of 50 known, published, well-analysed, robust
> algorithms. She chooses one at random and uses it to encrypt a message.
> She sends the message to Bob.
> Bob uses their shared secret key on each of the 50 algorithms until he
> hits the right one.
> Now, Bob's work (with the key) is O(N) where N is the number of
> algorithms - not an onerous task, whereas Eve's work is incomparably
> vaster than if she knew which algorithm Alice had chosen for this
> particular message.
> Now, from sci.crypt's point of view, this means that it's correct to say
> "publish your algorithm because unpublished algorithms are snake oil (or
> GCHQ/NSA secrets!)", and it's also correct to say "we can't decipher
> this unless you tell us your algorithm", and that there is no
> contradiction or hypocrisy in these two apparently conflicting
> statements.
> --
> 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, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Really Strong Cipher Idea?
Date: Wed, 01 Nov 2000 10:08:48 GMT
On Wed, 01 Nov 2000 09:20:15 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Is the 6000 byte secret used for one single message, or
>is it used again and again in combination with other
>informations that vary from message to message (or session)?
>I guess that it is the second case. Then your scheme
>certainly cannot provide perfect secure communication till
>eternity.
No, it is not claimed to do that. But a very large secret key does
make things harder, and this scheme is proposed as one way to make
effective use of such a key.
If only one message segment is intercepted, that one message segment
alone is secure in the information-theoretic sense. So the useful
property this has is that the cryptanalyst has to work with multiple
messages, (or at least multiple message segments) and somehow compare
them to each other. I've chosen a method of using the large secret key
that makes such comparison rather difficult: that's all I claim.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 11:25:28 +0100
Mike Connell <[EMAIL PROTECTED]> writes:
> David Hopwood <[EMAIL PROTECTED]> writes:
>
> > Mike Connell wrote:
> > > Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> > > Xa, Xb are random blocks of data of the same size as the public keys.
> > >
> > > 1. a -> b : Pa
> > > 2. a <- a : Pb
> > ^ I assume this should be b
> >
>
> Oops! Yes, it should be B. Apaprt from the case where A is telepathic ;-)
>
^^^^^^ Yes, it should be "Apart" ;)
Ah, the humiliation of making a mistake in my admission of mistake
making. I can tell it's going to be one of those days... 8-/
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Really Strong Cipher Idea?
Date: Wed, 01 Nov 2000 10:22:47 GMT
On Wed, 01 Nov 2000 01:21:54 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>One important step, though, can easily be added to significantly
>improve the already high security. In addition to using the encrypted
>large secret key to XOR with the message, also use part of it as the
>key to encrypt the parts of the session key used for the ECB and CFB
>stages before and after.
>This increases security if the public-key part is compromised.
Without this step, if a known-plaintext attack is possible, then the
cipher is only as secure as the public-key part, because it is quite
straightforwardly possible to work backwards to get a big chunk of the
6,000 byte shared secret in that case.
Even with this step, however, known-plaintext reduces the security to
the 'ordinary' dimensions of the public-key part and the conventional
cipher used. But at least one is forced to crack the conventional
cipher as well, so the scheme still has _some_ benefit.
Thus, the improvement my scheme requires is obvious. The large shared
secret must be handled a bit more securely.
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, and encrypt them, this time not with a key found in
the session key, but with another part of the encrypted secret. (Note
that the key used is no longer limited to 128 bits in size while
keeping the session key to a reasonable 512 bits.)
Then, while known-plaintext and a cracked session key allow reading
what is XORed to the message from the shared secret, that is now not
invertible.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Wed, 01 Nov 2000 09:58:41 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
"SCOTT19U.ZIP_GUY" wrote:
>
<snip>
>
> They are still laughing when they get the first message to
> decyrpt. Since it is only a byte long. Some of the boys don't
> even want to try to turn the quantum computer on. One byte they
> say. How many possible messages could that decrypt to.
2^CHAR_BIT
In other words, usually 256.
--
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
------------------------------
Date: Wed, 01 Nov 2000 10:55:43 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: frequency analysis
Richard Heathfield wrote:
>
> JPeschel wrote:
> >
> > [EMAIL PROTECTED] writes:
> >
> > >If the cypher is half decent [anything more than a monoalphabet] that
> > >approach will not work. I know of no such program, however one could write
> > >such program over lunch.
> >
> > The results of doing single-character
> > frequency analysis, in addition to
> > solving monoalphabetical ciphers, help
> > you eliminate other cipher types.
>
> Hurrah! I was planning to write one anyway, so it's good to know it will
> be useful.
Well, I did. It took me a little more than lunch - in fact, a couple of
evenings. But the question remains - is it useful?
<snip>
> I've decided my time would be better spent on this kind of program than
> on trying to make sense out of someone else's nonsense, so watch this
> space.
Yes, this space here.
I know the sci.crypt gurus will have this kind of stuff already, but I'd
appreciate a peer review nonetheless. I've not-quite-given-up on
cryptography for now; it seems more sensible to focus on cryptanalysis
for the time being. So, starting right in the basement, here we go - a
monoalphabetic substitution cipher decryption program.
The program is incredibly powerful (but quite slow) because it hooks
into a massively powerful pattern-evaluation parallel processor, known
by some as "the user" - the slow bits are the bits where it's waiting
for you. :-)
In other words, it relies to some extent on your knowledge of your
language. (It can handle any language that uses the Latin alphabet -
just give it a dictionary in the right language!)
http://users.powernet.co.uk/eton/crypto/mscd1.c has the source code. No
special headers. ISO C. So it should work fine on your compiler, on your
OS. If you get compilation diagnostics, please let me know. (gcc gives
half a dozen which I've checked through for seriousness - they're fine,
but I'll fix them anyway at the weekend).
No real docs yet, so I'd better say a brief word about how to use it:
mscd1 ciphertext dictionary
ciphertext is a file containing a monoalphabetic substitution
ciphertext, in which /only/ alphabetic characters have been enciphered,
without distinguishing case. Thus, the key is 26 letters long. If spaces
separate the words, it makes the task an awful lot easier.
dictionary is a file containing a list of words, one per line, in
alphabetical order. /usr/dict/words is perfect, if you happen to be
using Linux. For it to be useful, it should be a big ol' dictionary -
mine has around 45000 words in it.
German users will want to play with the MAX_LETTERS macro. :-)
Once it's up and running, type
> help
for a list of commands.
The most useful commands are:
exit :-)
freq (display frequency analysis chart for alphabetic characters)
cipher (display ciphertext)
plain (display plaintext)
both (display both!)
map c p (let p be the plaintext character for which the ciphertext
character is c)
guess cryptword plainword (perform all necessary mappings to make the
one word map to the other, if this can be done)
match wordpattern
Here's an example:
> match dyszzs
agreer apollo career deanna grotto indeed joanna pierre yvette
9 words matched.
lookup a???ally (with my dictionary, this gives "actually atonally
annually" - note that a????lly will match only "artfully", because it's
assumed that, since you know 'a', none of the ? can be 'a')
++++++++++++++
Okay, that's it. I'd appreciate the opinions of the clueful on whether
this is any use for elementary cryptanalysis, or whether it should be
relegated to rec.puzzles.
--
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: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 12:33:17 +0100
Mike Connell <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (David Wagner) writes:
> > If you use RSA encryption, so that (Xa)Pb = Xa^Eb mod Nb (Pb = (Nb,Eb)),
> > then an active attacker M can break the scheme by replacing the
> > transmitted values (Xa)Pb with 0:
> > a -> b : Pa
> > a <- b : Pb
> > a -> m : (Xa)Pb
> > m -> b : 0
> > m <- b : (Xb)Pa
> > a <- m : 0
> > Then M can predict the session key used, since 0^Db mod Nb = 0, etc.
> >
>
> Eek! Thanks for pointing that one out 8-|
>
> So the encrypted blocks shouldn't equal zero either...
>
On further thinking, I'm not sure that I see the problem. In this
case, after all the communication has taken place, the three entities
are in this following positions:
A has : Pa Pb Xa 0, computes Pa+Pb+Xa+0 = Pa+Pb+Xa
B has : Pa Pb Xb 0, computes Pa+Pb+Xb+0 = Pa+Pb+Xb
M has : Pa Pb (Xa)Pb (Xb)Pa, computes nothing?
A and B compute different XOR blocks, and so different session keys. M
still doesn't really get any information, and the session collapses.
What am I missing?
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Wed, 01 Nov 2000 11:57:28 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis schrieb:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > Tom St Denis wrote:
> > > >
> > > > Here is all you need to know about communication topology.
> > > >
> > > > Secrecy -> Cipher
> > > > Efficiency -> Codec
> > > >
> > > > Codec != Cipher.
> > >
> > > Questions: (1) 'Topology' has a time-honoured and well-
> > > established meaning. How does the above conform to that?
> > > (2) Are you saying that one can't extremely increase the
> > > strength of a cipher and yet remain very efficient like
> > > one can't have a racing car at very low price, or do you
> > > want to express some other novel idea? Thanks.
> >
> > Perhaps "topology" was the wrong word. But I just want to
> > stress "leave security to the components designed for security".
>
> In view of the text of your original post and the uncommon
> title I still have trouble of understanding. (1) What
> would you substitute for the wrong word? (2) The above
> phrase under double quotes seems to be ambiguious. What
> is your 'proper' point? Could you paraphrase that into two
> or three sentences? You mentioned security and efficiency.
> Now there is always a trade-off between these, no matter
> how capable the cipher designer is. So, if one needs
> extremely high security, one must accept some inferior
> processing speed. This is common sense. I don't yet see
> what new relationships between these two entities could be
> established. You mentioning of 'components' seems also
> a bit difficult for the reader. For the components need
> not only be good but also to be put together in a good way
> in order to have a strong cipher as a whole.
Um it's rather obvious what my point is. "Security != codec". i.e, get
your security from ciphers and cryptography and not from a huffman
codec.
If you can't comprehend this... well too bad.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Reply-To: [EMAIL PROTECTED]
Date: Wed, 1 Nov 2000 12:04:21 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Bryan Olson <[EMAIL PROTECTED]> wrote, in part:
:>More importantly, it applies to the message as people
:>actually send it. It makes no sense to say we must not
:>provide known plaintext and then use a public-key cipher.
: A very important point. Unless, of course, one is using a secure
: public-key cipher to transmit a key for a much less secure (for speed
: reasons) conventional cipher.
Exactly - I doubt I could have put this better.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Hat: Baldness cure.
------------------------------
From: "Verd" <[EMAIL PROTECTED]>
Subject: Somebody help me out of using openssl~
Date: Wed, 01 Nov 2000 06:50:55 GMT
Hi, I'm graduated student of Seoul, Korea.
I am now doing some term project in my lab to construct small system that
can be used in internet banking.
Using openssl-0.95a, I could construct most part of it.
Using openssl's crytpo as a library, and converting the test program to
interface...that's what I use the openssl.
But I now have difficulty in verifying the x.509 certificate.
To show users the content of certificate, extracting some contents(such as
subject name, Issurer name, etc...) should be needed.
I've studied x509.c in openssl-0.95 and SSLeay Documentation for
sometimes..but couldn't I catch the concept of how to use it.
Would I ask a favour of you to make some sample of extracting x509
contents?(By using openssl 0.95)
I made a applet of showing subject name and issurer name.
So, I should extract at least above two contents from the certificate.
It will be a great help to me to show some sample of using some x509
functions or where the sample codes are.
I hope you will make some favourable answer to this letter.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Is RSA provably secure under some conditions?
Date: 1 Nov 2000 11:56:23 GMT
> an actual example
Here's the obvious example: s is a signature of m if
* s is a Rabin signature of m or
* s is a program that produces the same result as the hash function,
at the same speed, for several random inputs.
If factoring is difficult then any attack on this system has low
probability of success for a uniform random hash function. But the
system is easily breakable as soon as you plug in a real hash function.
---Dan
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 1 Nov 2000 12:14:54 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: I just want to stress "leave security to the components designed for
: security".
Where security considerations are relevant, they can impact the design of
practically every component in a system.
I don't think you can usually isolate security considerations in
(say) a cipher system.
What is your idea of a component in a secure system whose design is
*not* impacted by security considerations?
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 1 Nov 2000 12:23:20 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" wrote:
:> They are still laughing when they get the first message to
:> decyrpt. Since it is only a byte long. Some of the boys don't
:> even want to try to turn the quantum computer on. One byte they
:> say. How many possible messages could that decrypt to.
: 2^CHAR_BIT
: In other words, usually 256.
A better upper bound would be 2^KEY_BIT - i.e. approx 2^128 in this
context.
This figure may contain a few duplicated messages under different keys.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Organic: Church music.
------------------------------
From: [EMAIL PROTECTED] (Jan Fedak)
Subject: Re: Arbitrated signature scheme (conventional cryptosystem)
Date: Tue, 31 Oct 2000 22:42:51 +0000 (UTC)
In article <8tmvrb$1rt$[EMAIL PROTECTED]>, David Wagner wrote:
>Jan Fedak wrote:
>>Here's what Selim G. Akl offers as an arbitrated signature scheme
>[...]
>>3. She computes $C = E_{k_{SA}}(m, h)$ and sends it along with
>> UNENCRYPTED $M$ to arbiter.
>[...]
>>The enemy then knows $C$, $m$ and $h$ and can easily obtain $k_{SA}$.
>
>How do you obtain $k_{SA}$? You know $(m,h)$ and $C$, so you
>have a known plaintext/ciphertext pair for the cipher $E_{k_{SA}}$,
>but how does this help? Ciphers are supposed to be secure against
>known-plaintext attacks.
>
>What am I missing?
Conventional ciphers needn't neccessarily be secure against known
plaintext attacks. Just consider one-time pad or other stream ciphers...
Jan
--
Jan Fedak talk:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Linux - the ultimate NT Service Pack.
------------------------------
** 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
******************************
