Cryptography-Digest Digest #189, Volume #14 Fri, 20 Apr 01 05:13:00 EDT
Contents:
WHY I HATE BOSCHLOO (Fight Boschloo)
Yarrow code update? (pjf)
Will this defeat keyloggers ? (Anonymous)
Re: Will this defeat keyloggers ? (pjf)
Re: First cipher ([EMAIL PROTECTED])
Re: First cipher ([EMAIL PROTECTED])
Re: First cipher ([EMAIL PROTECTED])
Re: OTP breaking strategy (Volker Hetzer)
Re: newbie: cryptanalysis of pseudo-random OTP? ("Osugi Sakae")
Re: OTP breaking strategy (Volker Hetzer)
Re: OTP breaking strategy (Volker Hetzer)
Re: "UNCOBER" = Universal Code Breaker (Joe H Acker)
----------------------------------------------------------------------------
Date: 20 Apr 2001 07:11:36 -0000
From: [EMAIL PROTECTED] (Fight Boschloo)
Subject: WHY I HATE BOSCHLOO
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
I hate Boschloo
===============================================
HISTORY:
That Boschloo bozo is a clown and a troll who has been looming around for nearly a
year.
Don't mistake a "regular" (troll) with a knowledgeable person: that self-proclaimed
"security expert" is not even a remailer user. In the past, he proved himself unable
to check a PGP signature, and got ridicule from every single technical topic he wanted
to talk about.
Besides false or inaccurate or misleading technical misinformation, his posts are
about his avowed mental illness, or for bashing remops or real freedom fighters: he
likes to quarrel with every one, and stir shit. Sometimes, it is even pure delirium
(when he misses his pills?)
One of his last actions was to stage a hoax about his own suicide, just to try to grab
some sympathy, after he had been exposed as a troll and technically incompetent.
The worst being his teasing of Script-Kiddie until it triggered a new flood on apas.
Of course, he refuses to apologize.
Actually, the level of contempt he shows for remailer users:
they don't give their names, while he does
that can't do anything against him, without giving their names
is in no way different from what is displayed by Pangborn, Burnore and the like
Ignore him completely, killfile him, respect others' killfiles
KILLFILE:
To put him in your killfile, put "Author: Boschloo"
That will make disappear both him and people who warn about him
If you want to tell him to buzz off, or warn about him,
use a nickname containing "Boschloo" (Boschloo Hater, Boschloo Sucks,...)
to accomodate such killfile for "regulars", and still warn newbies
COURAGE:
Boschloo is getting _no_ answer from apas any more.
He has to crosspost to various newsgroups to try to grab some attention.
In a few months, it will be gone.
------------------------------
From: [EMAIL PROTECTED] (pjf)
Subject: Yarrow code update?
Date: Fri, 20 Apr 2001 07:22:17 GMT
Greetings.
I was wondering if anyone knew the status of Yarrow, and whether or
not there was a new version coming out with the "kernel driver"
functionality that is mentioned in the readme files of the
downloadable source.
I'd like to use it in my cryptographic library, but I am loathe to use
the FrontEnd app included in the currently available version of the
download. I'd rather just link in a DLL or LIB...
Thanks for any info or pointers you can give me.
-pjf
--
[EMAIL PROTECTED]
http://www.staticengine.com
Developer, KnowWonder Inc.
Musician, Static Engine
---
Digital Certificates provide no actual security for
electronic commerce; it's a complete sham.
-Bruce Schneier, Secrets & Lies
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
Date: Fri, 20 Apr 2001 09:27:02 +0200
From: Anonymous <[EMAIL PROTECTED]>
Subject: Will this defeat keyloggers ?
Hello,
Say for arguments sake I create a password/phrase on a stand alone
machine and save it to a removable disk.
If I now use an encryption algorithm on another machine and call the
password/phrase from the removable disk instead of typing it on the
keyboard, will this method defeat the average keylogger ?.
Thanks for your time.
------------------------------
From: [EMAIL PROTECTED] (pjf)
Subject: Re: Will this defeat keyloggers ?
Date: Fri, 20 Apr 2001 07:31:41 GMT
Yes, but by grabbing your passphrase from over the network on a remote
machine and removable disk, you open yourself up to far more problems
than keylogging.
*Network Packet Sniffing
*Someone taking the disk from the other machine while you're not near
it
*Watching the memory on your box to see what passphrase you're piping
in remotely...
I'm sure there are others.
-pjf
On Fri, 20 Apr 2001 09:27:02 +0200, Anonymous
<[EMAIL PROTECTED]> wrote:
>Hello,
>Say for arguments sake I create a password/phrase on a stand alone
>machine and save it to a removable disk.
>If I now use an encryption algorithm on another machine and call the
>password/phrase from the removable disk instead of typing it on the
>keyboard, will this method defeat the average keylogger ?.
>Thanks for your time.
>
--
[EMAIL PROTECTED]
http://www.staticengine.com
Developer, KnowWonder Inc.
Musician, Static Engine
---
Digital Certificates provide no actual security for
electronic commerce; it's a complete sham.
-Bruce Schneier, Secrets & Lies
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 22:45:32 -0800
Tom St Denis wrote:
>
> LCS? That's not a standard function AFAIK. A circular (or cyclic) shift is
> denoted by <<< or >>>. What does LCS(x,y) mean?
I was trying to denote a left circular shift which is a function of two
bits from the round key, which I arbitrarily chose to be b1 and b0. I'll
use <<< in the future but I'm not sure how to adapt <<< to indicate that
the number of shifts
depends on a variable.
> This will suffer badly from differential attacks IMHO. Unless you
> design your sboxes very carefully. Also standard terminology for a 256
> element array with 4-bit elements is a 8x4 not 8x8. Unless your rows and
> columns are very independent of each other (and differentially distanced
> too) this will be easy to break.
Standard terminology noted. Any pointers on S-box design? Fill a matrix
with elements that are maximally spaced so that a single change in input
choses a different element in the matrix which will be maximally spaced
from the previous element?
> > e. Left circular shift the output from (d) with the number
> > of shifts determined by two bits from the subkey.
>
> This is crytographically useless since a differential attack will make the
> same output differences in the same spots... (rotate is key constant).
Is it useless only because it is key constant or useless in general,
i.e. would
it be of any value if it also depended on the input to the round
function?
> Well first why do you expand to 64 bits in your round function? Typically
> it's idea to make your round function a bijection.
I was trying to hit as many S-boxes a possible.
> I would read up on cryptanalysis too..
I'm slowly making my way through some of the literature: _Applied
Cryptography_ by Schneier, _Handbook of Applied Cryptography_ from CRC,
_Cipher Systems_ by Beker and Piper.
I don't have any cryptanalysis books though. My number theory is also
weak.
Suggestions?
> Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 22:55:11 -0800
Scott Fluhrer wrote:
> > It seems like an S-box design would have to be optimized against a
> > certain
> > type of attack and weak against other attacks, or is the S-box only
> > meant
> > to thwart a differential attack? Why must an S-box be bijective given
> > that the F function needn't be reversible?
>
> Well, it needn't (the F function in DES isn't reversible), but it's usually
> a good idea. Otherwise, you tend to be vulnerable to differentials of the
> form:
> (0, X)
> where one half has a zero differential, and the other half has a nonzero
> differential. If, in your F function, the F function turns the X
> differential into a 0 differential with probability p>0, then you have a two
> round differential that starts with (0, X), and ends with (0, X) with
> probability p.
I found a paper in the Springer-Verlag Lecture Notes in Computer Science
Cryptography Proceedings (1982) which analyzed random, reversible
S-boxes.
Supposedly, if the S-box is reversible and the number of bits per table
entry is large, then the probability of a random S-box having one or
more bits that are linear functions of the address bits is low.
So, for whatever reason, reversible S-boxes seem to be the way to go.
> Now, when DES was designed, they specifically considered this differential,
> and made sure it couldn't be concatinated with itself. Of course, they knew
> what they were doing...
Ah, but at one time each one of them was a neophyte just like me.
> --
> poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 23:10:09 -0800
"M.S. Bob" wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Here's my first attempt at a block cipher. Please critique
> > and explain WHY as well as where I'm going wrong.
> >
> > 1.) Feistel network, blocklength 64 bits, 128-bit key, 16 rounds
>
> Short (pointers to more) reading list:
>
> Memo to the Amateur Cipher Designer
> <http://www.counterpane.com/crypto-gram-9810.html#cipherdesign>
>
> Self-Study Course in Block Cipher Cryptanalysis
> <http://www.counterpane.com/self-study.html>
>
> Memo to the Amateur Cipher Designer
> by Bruce Schneier (October 15, 1998)
>
> Congratulations. You've just invented this great new cipher, and you
> want to do something with it. You're new in the field; no one's heard of
> you, and you don't have any credentials as a
> cryptanalyst.
[snip entire post from URL given above]
Parroting what Schneier says isn't necessary. I have a web browser and
get the Crypto-GRAM like everyone else. How about something a little
more
useful, like pointers on how to cryptanalyze my cipher so I don't bug
the
group with the obvious?
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Fri, 20 Apr 2001 10:39:04 +0200
Volker Hetzer wrote:
>
> newbie wrote:
> >
> > It is hard to break OTP but not impossible.
> > Let me explain my strategy. You think that I do not know what I'm
> > talking about.
> Right.
> Now, here's your chance of getting the nobel prize in maths:
> Appended you find a file encrypted with the OTP. (Ok, I didn't throw
> coins but it's close enough.)
> Concext:
> It's a little C-program that implements the OTP.
> Now you tell me
> - whether the first line is #include <stdio.h> or #include "stdio.h"
> - the name or the input stream
So, how far did you get?
Do you require further context?
Are there any statements at all you can make about the C-program,
(apart from the fact that it probably contains the words include,
stdio.h and main?
Are there any reasons you cannot try out your algorithm on the sample?
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Osugi Sakae" <[EMAIL PROTECTED]>
Subject: Re: newbie: cryptanalysis of pseudo-random OTP?
Date: Fri, 20 Apr 2001 17:34:36 +0900
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, "M.S. Bob"
<[EMAIL PROTECTED]> wrote:
> Osugi Sakae wrote:
>>
>> forgive me for what is prolly a newbie question, but ...
[snip]
> Cryptanalysis by Helen Fouche Gaines (Dover Books less than $10 new) It
> covers most "classic" (pre-computer) ciphers, and requires no higher
> math knowledge. Also read about the American Cryptogram Association
> <http://www.und.nodak.edu/org/crypto/crypto/>
Thanks. I have Cryptanalysis. Great book, wish someone would update it
for the computer age.
> You determine the length of the key(word) by the Kasiski test or index
> of coincidence. Then you solve it simply as x number of different
> monoalphabetic substitutions ciphers using frequency analysis.
Yes, I understand that, but am wondering about the case when the keyword
is as long as the plaintext. In this case, when you find out that the
keyword does not repeat, how do you attack the ciphertext?
>> The books also mention that a OTP is only as secure as the random
>> number, but again don't mention how someone would break a pseudo-random
>> cipher. Is it something to do with probabilities of subsequent numbers
>> (for example, noticing that say 5 tends to follow 8 more often than 10%
>> of the time? (assuming a cipher that displays as numbers 0-9))
>
> 8.10. Can I use pseudo-random or chaotic numbers as a key stream?
>
> Chaotic equations and fractals produce an apparent randomness from
> relatively compact generators. Perhaps the simplest example is a
> linear congruential sequence, one of the most popular types of random
> number generators, where there is no obvious dependence between seeds
> and outputs. Unfortunately the graph of any such sequence will, in a
> high enough dimension, show up as a regular lattice. Mathematically
> this lattice corresponds to structure which is notoriously easy for
> cryptanalysts to exploit. More complicated generators have more
> complicated structure, which is why they make interesting pictures---
> but a cryptographically strong sequence will have no computable
> structure at all.
>
> See [KNU81], exercise 3.5-7; [REE77]; and [BOY89].
>
> from the sci.crypt FAQ <http://www.faqs.org/faqs/cryptography-faq/>
Thanks for the link, I will read that one right away. Unfortunately, just
reading the part you posted here, I can tell it is going to be a bit over
my head. Would the system I describe below show these `regular lattice'?
>> Also, OTP's are hard to impliment, because of the amount of data and
>> the need for secure exchange and storage. And they work best with a
>> limited number of people.
>>
>> So, thinking about these long keywords, OTP, and pseudo-random stuff, I
>> had an idea that I think i understand. (I am not suggesting this as a
>> real system, I understand that I am not qualified to declare any system
>> secure
>> (of course, if I can break it, it is most likely very insecure). This
>> is
>> just a thought exercise).
>>
>> 1. Take any previously agreed upon text - one from project gutenberg
>> would be good.
>
> Book cipher, read about them in Kahn.
>> 2. Just xor'ing with the text would not be secure, nor I gather would
>> doing some sort of transformation add all that much security.
>
> Book cipher with a unspecific twist. A bit more work, but not really a
> big deal.
>
>> 3. So, tally the letters' frequencies. Choose the two letters that
>> account for the closest percentage of the text (4.021% and
>> 4.074% for example).
>
> You lose me from here to the end.
Sorry, I meant them (1-5) as a sequence for generating a pseudo-random
OTP. Like I said, I am not suggesting that it would be secure, it was
just the logical outcome of my musings on the book cipher (keywork as
long as the plaintext) and how you crack it.
Assuming that the weakness of a book cipher is in the letter frequency
characteristics, it would be better to avoid high and low frequency
letters like 'e' and 'q'. But deleting any leaves holes in the alphabet
right? So convert to base ten (0-9) or base 2, or whatever.
So for base two, chose from the book, the two letters with
the closest frequencies. For example, A Tale of Two Cities, by
Charles Dickens [Project Gutenburg Etext #98] has these basic
stats: (includes the PG header)
a, 46798, 0.0811999
b, 7752, 0.0134506
c, 12830, 0.0222615
d, 26816, 0.0465288
e, 73636, 0.127767
f, 12972, 0.0225079
g, 11972, 0.0207728
h, 37804, 0.0655942
i, 37611, 0.0652594
j, 375, 0.000650668
k, 4639, 0.00804919
l, 21046, 0.0365172
m, 13506, 0.0234345
n, 41441, 0.0719049
o, 45533, 0.0790049
p, 9264, 0.0160741
q, 638, 0.001107
r, 36368, 0.0631026
s, 36358, 0.0630853
t, 51650, 0.0896186
u, 16391, 0.0284403
v, 5038, 0.0087415
w, 13333, 0.0231343
x, 720, 0.00124928
y, 11622, 0.0201655
z, 218, 0.000378255
total,576331
We could chose 'c' and 'f' or 'h' and 'i', or 'y' and 'g', etc.
Suppose we use 'c' and 'f'. Now delete everything else in the book.
"It was the best of times, it was the worst of times,
it was the age of wisdom, it was the age of foolishness,
it was the epoch of belief, it was the epoch of incredulity,
it was the season of Light, it was the season of Darkness,
it was the spring of hope, it was the winter of despair,
we had everything before us, we had nothing before us,
we were all going direct to Heaven, we were all going direct
the other way--in short, the period was so far like the present
period, that some of its noisiest authorities insisted on its
being received, for good or for evil, in the superlative degree
of comparison only. ..."
etc. becomes:
fffffcffcfcffffffccffcfffc... etc to the end of the book. How random
would this be? Linguistic frequencies have been removed or at least
minimized right?
To actually try to use this, would it be best to turn
fffffcffcfcffffffccffcfffc
into
00000100101000000110010001 (f = 0, c = 1)
and then binary xor it with the plaintext?
"HELLO" (no quotes) is 01001000 01000101 01001100 01001100 01001111, so
can easily be xor'ed with the results from Dickens book. But how secure
would this be? It is basically the computer equivalent of a poly-alphabet
with keyword as long as the plaintext, right? If not, what is it?
Like I said, I came to this point by thinking about the weakness of
book-ciphers. None of the books I have read dealt with this, aside from
mentioning that book ciphers are not as secure as amateurs might think.
So again, I am not claiming or even suggesting that the above method is
secure. Rather I am asking, how would one attack such a pseudo-random
book cipher? What is it that remains in the key that allows one to
crypto-analyse the message? Would putting the "key" through one or two
transposition ciphers before xor'ing it help any (assuming that remaining
info was in the specific sequence of letters.)
[snip]
> Not necessarily. A poor but long key x-or'ed does little to conceal the
> message.
Ok, i understand that, but what about a long, not-poor key? A long, pure
random key is an OTP, right?
[snip]
> Decrypted Secrets and Applied Cryptography are good books.
Sure are, but the math, especially the matrixes (matrii?) in Decrypted
Secrets was beyond my knowledge. Also, my programming knowledge is
insufficient to make heads or tails of the source code in Schneier's
book. On the otherhand, I know just enough perl to be able to muddle
through the perl cyber saber-code that someone posted on the web.
> Many newcomers find they need to refresh or learn some additional
> mathematics to understand more about cryptography. An idea of your
> mathematical knowledge might help suggest some possible books at a level
> you can understand.
Well, I took some physics and accompanying calculus as college, but only
a little and it was a while ago. I tried to bone up by reading
"Mathematics: from the birth of numbers" but that was not as helpful as
I had hoped (but it was a very helpful and interesting book). I am
currently going through Thompson's Calculus Made Easy,
and he sure does make it easy.
Thanks for your help. Hope this is comprehensible.
--
Osugi Sakae
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Fri, 20 Apr 2001 10:49:57 +0200
newbie wrote:
>
> You are reaching what I had tried to prouve.
> You could distinguish with extra-information which message is valid.
> And select the message. Because, the plaintext is deterministic
> sequence.
What extra information?
So far you haven't extracted a single bit of information from the
OTP encrypted share trading message. So, apply your algorithm
and show us that you can read something from the Message that was not
known to you before.
> If you could distinguish truly random output and not random, you have
> still a way to break it.
But you cannot. That's the point.
000 is just as random as 101.
> I know it is very hard. Very very hard. It is like rebuilding the
> plaintext with very few information.
> I said OTP could be broken practically.
> In theory, I KNOW that is unbreakable, but If you combine the context
> factor and other extra-information you can break it.
If you know the context, you know the context. You can learn nothing more.
In the example given to you, what more context do you require?
If you are told that the first letter is B and the word is either
sell or buy you might assume it's buy. But you don't need the encrypted
text for that and it won't help you determining the number of shares.
Assuming it's shares and not options.
Conclusion: You know what you are told ("context"), nothing more.
> [EMAIL PROTECTED] wrote:
> > Okay, remember that you don't have access to the pad itself. Now, suppose I
> > have two different pads and I encrypt the following two messages:
> >
> > SELL 750 SHARES
> > BUY 1000 SHARES
> >
> > Since I am not reusing the OTP, I encode each message with a different
> > pad. By some bizarre coincidence, the pads happen to encrypt their
> > messages to exactly the same result: 5e8f128c65a30954371a7e494217ad
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Fri, 20 Apr 2001 10:54:05 +0200
newbie wrote:
>
> I know that.
> But you have to read what I'm trying to say. Just decrypt what I'm
> saying.
> You are talking in theory.
> I assume that I use extra-information.
Is there any reason you have not so far turned the extra information
into a way to read something from the OTP encrypted message that you
didn't know before, i.e. that couldn't be derived from the context without
looking at the encrypted message?
> I'm not dummy.
Yes, you are.
> If all bit-string are truly random, even 1111111111111111111111111 or
> 000000000000 you should be right.
Right. They are.
> If all messages are related to the context, you should be right.
Very simple. All related messages are related to the context.
An OTP gives you no way to narrow it down.
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: [EMAIL PROTECTED] (Joe H Acker)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Fri, 20 Apr 2001 10:57:14 +0200
newbie <[EMAIL PROTECTED]> wrote:
> So if the probability of non-random is infinitesimal, why to try
> statistical tests to prove truly randomness?
> Statistical tests (Diehard, Maurer etc...), is it a loss of time?
Even a TRNG must run some statistical tests against his outputs to
continually affirm that it works correctly. Hardware can fail, and good
TRNG hardware has to detect this automatically. Like others have
mentioned, the tests do not prove that the output is random, but they
can indicate when the output is completely non-random and then a huge
red warning sign should show up "Alert! TRNG broken!"
BTW, I see no reason why the extremely rare cases when a TRNG outputs
sequences that appear to be extremely non-random shouldn't be discarded.
If the random source is truly random, it doesn't do any harm when some
of its output is discarded, except for performance slowdown. So yes,
tests are useful to (a) continually test wether the hardware has failed
or does appear to work correctly, and (b) to prevent against very very
bad luck when a true random source happens to output the complete volume
of Shakespeare's Macbeth (very unlikely)
Regards,
Erich
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
