Cryptography-Digest Digest #759, Volume #9 Thu, 24 Jun 99 09:13:02 EDT
Contents:
Re: one time pad (Greg Ofiesh)
1024-bit block cipher ([EMAIL PROTECTED])
[OT] alt.security.scramdisk spamming ("Andy Jeffries")
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Robert
Harley)
Re: Converting arbitrary bit sequences into plain English texts
([EMAIL PROTECTED])
Re: Converting arbitrary bit sequences into plain English texts
([EMAIL PROTECTED])
Echelon--Rights Violation in the Information Age (The Electronic Zola)
Re: On an old topic of internet publication of strong crypto (Mok-Kong Shen)
Re: Kryptos article (Jim Gillogly)
Re: Secure broadcast ("Gene Sokolov")
Re: 1024-bit block cipher ([EMAIL PROTECTED])
Re: "Breaking" a cipher ([EMAIL PROTECTED])
Re: xtea ([EMAIL PROTECTED])
Re: one time pad (Patrick Juola)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: Authentication Schemes (David P Jablon)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Medical
Electronics Lab)
----------------------------------------------------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 06:48:58 GMT
> Not true -- utter urban legend. PI has noticable statistical trends,
and
> it's very well approximated by very simple functions.
I thought Statistical randomness ment:
> >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.
Are you certain that this definition is not correct? Is this not what
you call statistical trends? i.e.- even distribution.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: 1024-bit block cipher
Date: Thu, 24 Jun 1999 07:39:03 GMT
1024-bit block cipher with weighed dispersion of bits
with 1 and 0 value.
For encryption is used input block 128 bytes and output
block 256 bytes. For decryption is used input block 256
bytes and output block 128 bytes. The first plain block
is composed with 4 bytes, which contains the length of
the original file, and bytes from the plain file. A key
length is 256 byte. A key can be inserted using keyboard
or from a file. Inserted key overwrites the default key
in the memory. So the default key compliments an inserted
key, if it is too short. If inserted key is a file, then
first 256 byte would be used as inserted key.
All this makes a current key. A current key is transformed
to effective key using 10 round 8-bit chained Alex encryption
as described in my Web.
Encryption of a 128 byte block
1. (Procedure 'BlockTo256', AlexUnit.pas)
128 bytes block is converted to 256 bytes block. A 256 bytes
block consists of 128 two bytes records. One byte of the
original block corresponds a record where the first byte is
the same and the second byte is XOR of the first byte with 0FFh.
So any record has the same number of 1 and 0 bits.
Such approach corresponds what I call as weighed dispersion of
bits with 0 and 1 value.
2. (Procedure 'Encryption256', AlexUnit.pas)
Input is 256 bytes block from the previous step. 2048 transpositions
are made for all 2048 bits in the block. Transpositions are
generated from the effective key.
3. (Procedure 'Encryption8', AlexUnit.pas)
Input is 256 bytes block from the previous step. 8-bit chained Alex
encryption is made as described in my Web.
Performance of the implementation on PII, 128Mhz machine is
approximately
200Kb/sec.
Well-commented Delphi 4 source code and executable are available for
free download at www.online.de/home/aernst .
Please follow the link for 1024-bit block cipher.
Regards.
Alex
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Reply-To: "Andy Jeffries" <[EMAIL PROTECTED]>
From: "Andy Jeffries" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk
Subject: [OT] alt.security.scramdisk spamming
Date: Wed, 23 Jun 1999 17:02:57 +0100
> And in my typical efficient manner a complaint has been sent. :-)
Just so you see it (spam will not be tolerated in alt.security.scramdisk):
>I look forward to receiving your confirmation of this e-mail and
>confirmation of your action.
>
>Should I not get a sasisfactory response, (for example if 'abuse' is a
>friend/synonym of i.hurkmans) then I shall follow the traceroute and
>complain higher up the chain.
>
>Andy Jeffries
>alt.security.scramdisk Proprietor
User 'i.hurkmans' is known to us because there are more complaints about
this customer. We already warned him/her that when we get more complaints
his/her account will be shutdown forever.
Thank you very much for your message, we will keep screening this user.
==============================
Met vriendelijke groet,
Abuse / Planet Internet
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 24 Jun 1999 11:30:07 +0200
Michael Scott writes:
> See ftp://ftp.compapp.dcu.ie/pub/crypto/schoof.exe. [...]
> Source code at the same site. Its not as fast as one would like [...]
Yes, I am aware of your program! It is great that something is
available, but it is not nearly enough to really solve the problem, IMO.
Ideally one would like to pick a size like 256 bits or 400 or
whatever, and run through a bunch of random curves of that size until
one (or its quadratic twist) has almost prime order, and do so in a
reasonable amount of time. It would also be nice to be able to pick
curves defined over fields of characteristic 2.
Bye,
Rob.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Converting arbitrary bit sequences into plain English texts
Date: 24 Jun 1999 09:38:01 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
Supposing we had a 16 entry lookup table reading out as:
| 0000 - no
| 0001 - yes
| 0010 - here
| 0011 - there
| 0100 - down
| 0101 - up
| 0110 - left
| 0111 - right
| 1000 - off
| 1001 - on
| 1010 - under
| 1011 - over
| 1100 - around
| 1101 - true
| 1110 - false
| 1111 - maybe
It might be a good idea to add tables for punctuation marks, such as:
000 - space
001 - comma + space
010 - exclamation mark + space
011 - question mark + space
100 - period + space
101 - semicolon + space
110 - colon + space
111 - dash + space
But it ought to be weighted towards zero so that elements are more
often separated by spaces, commas, &c., in that order. The important thing
would be supplying one of the eight punctuation-strings after every N
series of 4 bits encoded.
--
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Converting arbitrary bit sequences into plain English texts
Date: 24 Jun 1999 08:50:50 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
S.T.L. wrote:
>> Is this a sentence:
>> "Yes!"
>> And is this a sentence:
>> "No!"
>> Both are. Therefore, encode 10010110 as:
>> Yes! No! No! Yes! No! Yes! Yes! No!
>> It's English, even though it's a long string of interjections.
Mok-Kong Shen wrote:
>I think that this should work. Any thought of what arguments the
>bureaucrats could possibly have against the sort of conversions we
>discuss in this thread? I should appreciate further contributions.
Why settle for adverbs like yes or no? Let's do 4 bits at a time, and
encode them as a mix of adverbs or prepositions:
0000 - no
0001 - yes
0010 - here
0011 - there
0100 - down
0101 - up
0110 - left
0111 - right
1000 - off
1001 - on
1010 - under
1011 - over
1100 - around
1101 - true
1110 - false
1111 - maybe
--
------------------------------
From: The Electronic Zola <[EMAIL PROTECTED]>
Subject: Echelon--Rights Violation in the Information Age
Date: 24 Jun 1999 10:09:15 GMT
The Laissez Faire City Times
http://www.zolatimes.com
=================
The Front Page:
http://www.zolatimes.com/V3.25/pageone.html
==================
Jack Parsons &
The Curious Origins of the American Space Program
by The Magician
Part 17: Stab Your Demoniac Smile to My Brain!
http://www.zolatimes.com/V3.25/jpar17.html
============
Ayn Rand, Smeared Again
The Ayn Rand Cult
by Wolf DeVoon
http://www.zolatimes.com/V3.25/rand_cult.html
============
Echelon--Rights Violation in the Information Age
by Don Lobo Tiggre
http://www.zolatimes.com/V3.25/echelon.html
============
Public Sector at the Expense of Private Life
by Peter Topolewski
http://www.zolatimes.com/V3.25/public_private.html
============
Tibet: Obsessed with Money
by Richard S. Ehrlich
http://www.zolatimes.com/V3.25/tibet_obsessed.html
============
Tomorrow's Allies Today
by Sunni Maravillosa
http://www.zolatimes.com/V3.25/allies.html
============
Visit the Laissez Faire City Book Shop
http://www.zolatimes.com/SS/BookShop.html
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On an old topic of internet publication of strong crypto
Date: Thu, 24 Jun 1999 12:44:12 +0200
[EMAIL PROTECTED] wrote:
>
> The way ITAR was implemented, importation from outside UKUSACAN
> didn't matter; what mattered was whether or not strong crypto
> was available from a US-based webserver to non-UKUSACAN nationals,
> wherever they happened to reside or to be when they obtained the
> strong crypto. This is from memory, of course, and so I Could
> Be Wrong. But I think I got the main part right.
What if the author does not have the text of his paper at his site
but simply provides a link to the page on the foreign server (which
in this case has to keep the material for longer time)? For access
by the reader it makes no difference at all whether what the link
points to is stored locally or remotely, thanks to the design of
the world wide web. Should even that be objected to, he can simply
write that a paper is available overseas at www.xxx.yyy (i.e. without
the mouse click functionality). Now this last is a pure reference,
like any literature references found at the end of a scientific paper.
I doubt whether even an authority of a country under the worst
dictatorship of the modern world could forbid such references.
Any nation claiming to be democratic certainly could not afford that
kind of censorship.
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 04:11:30 -0700
Douglas A. Gwyn wrote:
> Jerry Coffin wrote:
> > I think in this case, their cracking it long before the rest of us
> > mostly had to do with their having easy access to it before the rest
> > of us did. I'm not sure when Jim started working on the problem, but
> > from what he's said, it sounds like once he started working on it, he
> > cracked it in less time than they did...
>
> Since I posted an accurate transcript of the Kryptos ciphertext
> several years ago, there has been plenty of time to work on it.
> (ACA's The Cryptogram published a slightly incomplete and slightly
> inaccurate version in the MA92 issue, which was the start of my
> quest for the complete, accurate text.)
>
> Jim took about 9 days, I think, not counting a preliminary
> glance at it earlier and his previous investment in constructing
> general cryptanalytic tools (computer and otherwise). Also not
> counting the time previously invested in learning and practicing
> cryptanalysis. (Practice is more important than you might think.)
I took four evenings: the posting by uhussy that triggered the
thread was on 6 Jun. Tom's article that I felt obliged to correct
was on 7 Jun; I corrected it that day and started working on it
again that evening (I'd looked at it briefly in 1992 and again a
couple times over the years). My first break was announced here
on the 8th, and I solved the transposition on the evening of the
10th, before my chamber music group's dress rehearsal. The NSA
team spent most of 1992 on it, finishing it (except for the same
old 97 Letters o' Doom at the end) near the end of the year,
according to Judy Emmel at NSA. Stein took 400 hours, by his
estimate.
> I think there are several other people who *could* have cracked
> Kryptos to the same degree, but didn't have the motivation or time.
Each of the systems so far would be solvable by most ACA members
with sufficient time, if armed with the knowledge that it was in
fact solvable. A positive mental attitude is a real key to this
kind of thing. The transposition would have taken me much longer
without my programs; but a '386 would have been nearly as effective
as my P2/400 for this task... assuming it ran Linux, of course.
> It would be nice if somebody would get that last piece of Kryptos
> deciphered.
Absolutely! And after that we can start on the meta-puzzle.
--
Jim Gillogly
1 Afterlithe S.R. 1999, 10:57
12.19.6.5.9, 13 Muluc 17 Zotz, First Lord of Night
------------------------------
From: "Gene Sokolov" <[EMAIL PROTECTED]>
Subject: Re: Secure broadcast
Date: Thu, 24 Jun 1999 16:17:50 +0400
Medical Electronics Lab <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'd push real hard for more bits now. A 1 GHz computer for US$500 is
> only 2 years away.
Customers are already screaming bloody murder over 10 char passwords. About
15% of support calls are "my password does not work". It's just hard to tell
0 from O and l from 1 or I. Then 60% of the customers change passwords to
something short and easy.
> > On the other hand, use of RSA would require key management &
royalties.
> > That's something to be avoided. Is there a known way to convert
> > password->symmetric key?
> > How about hashing user id + password + random number and using the
hash
> > as a key to symmetric cypher to encrypt the session key? Individually
> > encrypted session key and random number(s) would be transmitted openly
with
> > the stream.
>
> Public key isn't needed. If you have each clients private key,
> you can broadcast the session key to all clients, encrypted with
> each clients private key. Only the client with a good private key
Ok, that's what I thought too. Except I wanted that private key to be
calculated from the user password. Originally I wanted to xor a one way hash
of password + user ID + random number with the session key. But then if the
session key is encrypted instead of xored, random number would not be
needed.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 1024-bit block cipher
Date: Thu, 24 Jun 1999 12:34:33 GMT
<snip>
Some problems.
1. The block size cannot change. This would for example be a bad
thing for network trafic (imagine the 2x slowdown!).
2. 1024-bit blocks are only good for static objects (or small
objects). Consider a 'difficult' problem like RSA, ElGamma, etc...
3. You have no link in your email, but if you don't have a text
describing the algorithm your source code better be really really
clean !
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Breaking" a cipher
Date: Thu, 24 Jun 1999 12:39:52 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> Tommy, do you ever read the posts you respond to? Notice Steven's
> phrase "in a reasonable amount of time."
>
> A brute-force break is just that, a break. See Menezes.
What is reasonable? A year? A decade? No I think you are wrong. A
break is a break. Imagine a safe. You could blow the door off it
which would consitute a 'break' or you could try all combos which would
be a brute force search. When you close the safe and forget the combo
the safe is just as 'safe' as it was before that happend. Same for
block ciphers. Just because you found one DES key doesn't mean you
have them all.
NOW HERE THIS, I have broken all AES ciphers. I used this new
technique called Brute Force. This is when I try all keys and I try to
find usefull plaintext. It works against all AES ciphers, so they are
all broken. (fine print = Will take 10^38 years to complete, but for me
that's reasonable.)
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: xtea
Date: Thu, 24 Jun 1999 12:42:44 GMT
In article <[EMAIL PROTECTED]>,
Peter Gunn <[EMAIL PROTECTED]> wrote:
> a+=(((b<<4)^(b>>5))+b)^(s+k[s&3])
>
> so who is right??
The correct line is:
a += ((z << 4) ^ (z >> 5)) + (z ^ sum) + k[sum & 3]
Read the paper. The idea is to mix all ^ and + operations. Your above
line will do that so it is most likely equally as strong.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
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: 24 Jun 1999 08:54:21 -0400
In article <[EMAIL PROTECTED]>,
Christopher <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>_ But if we leak *any* information, then, clearly, our
>_ "guarantee" is something less than one might expect.
>
>Which would happen if it is known that there are definitely no sequences
>of 100 bytes (or more) in the pad, as an example.
Let's see -- out of the 8^100 possible sequences for any 100-byte
block, 8 are disallowed.
This in turn, disallows 8 of the possible decryptions. If one of
those 8 is a particularly crucial possibility, then the cryptanalyst
has gotten some significant information.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Thu, 24 Jun 1999 12:50:55 GMT
In article <7ks2ch$oab$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > 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.
Hmm well I am wrong. However my arguement still holds true. Is that
36% for the first 256 output? Why only the first 256? (It should be
the first 210 output because of the feedback). Does the 36% hold for
all multiples of 256 in the output?
> > You seem to forget that the key is the state.
>
> It isn't. Check the algorithm.
It is. Ok make a RC4 key and gimme the state :) I think not. The
state is the key. You could make your own states without the key
schedule too. So it is. Maybe I am using the wrong words, but the
privacy of the state is crucial to the security of the algorithm (kinda
like a key :) ).
> 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?
Wow a tremendous volume of it? Ok well I just propagate shit then
don't I? It's wonderful getting into silly arguments about the dumbest
things, I came to the right place then?
The RC4 state is the key to the algorithm. The key schedule only
produces the key in a way RC4 can use it. It's the only mystery in the
output. If the key does appear in the first series of outputs (which I
think you are right) then by all means shuffle some more, however if
that is true then the next output would be the key shuffled with a prob
of 36%. I don't know how to exploit that (would have to sketch a
model) but that would be a weakness.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Authentication Schemes
Date: Thu, 24 Jun 1999 13:04:18 GMT
www.IntegritySciences.com is the place to learn about SPEKE.
It's one of a few new (1990's) methods that optimally use and
protect small passwords in network authentication.
In article <7krn12$kct$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>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.
A search for SPEKE should work. If not, please let me know.
The company is actually named "Integrity Sciences".
>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.
Unfortunately, private keys for RSA and other digital signature
schemes are too long to memorize. Thus, authentication based on
digital signatures is essentially a proof that you have something,
namely your private key.
In contrast, SPEKE directly proves that you know something,
like a small password, without depending on stored user secrets,
SPEKE provides a different kind of protection than you can get
from digital signature schemes, like RSA. It can be stronger
in special cases, but in general it complements and extends
the protection provided by digital signatures.
SPEKE, EKE, SRP-3, OKE, and related methods are all special kinds
of "zero-knowledge proofs of knowledge" that can work even with
small pieces of knowledge. The usual FAQ's don't yet cover them,
but you'll find a rough description of EKE in Schneier's
Applied Cryptography and other texts.
www.IntegritySciences.com/links.html has on-line links and
references to these and all other published methods.
-- dpj
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: Wed, 23 Jun 1999 12:11:58 -0500
Robert Harley wrote:
> What I fear is that people who should know better are promoting the
> use of very special cases with lots of extra structure. It is not at
> all unlikely that one of these that is actually in use will be broken,
> then the general perception will become that elliptic curves can't be
> trusted and that will be the end of it.
Koblitz curves don't have a lot of extra structure and allow an
"easy" way to count points. The only reduction in "safety" on
these curves is an additional 1/sqrt(m) for a GF(2^m) field.
Cracking a point still grows exponentially with m.
> There are plenty of bad reasons for people to pick curves defined over
> tiny sub-fields, to use complex multiplication, etc: familiarity with
> them, holding of relevant patents, selective blindness to the danger
> they represent...
>
> There is only one good reason I can think of and that is the
> difficulty of counting the number of points on a curve. In theory it
> is polynomial time, therefore "easy".
Well *I* don't think it's so easy! But I don't have a Ph.D. in
math either.
> In practice there are some research prototypes but what is needed is a
> real-world implementation, able to quickly handle cases big enough to
> be useful, and that's out there for everyone interested to work with.
>
> It would take time, sweat and money but the main thing is that we know
> how to do it. So solve the problem!, rather than skirting around it
> with pseudo-solutions that risk killing the elliptic-curve business in
> the egg before it ever really flies.
I'm working on it :-) For the moment I'm having too much fun
playing with Linux to do the math. Maybe by fall y'all will have
some free point counting software. Lots of time and lots of
sweat (fun!) make up for money. but if you're in a hurry, I'll
be happy to get paid :-)
Patience, persistence, truth,
Dr. mike
------------------------------
** 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
******************************
