Cryptography-Digest Digest #890, Volume #9 Fri, 16 Jul 99 12:13:03 EDT
Contents:
Re: How to crack monoalphabetic ciphers ([EMAIL PROTECTED])
Re: randomness of powerball, was something about one time pads (Patrick Juola)
Re: Numerical Base Encryption (NBE) ([EMAIL PROTECTED])
Re: Numerical Base Encryption (NBE) ([EMAIL PROTECTED])
Re: Neato Talk (Keith A Monahan)
Re: zip or replacement ([EMAIL PROTECTED])
Re: How to crack monoalphabetic ciphers ([EMAIL PROTECTED])
Re: randomness of powerball, was something about one time pads ("Tony T. Warnock")
Re: Why this simmetric algorithm is not good? (Roger Fleming)
Re: Funny News ("Tony T. Warnock")
Implementing the CS-Cipher (Stelios Koroneos)
RC6a ("Nigel Porter")
Re: RC6a ("Richard Parker")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to crack monoalphabetic ciphers
Date: Fri, 16 Jul 1999 12:50:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:
> I'm not sure what "ultimal" means, but whatever it is, it apparently
> doesn't apply to any of the LZ-based compression schemes, as all of
> them have a set of codes that are invalid at any given time.
Well in LZSS (variant of LZ77) you encode things by
bit = 1 code = (12 bits distance)(4 bits length)
bit = 0 literal
(or whatever length/distance you choose).
I could not see where an invalid stream comes from? All the lookup
does is copies out of a local ring buffer. In a *complete* huffman
tree no binary sequence is invalid. You may for example run out of
bits before finding a data-leaf on the tree though...
> > The only way to really check for errors is to check the CRC (which
is
> > not absolute either).
>
> If you honestly believe this, you simply don't know much about LZ-
> based compression schemes.
But I do. If you think about it if a sequence or coding mechanism is
omited then you haven't done all you can to sqeeze the information.
You could do a lookup in the ring buffer where you haven't been yet
(i.e looking upto -1024 on the first byte) but that shouldn't really
effect the program running (other then to produce garbage out).
> > Check the DEFLATE specs there are no invalid decodings at any point.
>
> Here -- since you like on-line documents, take a look at:
> http://www.patents.ibm.com/details?pn=US04558302__
>
> That's the patent on LZW compression. The claims are far too dense
to
> try to understand, but the disclosure of the patent is really quite
> readable, though it'll probably take a couple of times through before
> you completely understand how LZW compression works.
I know how LZW works. I wouldn't use LZW if I was forced to. I like
LZSS since it's simple to code. I have a zero memory LZSS coder if you
would like to see it... LZSS+Huffman is a good combination as well.
> Of course, other LZ variants work differently in some respects, but
> they all have one basic concept in common: the compressor and
> decompressor build up string tables in parallel. At any given point
> in the stream, the compressor can only send codes the decompressor
> already knows about, or (at least in the case of LZW) a code that's
> exactly one greater than any the decompressor has seen yet.
>
> At any given point, however, there's an entire set of codes that
> absolutely, positively canNOT occur in the stream because the
contents
> of the strings to which they should be decoded has not been defined
> yet.
You are talking about codebook methods. In LZ77 you codes are not
indexes they are distance/length pairs. And they should always be
valid. (although like above a -1024 distance on the first byte would
make garbage out).
> Once you've read through the patent, I'll be happy to go over any
> points you may have trouble with -- I'm reasonably certain I
> understand it (both the patent, and LZW compression) quite well.
>
> I'd also note that if you look through the popular literature on the
> subject, you'll find LOTS of stories about LZ-based compression, and
> LZW in particular, that are completely wrong. Misconceptions abound
> about exactly how LZ-based compression works, and (in particular)
> about what Terry Welch invented that was new and original (I.e. about
> the exact differences between LZW and LZ77, LZ78, etc).
Well I know about the methods. I did a short paper in my grade 13
comp.sci class on the methods. I have printed material on
huffman/shannon-fano/arith lzw/lz78/lz77/lzss etc... I even have a
paper on lossy LZSS coding and vector quantization...
Only in LZ78 and LZW (of the LZ methods) can you truly have invalid
codes. This is a waste of space though. If for the first 100 bytes
only the lower 7 bits of the lookup are being used then there is wasted
space (if your index is 10 bits for example). In LZ77 and LZSS same
thing however the codes should still be accepted (producing garbage
out) since it's perfectly valid to read out of the ring buffer at any
point (it's easier to code for this assumption then check the CRC
afterwards).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: randomness of powerball, was something about one time pads
Date: 15 Jul 1999 09:03:15 -0400
In article <[EMAIL PROTECTED]>,
Alan Braggins <[EMAIL PROTECTED]> wrote:
>"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>> remaining doors? On the assumption that the host *knows* where
>> the good prize is and as a matter of policy *always* opens a
>> bad-prize door, the new odds are 1:2 in favor of the third door.
>> If he had just opened a door on whim, with the reported result,
>> then the new odds are 1:1. (If you don't know which of these is
>> the case, then switching can't hurt and might help.)
>
>On the other hand if he only ever opens a door if you have already
>chosen the prize door, switching will hurt. But viewers could be
>expected to notice, and once the pattern is noticed no-one will ever
>switch.
>I'm still not sure about the case where he doesn't always open a door,
>and sometimes opens a door when it will help you, but is more likely
>to open a door if you have already chosen the prize.
Surely that's a mixed case and depends on the exact percentages.
Where *did* I put my game theory text? 8-)
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Numerical Base Encryption (NBE)
Date: Fri, 16 Jul 1999 13:00:47 GMT
In article <ODBj3.168$[EMAIL PROTECTED]>,
"User" <[EMAIL PROTECTED]> wrote:
> oops... after you enter 1/MESSAGE, press calculate button.
> then press BASE button, select 36, press Ok button.
> THEN you will see the plaintext. :)
Division or multiplication without a prime modulus is a bad idea. You
could have truncated parts of the fraction and lost the message! Check
out IDEA for methods on using multiplication and division (well
multiplicative inverse) in a cipher.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Numerical Base Encryption (NBE)
Date: Fri, 16 Jul 1999 12:58:55 GMT
<snip>
Well actually you don't. You are not changing the bit representation
and most people will not want to have to convert their message from
ASCII or binary to base 50 or whatever...
You are not removing BITS!!!! Get that thru your head!!! You are just
changing the representation. And remember that it's not only text that
is encrypted (esepecially in CBC mode). So converting 8 bytes to base
64 you made the plaintext *4 times* larger!!!!
If I used base 256 what would I have? A byte.. wow! All ciphers work
like that. They take input and voila a byte. Whether there is truly
one byte worth of entropy (normal ASCII says no) is not up to the
cipher but the protocal.
If you truly want to compress the message use huffman coding or DEFLATE
or something. Also note that in even base 64 or whatever you still
have biases. Like the higher ASCII set will not be used (that's 127-
255) and the lower (0-31). So really how is your method any better
then huffman coding the message (espeically with binary plaintext or in
CBC mode)
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Neato Talk
Date: 16 Jul 1999 13:59:42 GMT
Tom,
Thanks for posting that link... I actually attended that conference, and
I can't believe I missed his talk... Then again I wasn't into crypto back
then.
Keith
[EMAIL PROTECTED] wrote:
: I know this is not new but if you have real audio you can hear Bruce S.
: talk at the HOPE conference. I think it would be good for anyone
: interested in finding out what cryptography is really about. It's a
: really nice straightforward presentation.
: For me it's just something todo. At 16kbs he has a really nice
: voice :) (most things I get are hard to understand). He sounds like a
: very competent person (I only heard part of the talk) and I hope to
: actually see him in person sometime (maybe when I go pro...).
: The file is at
: http://www.2600.com/offthehook/rafiles/crypto.ram
: Tom
: --
: PGP key is at:
: 'http://mypage.goplay.com/tomstdenis/key.pgp'.
: Free PRNG C++ lib:
: 'http://mypage.goplay.com/tomstdenis/prng.html'.
: Sent via Deja.com http://www.deja.com/
: Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zip or replacement
Date: Fri, 16 Jul 1999 13:06:15 GMT
In article <7mmng7$8v5$[EMAIL PROTECTED]>,
Paul Edwards <[EMAIL PROTECTED]> wrote:
> Looks good! I'd rather have a longer password
> than use other than lowercase letters. That way
> I can easily make up a sentence that no-one can
> guess, not even in English (or any language!).
> You cited 20 characters for uncrackable forever.
> Does this still apply for my sentence, or do I
> need more (assuming someone knows that its
> lowercase alphas)?
Well 20 lower case only gives you 26^20 or 94 bit keys. Not bad but
as long as your password is 20 chars and unpredicable to guess.
> Also, I was a bit confused, can I use the same
> password for all my files? It sounded like I could,
> because although the algorithm didn't allow it, you
> used random numbers to overcome the problem.
Well the problem is he is using RC4 which is a stream cipher.
Obviously if you use the same part of the stream twice you make it
vulnerable to attacks. Even in block ciphers where CBC is used the IV
has to be random per session...
> One more thing - some people here have suggested
> using PGP. I don't have the PGP software, but
> assuming I do, is there an advantage in using your
> software? Or do I need to create a 100 character
> password for PGP in order to acheive the same thing
> as yours? Thanks. Paul.
Well PGP supports other algorithms like CAST and IDEA. Generally you
can use RC4 and assume (well hopefully) a high level of trust in the
cipher. I would inspect his code though to make sure it peforms RC4
and has no hidden doors. As long as your room is not bugged and nobody
forcefully takes the password from you you should be set. :)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to crack monoalphabetic ciphers
Date: Fri, 16 Jul 1999 12:52:29 GMT
In article <7mn97v$e3o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Yes, I would suppose so since each compression algorithm works
> differently.
Then hybrid systems like LZSS+huffman or LZ77+huffman would really
throw this off?
> This is what I thought you were talking about<above>. Since a PRNG
has
> a period, it will eventually repeat and then it can be analyzed and
> broken. This of course assumes you have enough ciphertext. If the
PRNG
> only repeats itself 5 time, for example, when applied to a plaintext
> message, you won't get a good enough analysis. If it repeats 100
times
> when applied to a message, you will get a good analysis of the cipher.
Well it was what I was talking about. What if the period is longer
then the message?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Fri, 16 Jul 1999 08:37:45 -0600
Reply-To: [EMAIL PROTECTED]
fungus wrote:
> "Douglas A. Gwyn" wrote:
> >
> > I guess we have ample demonstration in this thread that people
> > really do have trouble with probability questions.
> >
>
> Heh... :-)
>
> The dice game is a real nasty one. It seems you have a 50/50
> chance of getting your money back, and also a small chance of
> winning even more (when you number comes up two or three times).
>
> So the odds are in your favour, right?
>
> A simple proof that they aren't goes as follows:
> This game is actually played in carnavals and casinos. The
> people who run these games don't like to lose money....
>
The existence of casinos also refutes most ESP claims.
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 16 Jul 1999 12:22:08 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
>> You mean that since you don't see any difference you assert
>> as fact that they are equally secure? That clearly falls
>> into the "just making it up" category.
>
>No I mean because each element is used with equal prob it shouldn't
>matter. Maybe it is but I really don't see that as a plasuaible
>weakness, can you?[...]
Well, I can see it as a plausible weakness - in fact it is definitely a
crippling weakness. RC4 with arbitrary initialisation can find itself locked
into a short cycle, where it continuously outputs the same short (255 byte)
sequence. For random keys, this nasty state of affairs occurs with probability
1/256.
The normal initialisation (x=0, y=0) has the effect of guaranteeing that such
a crippled state cannot occur. However with your change - minor as it seems -
that no longer works and it is now once again possible to get short cycles.
The cipher is changed from quite secure, to secure usually but fairly often
childishly weak.
You should be aware that this is a very common phenomenon in cryptography;
making very small changes to an algorithm often has dramatic effects on
security, even if it is very difficult to see how. Essentially, every time you
make even a very small change, you have a different cipher and must commence
analysis all over again.
Think of it this way: if you made an arbitrary, one or two character change in
code for some complex calculation (say, inverting a matrix or something),
would you expect the changed code to give a sensible result? Of course not.
You only think you can get away with it in crypto because nearly all outputs
look similar - like gibberish.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Funny News
Date: Fri, 16 Jul 1999 08:36:39 -0600
Reply-To: [EMAIL PROTECTED]
Bradley Yearwood wrote:
> In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> >
> >[EMAIL PROTECTED] wrote:
> >>
> >> Watching CNN today I saw a clip of Janet Reno (hey wheres the blue
> >> dress?) and I semi-quote
> >>
> >> " Terroists can use encryption technologies making wiretaps effectively
> >> useless and crime prevention much harder ... "
> >>
> >> Basically she was advocating the restrictions.
> >>
> >> My question is (this is an open question), What good do these
> >> regulations ACTUALLY provide? If a criminal breaks the law won't logic
> >> dictate they won't follow this law as well?
> >>
> >
> >The specific argument that control is useless because criminals
> >will ignore regulations is false logic.
>
> It is no more false than any other use of bad assumptions. Bad assumption:
> control and regulation are not at least as much of a potential threat as the
> actions of an individual criminal. What is being discussed is the
> criminalization of acts and mechanisms which are currently legal and unlike,
> for example H-bombs, have incredibly diverse utility whose true extent is
> still being discovered.
>
> Janet Reno's views on anything deserve little attention. Far too much
> government malfeasance, of both the brutal and the insidious varieties,
> has happened on her watch. Her only current value (to anyone other than
> her perfidious boss) is in providing grist for the occasional refreshingly
> vitriolic Wall Street Journal editorial squib.
>
> Wiretaps (with the possible exception of transborder communications, where
> I might grudgingly support a requirement for readability) are very likely
> nearly useless anyway. There was a nice program the other night on TLC or
> Discovery, about that Mob boss who walked around in a filthy bathrobe trying
> to make people believe he was insane. These guys, probably not a really
> brilliant bunch, knew enough not to use the phone. Bugs were useful, because
> they could get the guys talking in person at a restaurant table, where hot
> communication and negotiation happen. That meant someone had to match wits,
> go in, and do actual tough case work.
>
> Enforcement and prosecution apparatchiks appear to be very enthusiastic about
> easily quantifiable "crimes": speed limits, possession of certain chemicals,
> possession of scary-looking guns, having or moving too much money without
> the paperwork-of-the-week. So add possession of non-government-readable
> information (love letters? bad poetry? unified field theory? collection of
> facts inconvenient to a powerful politician or party?) to the list.
>
> Isn't that likely to be just another distraction from (actually an active
> enticement against) difficult and nasty work on difficult and nasty crimes
> where people actually get hurt or killed?
>
> You want a national security state that can tap all the phone calls and
> read all the mail, go rebuild East Germany somewhere, preferably Pluto.
> Just look at their stellar record of noble police work. That's what you
> get when you allow a structural emphasis upon thoughtcrime: stuck on the
> road somewhere between an info speed trap and Stasi thug-paradise. That
> is not the United States envisioned in the Declaration, and framed in the
> Constitution and Bill of Rights.
However, it does seem to be Ms Reno's and the current Administration's ideal. Other
Administrations have been equally bad.
------------------------------
From: Stelios Koroneos <[EMAIL PROTECTED]>
Subject: Implementing the CS-Cipher
Date: Fri, 16 Jul 1999 17:30:50 +0300
I am trying to implement the CS-Chipher on the AVR mcu.
( http://www.cie-signaux.fr/security/)
I have finished the key generation routine sucessfully (results are
matching the ones published in the paper describing the algorithm).
I am facing a problem regarding the first layer of the first encryption
round, as i get 2 bytes different than the ones that are mention in the
paper as test results.
To be more specific.
(All values are in hex copied directly from the assembler text)
Dummy_PlainText: .db $01,$23,$45,$67,$89,$ab,$cd,$ef
DummyKey: .Db
01,$23,$45,$67,$89,$ab,$cd,$ef,$fe,$dc,$ba,$98,$76,$54,$32,$10
Calculating the keys results in K0=45fd137a4edf9ec4
Xoring K0 with the Plain Text and splitting into 16 bit pairs results
Pair1-2 : 44de
Pair3-4: 561d
Pair5-6: c774
Pair7-8: 532b
Calculation of the Yl/Yr is done as follows
Yl=P((R1(Xl) and $55) xor Xl) xor Xr
Yr=P((R1(Xl) xor Xr)
Results of the above calculations for Pair1-2,Pair3-4,Pair7-8 are
according to example data
Pair1-2 : d856
Pair3-4: 5c90
Pair7-8: 78e3
The difference is in Pair5-6 which calculates to 2824 instead of 19b0
which is mentioned in the example
Doing the calculation by hand comes to the same result
PlainText[Byte 5]=89
PlainText[Byte 6]=ab
Key0[Byte 5]=4e
Key0[Byte 6]=df
89 xor 4e =c7
ab xor df = 74
C7<<1 = 8e
8e and 55 = 04
04 xor c7= c3
c3 xor 74 = b7 which using table P becomes 28
and Yr=24
I have done the above calculations many times but i can not find any
error.
Is it possible that there is a typo in the test values printed or i am
doing something wrong ?
Thank you in advance for your time.
Stelios Koroneos
--
Http://Come.to/Stelios_Cellar
------------------------------
From: "Nigel Porter" <[EMAIL PROTECTED]>
Subject: RC6a
Date: Fri, 16 Jul 1999 15:41:32 +0100
I heard that RC6 has been updated to improve the key schedule. I had a brief
look in the "AES cypher lounge" and on the RSA web site but could not find
any document/code to provide the details of RC6a.
Does anyone have a link to a download of document/source for RC6a?
Thanks,
N
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: RC6a
Date: Fri, 16 Jul 1999 16:02:36 GMT
In article <7mnf1r$na0$[EMAIL PROTECTED]>, "Nigel Porter"
<[EMAIL PROTECTED]> wrote:
> I heard that RC6 has been updated to improve the key schedule. I had a brief
> look in the "AES cypher lounge" and on the RSA web site but could not find
> any document/code to provide the details of RC6a.
>
> Does anyone have a link to a download of document/source for RC6a?
The RC6a algorithm (RC6 with a new key schedule) is documented in the
appendix of RSA's AES Round 1 comments. This document can be found at
the following URL:
<http://csrc.nist.gov/encryption/aes/round1/comments/990414-mrobshaw.pdf>
-Richard
------------------------------
** 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
******************************
