Cryptography-Digest Digest #756, Volume #9 Wed, 23 Jun 99 22:13:02 EDT
Contents:
Re: "Breaking" a cipher (William Tanksley)
Re: Encryptor that fits on a disk? (JPeschel)
Re: one time pad (Greg Ofiesh)
Re: one time pad (William Tanksley)
Re: Solitaire optimization ([EMAIL PROTECTED])
Re: Authentication Schemes ([EMAIL PROTECTED])
Re: one time pad (Patrick Juola)
xtea (Nikos Mavroyanopoulos)
Re: A different method of encryption (fungus)
Re: one time pad (Greg Ofiesh)
Re: helping a beginner (fungus)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: Arbitrary Huffman tree and weights distribution (was: huffman code length)
(Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: "Breaking" a cipher
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 Jun 1999 22:02:50 GMT
On Wed, 23 Jun 1999 20:57:59 GMT, Greg Ofiesh wrote:
>> Normally brute force is not considered a break as any cipher is
>> vulnerable to a brute force search.
>Do you believe that a one time pad cipher system is vulnerable to a
>brute attack?
Grin -- sure thing.
Let's see, was this the message he sent? Nope, how about this? Ooh,
maybe it was this...
It's wonderful -- the decryptor can choose any message with equal
justification, so long as it's the right length. So if you're the police,
just pick the one that's the most incriminating.
:-)
Or maybe you can redefine "brute force" by beating up the guy who's
transporting the key and stealing it.
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Encryptor that fits on a disk?
Date: 23 Jun 1999 22:08:30 GMT
>[EMAIL PROTECTED] writes:
>I am looking for an encryptor that could be used from a single floppy
>disk. I wish I could use PGP but unfortunatly its just to big.
You might want to try PGP 2.6x. Remove the documentation and
it will fit on a disk.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 23 Jun 1999 22:02:55 GMT
> For a truly random stream, the likelihood of a value appearing at
some
> point in the stream is _independent_ of its appearance at other
points
> in the stream.
> Randomness is qualitative, not quantitative. IOW, either your stream
> is random, or it's not. There's no "strength" or "percentage"
> involved. If there's any ability to find patterns or correlations in
> the stream, then the key is not random. It may model randomness in
> some fashion to some degree, but it's still not random. For most
> practical purposes, a well written LFSR (for one example) models
> randomness well enough that breaking such encryption is relatively
> rare, but it IS still (at least theoretically) possible. To truly
> guarantee against any possibility of the cipher being broken, the key
> stream must be really and truly random.
Let me begin by saying this is the first time here, and I am quite
surprised at how some people participate here. I wish my
correspondences to remain at the highest technical level possible.
First, in my first post, I used the term "statistical" randomness. It
is a term I received when reading about PI, which is supposively the
most statistically random sequence of digits known to man. By this, it
is ment that the digits are generally well distributed, and that they
occur approximately as often as each other- that 1' occur as
frequently, as 2's which occur as frequently as..., you get the idea.
When you say that randomness is a quality, I agree. Statistical
randomness is a measure of the quantities to yield a quality.
Also, a OTP's strength is entirely found in the fact that given a
cipher stream only, any plain text stream is an equal candidate to be
the true plain text.
Now to the point. If we say that a OTP has truly random values and
that the pad's contents are totally independent of each other, then
there is the extremely low possibility for a series of bits to display
a pattern, though the pattern may never occur again. For example,
there could occur a series of BYTE values 0xa7 (or any value) that
repeats, say, 100 times.
I proposed this ment nothing, until someone disagreed with me and
advocated I turn to this forum for advise and insight. So I ask you,
does it make sense that randomness is a requirement, that patterns must
be avoided, in building a one time pad?
It appeared to me that this individual is correct. For example, if you
take a long sentence of 100 characters and you apply the segment of the
pad to it and someone guesses that the segment is in fact all 0xa7,
then one would have to conclude that the proposed candidate is indeed
the plain text because the odds against it appear astronimcal.
so I wonder now just how much relationship must occur in build a pad.
It seems that weak statistical randomness must be employed if nothing
else but to prevent this scenario.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 Jun 1999 22:30:39 GMT
On Wed, 23 Jun 1999 22:02:55 GMT, Greg Ofiesh wrote:
>> Randomness is qualitative, not quantitative. IOW, either your stream
>> is random, or it's not. There's no "strength" or "percentage"
>> involved. If there's any ability to find patterns or correlations in
>> the stream, then the key is not random. It may model randomness in
>First, in my first post, I used the term "statistical" randomness. It
>is a term I received when reading about PI, which is supposively the
>most statistically random sequence of digits known to man. By this, it
Not true -- utter urban legend. PI has noticable statistical trends, and
it's very well approximated by very simple functions.
>is ment that the digits are generally well distributed, and that they
>occur approximately as often as each other- that 1' occur as
>frequently, as 2's which occur as frequently as..., you get the idea.
Yet if I were to use PI as an encryption method, all a person would need
to know to decrypt my message is that the number was PI and which decimal
place I started at.
>When you say that randomness is a quality, I agree. Statistical
>randomness is a measure of the quantities to yield a quality.
Statistics are a summary, not the reality.
>Also, a OTP's strength is entirely found in the fact that given a
>cipher stream only, any plain text stream is an equal candidate to be
>the true plain text.
Right.
>Now to the point. If we say that a OTP has truly random values and
>that the pad's contents are totally independent of each other, then
>there is the extremely low possibility for a series of bits to display
>a pattern, though the pattern may never occur again. For example,
>there could occur a series of BYTE values 0xa7 (or any value) that
>repeats, say, 100 times.
This is true.
>I proposed this ment nothing, until someone disagreed with me and
>advocated I turn to this forum for advise and insight. So I ask you,
>does it make sense that randomness is a requirement,
Yes.
>that patterns must be avoided,
No.
>in building a one time pad?
The two requirements contradict, as you noticed. Randomness is by
definition not constrained. If your attacker knows that you never used
any data with patterns in it, those are values of the key he doesn't have
to check by brute force. You've given him info for free.
>It appeared to me that this individual is correct. For example, if you
>take a long sentence of 100 characters and you apply the segment of the
>pad to it and someone guesses that the segment is in fact all 0xa7,
>then one would have to conclude that the proposed candidate is indeed
>the plain text because the odds against it appear astronimcal.
I have a very hard time figuring out what you last sentance means, but
here's an attempt at an answer. To be sure of what you're talking about,
I need to know what "the odds against it" means.
I'm going to assume that you mean that the odds against a sequence of all
0xA7s are astronomical. If so, you need to recognise that the odds
against _any_ single sequence are equally astronomical. Consider a single
byte -- "0x00" is just as likely of a byte as "0x4E", even though 0x0
looks much more noisy and orderly. Each byte has the same probability of
occuring, one in 256.
>so I wonder now just how much relationship must occur in build a pad.
>It seems that weak statistical randomness must be employed if nothing
>else but to prevent this scenario.
There's a problem, though -- everything in a finite length string is a
pattern if you merely search hard enough. Therefore, eliminate the likely
patterns and the opponent will just know to start guessing the unlikely
patterns sooner.
In reality, though, no decrypting engine would ever guess one of the
things which you refer to as a pattern first -- it would prefer to set up
a search through a representative amount of keyspace. Since one of those
patterns is VERY unlikely to show up as random data, the decryptor would
be very unlikely to want to test for it as a special case -- it would be
wasted effort.
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Solitaire optimization
Date: Wed, 23 Jun 1999 21:46:13 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Johnny Bravo) wrote:
> On Fri, 18 Jun 1999 16:40:51 GMT, [EMAIL PROTECTED] wrote:
>
> >When working by hand, you'd probably want to record the deck state
> >periodically to make error recovery easier. I think this is true even
if
> >we use a new key for each message, because redoing even most of one
> >message could be a pain.
>
> This wouldn't help, you could easily make a mistake that you didn't
> realize. Then you have no way of knowing if your deck is correct or
> not at any given time you record the state. There is no built in
> error recovery, if you make an encoding mistake your message becomes
> gibberish, and the only way to check this is to encode the message
> again and compare it to the first draft.
For encoding, this is certainly true. For decoding (the case I was
thinking about), some mistakes may be obvious, depending on the
plaintext.
> And one of the ideas behind Solitaire is that you don't keep a list
> of your deck state lying around. You can use a text phrase to encode
> a deck state, thus two people with access to a shared medium can get a
> deck state from it on a regular basis (newspaper, tv or radio
> broadcast ect.)
[...]
> Another of the ideas behind the pass phrases is that you don't carry
> around the deck in a ready to code state. This, and carrying around
> the state written down, would pretty much nullify any security you
> would hope to gain. It would be like keeping your PGP keys on a
> floppy right next to your computer with the pass phrase written on the
> disk.
> You need a new state for every message to be secure, and once you
> encode a message there is no easy way to memorize the current state.
> It would be best just to pick a new pass phrase for every message.
There are some interesting tradeoffs here. The inconvenience of
memorizing passphrases with 90+ bits of entropy, one for each message,
and spending a couple hours painstaking preparing a deck with them even
before encryption/decryption begins, might make it too inconvenient to
bother using encryption at all. If you write down the deck, you have to
keep the physical piece of paper secure, but encrypting and decrypting
becomes much more convenient. (* SPOILER FOLLOWS *) Note that in the
novel, characters died because it took too long to encrypt the message
which would have saved them.
It's clear that speed matters. Has anyone timed doing RC4 by hand? And
no one wants to comment on whether cutting the deck length or simplifing
the output step makes Solitaire less secure?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Authentication Schemes
Date: Wed, 23 Jun 1999 22:27:59 GMT
If you'd like a simple scheme for authentication, you can use SPEKE. It
authenticates both the host and the client. It was designed for systems
where you need a session key for encryption, but there is no reason you
can't use it for normal systems. One really nice aspect of this is that
you can perform the authentication in 3 transmissions. I forget what
the webpage for it is, but if you do a search on it, you should find it
easily. Just for reference, though, the company that developed it is
Integrity Services.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello Security experts,
>
> I am curious what different authentication schemes exist for
> proving who someone ( A machine ) is. I have used RSA auth
> in the past. What else can be used to prove that host A is
> really who he says he is?? I assume digital certificates
> can be used for this also, but looking for a Host authentication
> FAQ. If anyone has a list or any info they can send me back I
> would appreciate it greatly.
>
> Thanks a bundle,
>
> Ryan
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 23 Jun 1999 19:53:18 -0400
In article <7krli9$jqr$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>Now to the point. If we say that a OTP has truly random values and
>that the pad's contents are totally independent of each other, then
>there is the extremely low possibility for a series of bits to display
>a pattern, though the pattern may never occur again. For example,
>there could occur a series of BYTE values 0xa7 (or any value) that
>repeats, say, 100 times.
Yes. And the probability of this is exactly the same as the probability
of any other equally well-defined sequence occuring; and hence any
inference about ``*if* this event occurs, then the cyphertext will
[will not] have this property'' will be entirely uninformative.
>I proposed this ment nothing, until someone disagreed with me and
>advocated I turn to this forum for advise and insight. So I ask you,
>does it make sense that randomness is a requirement, that patterns must
>be avoided, in building a one time pad?
Not in a formal sense.
>It appeared to me that this individual is correct. For example, if you
>take a long sentence of 100 characters and you apply the segment of the
>pad to it and someone guesses that the segment is in fact all 0xa7,
>then one would have to conclude that the proposed candidate is indeed
>the plain text because the odds against it appear astronimcal.
Except that I could make just as wild a guess with amy other
sequences and produce an entirely different ``plaintext'' that
you would also have to conclude is correct.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Nikos Mavroyanopoulos)
Subject: xtea
Date: 23 Jun 1999 23:59:00 GMT
Hello,
In ftp.funet.fi/pub/crypt/cryptography/symmetric/tea/tean.c
file the xtea algorithm has the following line in the source:
y += ((z << 4) ^ (z >> 5)) + (z ^ sum) + k[sum & 3];
whereas Needham and Wheeler in their "Tea extensions", djw-rmn-xtea.ps , use:
y += (z << 4 ^ z >> 5) + z ^ sum + k[sum & 3];
In djw-rmn-xtea there no parenthesis, and it is not clear (to me) what
they mean. Which one is the right one? (they produce diffent outputs).
(the problem is in z^sum)
Thank you.
--
Nikos Mavroyanopoulos
mailto:[EMAIL PROTECTED]
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: A different method of encryption
Date: Thu, 24 Jun 1999 02:59:19 +0200
Greg Ofiesh wrote:
>
> > I think you should read the faq before going on. I did a while ago
> and
> > it cleared up many issues.
>
> What FAQs? Where is it?
>
Try a web search for "cryptography faq".
ftp://rtfm.mit.edu/pub/faqs/cryptography-faq/
http://www.rsa.com/rsalabs/faq/
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 00:23:06 GMT
you said:
> False. The key word here is "guarantees." Unless we have a proof
> which applies in practice, there can be no such "guarantee" in a
> realized cipher.
>
> The difference is that we have no absolute *proof*.
> And that places the OTP firmly into the body of ciphers we know.
You can say that EC or IFP encryption cannot guarantee encryption
because it is possible to attack it using various methods. In any of
these methods, if successful, the result is certain to be correct
because there can only be one solution that fits the puzzle with only
the cipher stream in hand.
You cannot say this with OTP. OTP, even if rough, as long as it lacks
any obvious conclusions, does not let an attacker have a clue as to
which candidate is correct. In this lies the guarantee (it would seem
to me) that OTP cannot be broken, even in rough implementation.
Now, let me clarify what I mean by rough implementation. I mean that
the random numbers adhere to some rules such as a minimal number of bit
fluctuations in the stream to prevent obvious patterns to the naked
eye. Not much more than that.
In an earlier e-mail, there seems to be a contradiction in your
position. Tell me what you think. If a pure and perfect (okay,
theoretical) random generator can produce any sequence of bits, and no
bit is dependent on any other, then you could theoretically produce
streams of obvious patterns. And this should produce weaknesses in the
pad. Therefore, I put forth that some control must be maintained and
that the random bits cannot be whole random. Furthermore, the controls
must have wide margins to avoid weaknesses within itself.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: helping a beginner
Date: Thu, 24 Jun 1999 02:57:27 +0200
Fwumph wrote:
>
> Crypto, codes, and various methods of encryption have always been a hobby
> for me, Im looking to learn more about Encryption types and general
> information. Can anyone suggest for me a decent FAQ?
> please email me at [EMAIL PROTECTED]
ftp://rtfm.mit.edu/pub/faqs/cryptography-faq/
http://www.rsa.com/rsalabs/faq/
ftp://ftp.uni-paderborn.de/pub/doc/faq/news/answers/cryptography-faq/snake-oil
http://ciphersaber.gurus.com/
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Thu, 24 Jun 1999 01:41:38 GMT
[EMAIL PROTECTED] wrote:
> fungus <[EMAIL PROTECTED]> wrote:
> > Did I say "guess the state"? I could have sworn I said "guess part
> > of the key"...
>
> Same thing.
>
> > With a random key[*], the chances of the first byte output being
> > the same as the first part of the key are 36%. Having a 36%
> > chance of knowing one byte of the key is a fairly big weakness.
> > Throwing away the start of the output should be seen as essential
> > for a good RC4 implementation.
>
> No you are wrong. If the first output is State[0] with a prob of 36%
> or 92.16/256 then that's a serious weakness.
Yes. About the only one known for RC4.
> You seem to forget that the key is the state.
It isn't. Check the algorithm.
Tom, your energy and enthusiasm are impressive. Why
not direct them toward making a modest but positive
contribution, rather than this tremendous volume of
misinformation?
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: Arbitrary Huffman tree and weights distribution (was: huffman code length)
Date: Wed, 23 Jun 1999 15:11:37 +0200
Alex Vinokur wrote:
>
> ----------------------------
>
> Stage#2 : 49 (51)
> L R
>
> 100
> /\
> / \
> 49 51
> /\
> / \
> 3 48
> /\
> / \
> 1 2
>
At each level the nodes are sorted. But the terminal nodes are
not sorted. Would this matter for you in proceeding further to obtain
the range of variation of the frequency distributions of (terminal)
nodes where the frequncies are sorted (the problem I originally
asked)?
M. K. Shen
------------------------------
** 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
******************************
