Cryptography-Digest Digest #259, Volume #11 Sun, 5 Mar 00 15:13:01 EST
Contents:
Re: why xor?(look out,newbie question! :) ([EMAIL PROTECTED])
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David A.
Wagner)
Re: very tiny algorithm - any better than XOR? (David A. Wagner)
Re: very tiny algorithm - any better than XOR? (David A. Wagner)
Re: differential cryptanalysis ([EMAIL PROTECTED])
Re: THE CIA ... please deport me ... or FBI/NSA or any of people ... please, I have
been in the USA too long .... I am on my way to Vladivostok as I have already going
there since 1990 or so .... it is my train .. your train is HUUHAA .. my train is the
LO ("Mark Brooks")
Re: On jamming interception networks ([EMAIL PROTECTED])
Re: Excel password remover ([EMAIL PROTECTED])
Re: 'Free' services with tokens/puzzles ("Joseph Ashwood")
Re: very tiny algorithm - any better than XOR? (Jim Gillogly)
Re: Passphrase Quality ? (Guy Macon)
Re: CLSID and Security ("John E. Kuslich")
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: CLSID and Security (David Hopwood)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: why xor?(look out,newbie question! :)
Date: Sun, 05 Mar 2000 18:04:04 GMT
In article <89tvbk$3nk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> cypher=(text + rnd)mod 256
> on each byte of plain-text.Theoreticly,it should
> produce uniform distribution of same interval as
> rnd number,right?
Right, this is a stream cipher, if your Pseudorandom
Number generator is secure your stream cipher will
be secure.
> Now some friends of mine tell me: No,don't use
> that,use xor,everybodies using xor....
> Sooo,now I wonder why is it,really,that there's so
> many algorithms out there that choose to use xor
> rather than some other method?Is it just for
> speed,or because you can use a single function for
> both encrypt and decrypt or there's something
> more to it?
In this context to use xor or to use add mod 256
is the same from the security stand point.
Xor is more fast and the same function do encryption
and decryption, but in some case you need additions
(for example in order to mix operation from different
algebraic groups, like IDEA or Blowfish F() function)
> ps.And when you already here,could you give me a
> short comment on my initial idea of
> encryption.What would be your line of attack,if
> U need to decrypt it?
The point is the PRNG used. If you use for example
a linear congruential generator your algorithm is
weak, if you use a belived strong block cipher or
a one way hash function like SHA1 in order to create
the "keystream" your algorithm is strong. Anyway
this scheme is subject to an insertion attack: if
the attacker known the encrypted plaintext he will
be able to replace the ciphertext in a way that
it'll decrypt in some text that the attacker want.
bye,
antirez
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 5 Mar 2000 09:33:36 -0800
In article <89tu0t$2uc$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> It's well known that in some case stream ciphers
> are vurnerable
> to a "meet in the middle known plaintext" attack.
> This means that
> if P xor S = C the attacker that known P can
> obtain S and replace
> P with an arbitrary P'. How is possible to avoid
> this problem?
First off, this is not what is meant by a "meet in the middle" attack.
Second, the right solution is to authenticate the text using a separate
crypto-algorithm, usually called a MAC. Favorites includes SHA-HMAC and
TripleDES-CBC-MAC.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 5 Mar 2000 09:42:56 -0800
In article <89mpfs$7ch$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> I've never heard of Treyfer, got a URL?
FSE'97. You might need to slightly adapt the cipher, but the basic
idea there (opportunistically scavenging whatever you've already got
in the ROM for use as a vaguely-nonlinear S-box) seems very powerful
for exceedingly constrained applications like the one discussed here.
> GOST is actually well suited for 4-bit cpu's,but requires 64 bytes of
> S-box data.
Ok. I guess one could imagine a 64-round GOST/Treyfer hybrid, or somesuch.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 5 Mar 2000 09:48:53 -0800
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
> Anyone have any idea how secure RC5 is with a 16 bit block size?
How much data are you encrypting? With more than ~ 500 bytes of
text, a tiny bit information starts to leak. With megabytes of
ciphertext, the cryptanalysis problem is probably amenable to
classical (simple substitution cipher) techniques, and I'd imagine
it may become practical to start reading traffic if you know what
you're doing. But those comments are true of any block cipher with
16 bit block size. If you use some ridiculous number of rounds (64?)
with RC5, it looks awfully good to me, and I suspect it ought to be
as strong as anything with a 16 bit block size.
(I'm assuming you'll use CBC or CFB mode here, not ECB or counter
or OFB mode.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: differential cryptanalysis
Date: 5 Mar 2000 18:55:42 GMT
In a previous article, <[EMAIL PROTECTED]> writes:
>[...] Any attacker *in a chosen-ciphertext model*
>will get to *choose* to send blocks with a specific value of R. No matter
>how large R is, the attacker can choose whatever value he likes and use
>it for every chosen ciphertext he injects on the wire.
Of course. I guess you don't have to worry too much about differential
cryptoanalysis unless the attacker possess a decrypting device, or in some
way is able to monitor and interpret the responses of the legitimate
receiver.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Mark Brooks" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.nordic,soc.culture.russian,soc.culture.soviet
Subject: Re: THE CIA ... please deport me ... or FBI/NSA or any of people ... please,
I have been in the USA too long .... I am on my way to Vladivostok as I have already
going there since 1990 or so .... it is my train .. your train is HUUHAA .. my train
is the LO
Date: Sun, 05 Mar 2000 19:02:07 GMT
You have been traveling to Vladivostok since 1990 by train?
Maybe you should start thinking about booking a flight?...or at least stick
your head out of the window to see if a locomotive is attached.
Perhaps the fact that no one has figured out to lay tracks across the
Pacific ocean is what's slowing you down? One company did try it but the
weight of the train caused the tracks to flip over. Now that train lies at
the bottom of the Marianas trench. It was a sad day as the investors lost a
lot of money. It was not a total loss as it was discovered that iron rails
do not float. At the time this was considered a great scientific
achievement. The man responsible for much of the research, Prof. Murray
Schwartz received a Nobel peace prize and a teaching position at Princeton
University for his discovery of the sinking iron phenomonon.
"Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> THE CIA ... please deport me ... or FBI/NSA or any of people ...
> please deport me and replace me .. you can find some Mexican street drug
> runners or some other people .... I have been tired of being in the USA
> for years and I do not want to stay here .... I am on my way to
> Vladivostok as I planned in 1990 and I have already been going there
> since 1990 or so .... it is my train .. your train is HUUHAA (and a
> person C2 discussed this HUUHAA train with a person B4 .. :) HAHAHAHAHA
> ) that was captured by my train .. my train is the LOVE train going
> through the whole Russia ... and this is my dream ...
>
> Yours,
>
> Markku
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On jamming interception networks
Date: Sun, 05 Mar 2000 19:02:01 GMT
> In one previous follow-up I have remarked on some other people's
> suggestions on the internet in the past (I read many times
> such suggestions) of intentionally putting words such as 'bombs'
> in e-mails in order to 'waste' the resources of the interception
> agencies and hence block these. (There was last year even an
> action asking people to do that on a particular day.) I argued why
> that is not useful to achieve the intended purpose. For those at
> the agencies are certainly not unintelligent. They 'must' know
> that no terrorist, unless he is a fool, would ever write such words
> in plaintext in his messages to his companions. Thus I conjecture
> that there is even a possibility that they in fact put such key words
> in a 'negative' list to sort out from the outset stuffs that are
> uninteresting. A person shouting lourdly in the street that he is
> going to rob a bank is certainly and definitely not a gangster but
> rather a candidate for the psychiartric clinic. Do you see my point?
Would be nice, but it's not logical. If you were right, it always made
sense to put words like "bomb" in the mails. If they were on the
exclusion lists, I would not be surveilled. If they were on the inclusion
lists, we would jamm the interception network. I don't think that simple
keyword triggered lists are used at all. If anyone wants to surveille
large communication networks, there are more sophisticated tools to do
that.
But I also don't think that terrorists don't use words like "bomb" in
their mails. Terrorists, criminals and so on, often have a "support"
community--- a network of people acting semi-legally or plain legal and
in one way or other have to do with the few "active" terrorists. These
people will sometimes use plain text messages without any "code words".
And collecting information is then combining many pieces of a puzzle
until you can draw some conclusions. That's why I think analysis of
normal, unencrypted communication can be very interesting to various
agencies.
Greetings,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Excel password remover
Date: 5 Mar 2000 19:01:54 GMT
In a previous article, "Tobiass Mai" <[EMAIL PROTECTED]> writes:
>I've written a program which removes the protection of
>Excel-workbooks/-sheets.
>Can anybody tell me if i can get in trouble with Microsoft?
Maybe, but I do not see why: Each xls-file is the intellectual property of the
person who created it, and I guess it is the xls-files - not Excel - your
application will tamper with.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 'Free' services with tokens/puzzles
Date: Sun, 5 Mar 2000 11:15:48 -0000
I must agree, these are the questions that need to be
answered in order to determine which method supplies the
appropriate protection.
> But a crucial question must be how great the probability
is that corrupted
> data will be accepted. This probability might not only
depend on the
> reliability of the tests that once in a while are
performed. There are a
> number of questions involved: Will each client be tested
at least once within
> a given time span before the data it generated during that
time period is
> accepted? What is the probability that the client was
actually performing
> it's designated task when it was tested but not all of the
rest of the time?
> Is there even a slight probability that a task will be
recognized as being a
> corruption test?
In addition I realized that both of our methods are subject
to a man in the middle attack, as follows:
download real software on client A
create fake software on client B
make A think B is the server
Whenever A talks B routes the data to the server
Whenever the server talks B filters it and sends the data to
A
Whenever B wishes to use the connection B sends to the
server.
If you want to avoid attacks like this, then neither of the
proposed methods will work.
Joe
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: very tiny algorithm - any better than XOR?
Date: Sun, 05 Mar 2000 19:23:55 +0000
"David A. Wagner" wrote:
>
> In article <89kjtn$[EMAIL PROTECTED]>,
> Harvey Rook <[EMAIL PROTECTED]> wrote:
> > Hmmm. Speaking of Tiny Algorithms. How effective is RC-4 with only 16, 24,
> > or 32 bytes in the SBox.
>
> If I recall correctly, a regular poster here has done some work
> on this and found that at least the case of 16 bytes is much less
> secure than you can expect. Search the archives for hillclimbing
> and RC4.
Right - I did a hillclimbing attack on the 16-byte case that recovered
the state array in about 2^28 decryptions rather than the 2^44 steps
suggested by the 16! possibilities. It does not scale to a practical
attack on full RC4, but it effectively trashes RC4-nibble.
--
Jim Gillogly
Hevensday, 14 Rethe S.R. 2000, 19:19
12.19.7.0.4, 8 Kan 12 Kayab, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.dev.null
Subject: Re: Passphrase Quality ?
Date: 05 Mar 2000 14:57:37 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (jungle) wrote:
>
>IMO you did get all this wrong ...
>
>my way is to never remember pass text ...
>
>you will not spit a dummy only when you don't know the dummy,
>is it clear now for you ?
>
'Twas brillig, and the slithy toves did gyre and gimble in the wabe;
All mimsy were the borogoves, and the mome raths outgrabe. "Beware the
Jabberwock, my son! The jaws that bite, the claws that catch! Beware the
Jubjub bird, and shun the frumious Bandersnatch!" He took his vorpal sword
in hand: long time the manxome foe he sought -- So rested he by the Tumtum
tree, and stood awhile in thought. And, as in uffish thought he stood, the
Jabberwock, with eyes of flame, came whiffling through the tulgey wood,
and burbled as it came! One two! One two! And through and through he
vorpal blade went snicker-snack! He left it dead, and with its head he
went galumphing back. "And hast thou slain the Jabberwock? Come to my arms,
my beamish boy! O frabjous day! Callooh! Callay!" he chortled in his joy.
'Twas brillig, and the slithy toves did gyre and gimble in the wabe; All
mimsy were the borogoves, and the mome raths outgrabe.
is also it clear now for as well you ?
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: CLSID and Security
Date: Sun, 5 Mar 2000 12:58:56 -0700
"They" say that in the documentation on COM you find at the Microsoft
Developer Network site. www.msdn.com The is a very good site, by the way.
I think you are right, the CoCreateGUID API call has probably been changed
since the release of WIN98 Second (and almost working, just crashes a few
times per day) Edition, which I use.
This is reminiscent of the old OLE2 bug that caused memory slag to be placed
into Office Documents.
I still think THAT bug will eventually cause someone to find tort relief in
the courts. It was just an unimaginably bad security bug. I always thought
the PC press severely under rated it. It is the kind of bug that has put
data time bombs into all sorts of computer systems. In years to come,
computer forensics people will find Office Documents to be gold mines of
data. I can just picture historians of the future going over old E-Mail
archives and picking out some real dirt on Clinton and Gore many other
politicians.
JK http://www.crak.com Password Recovery Software
David Hopwood <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> "John E. Kuslich" wrote:
> > I was reading the Microsoft documentation on COM objects and how CLSID's
> > are used to provide, with almost absolute certainty, a uniquely
identifying
> > number. This number is used to identify interfaces for COM objects
across
> > any arbitrary boundary.
> >
> > They then go on to say that these CLSID's are not linked to the ethernet
> > MAC address for security reasons.
>
> Where do they say that? It's not correct: CoCreateGUID does use the MAC
> address when it is available.
>
> (In general, all of Microsoft's documentation has to be taken with a
> healthy degree of skepticism, especially with regard to security. In
> particular, they often document what somebody thought should happen,
> rather than what somebody else implemented.)
>
> > Well, when I compute a CLSID using the CoCreateGUID from the Windows
API, I
> > find that the MAC address of the GUID so created is laying right there
in
> > the last few bytes of the GUID.
> >
> > What am I missing here.
> >
> > I can surely see why the MAC address could be a security risk in some
> > situations.
>
> You're not missing anything, AFAICS.
>
> - --
> David Hopwood <[EMAIL PROTECTED]>
> PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBOMGbFDkCAxeYt5gVAQG1Bgf+MO9uiGcGUSSFviTaUt/DuF7cAlsETwX5
> EwxiSljxyFpUKiOf8phPYFdhwM4WthQl+KvfBedFZXednvEGMV0iHfc2YHJ/G3Oo
> yFSCMQd3Zx54KI8zNZU+J1Ef4dWCJzJ41Zw9AvOSXtiU+HvDHGWOWnhhFofsRDgV
> NOPw/7nlzkQE3RTleznFUhHO7fry8POCDONfadtHKj1kEENlJlBPN3NTEWWlv1Fw
> 80PFAyfUGAceCiXhsOBIQbMTe9EhqDDkx7mHGBuPw9NKwpg/ka5qUictRX6Az5Ql
> PVEZaCByr2Uqayug2GFaa0eFjHMMIdnrJXLE6+h7FIbeBrdsweTHSg==
> =Sle2
> -----END PGP SIGNATURE-----
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: Sun, 05 Mar 2000 19:45:50 GMT
In article <89u5pg$dlr$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <89tu0t$2uc$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
wrote:
> > if P xor S = C the attacker that known P can
> > obtain S and replace
> > P with an arbitrary P'. How is possible to avoid
> > this problem?
>
> First off, this is not what is meant by a "meet in the middle" attack.
Sorry, what's the right name for this kind of attack?
> Second, the right solution is to authenticate the text using a
separate
> crypto-algorithm, usually called a MAC. Favorites includes SHA-HMAC
and
> TripleDES-CBC-MAC.
No, I cant
A stream cipher is very useful to encrypt a socket in the
case of a telnet-like connection since if you use a block
cipher you needs to spent more bandwidth. In this case
you can not use a MAC since you need that every byte reach
the destination ASAP.
To use some material from the keystream to setup an sbox
_if it is secure_ is a possible solution? if you scramble
the sbox every X bytes is even better? The problem is that
I want to learn from a cryptographer if it is/isn't secure 8)
thanks,
antirez
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 05 Mar 2000 02:20:54 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: CLSID and Security
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
[...]
> There was a big ruckus a few months ago (front page article NY Times)
> when Richard Smith discovered that the GUID's contained the MAC address;
> and further, files like Microsoft Word documents and Excel spreadsheets
> contained GUID's which connected then back to the machines that the files
> were written on. I think a GUID like that was found in the Melissa virus
> and that's how they caught the author.
This is very often misreported: the GUID that was found was from a previous
virus that Melissa was based on, by a different author (the GUID is not
assigned when a document is edited, only when it is created). I don't
remember how the author of Melissa was caught, but it was not by this
method.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMHENjkCAxeYt5gVAQGaLAf+KZCHAs8BNa3LrsBYdwPYcXkSEcyRxXs/
mfJsSJmOd3GeVY7uyiR6G2BNaHtREhZ4ZHvs6p+hw4gFXlEXAtWrJwJFNpo/kshX
ATuxukGC7HQK70bCxdinC8cYffYZOYRivqInFFsw3vAju88RagcMcXkqaRAreQBu
agLYwsjkTF1tV4Q88IzZ60KcwBCH89pPYQuBv5TdB/qgpsyUiMj+yH2RtaCwh3IC
wShkCeAs6D5Oo4113QlCMy6enOW8VNK6aY3IJz1iliM/Ni3K5q2P5Ybg3BnocUJ6
nZO06ZkAvknkMDp3DqfR6NUcWEpXpgq8ao7EVv7FmrNHRrOgX5PZ0g==
=FpCY
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
