Cryptography-Digest Digest #55, Volume #12 Sun, 18 Jun 00 11:13:00 EDT
Contents:
Re: Weight of Digital Signatures ("Lyalc")
Re: Flattening of frequency distributions (Mok-Kong Shen)
Re: Evidence Eliminator Dis-Information Center (Dave Howe)
Re: Weight of Digital Signatures (Mok-Kong Shen)
Re: Comments requested: One way function blast() (Simon Johnson)
test prog !! ([EMAIL PROTECTED])
Encryption routine anyone? ("Jules and Rich")
Re: AWFUL PUN (was: Why the golden ratio?) (Guy Macon)
Re: Observer 4/6/2000: "Your privacy ends here" ("Darren Rhodes")
Re: I Will Make ANY Software for Anybody (Guy Macon)
Re: Comments requested: One way function blast() (Andru Luvisi)
Re: MD5 Expansion (tomstd)
Re: Encryption routine anyone? (tomstd)
Re: Weight of Digital Signatures (Tom McCune)
Re: AWFUL PUN (was: Why the golden ratio?) ("G. A. Edgar")
new books on conspiracy ("Alistair Krieg")
Re: Flattening of frequency distributions ("G. Orme")
Re: Encoding 56 bit data ---HELP--- (Nicol So)
Private key encryption that maintain length of plain text? ("World Online")
Re: Private key encryption that maintain length of plain text? (tomstd)
Re: MDS theory? (tomstd)
----------------------------------------------------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Sun, 18 Jun 2000 18:41:56 +1000
In general, a lay-persons analysis of electronic signature legislation based
on the UNCITRAL Model Law shows they have 5 main components; the electronic
signature
i) must identity the individual
ii) demonstrate the willingness (or acceptance) of the individual to be
bound by the content of the signed data and it's consequences
iii) allow for verification of the signature, at time of receipt and
subsequently
iv) be under the sole control of the individual identified.
v) be apprpropraite or approved for the purpose to which the signature is
put, according to standards prevalent at the time
For specifics, read the UNCITRAL Model Law - the American Bar site has some
references and critiques
Some states/countries have their own interpretations, often including
various amounts of prescriptive and or interpretative phrasing. Utah,
Germany, and Australia cover most of the spectrum on this aspect.
The scenarios described below is unlikely to be an electronic signature -
indeed the majority of PKI solutions in the marketplace fail on at least 2
of the above criteria.
Intelligent promoters of electronic signature solutions would realise that
the time to market, coupled with confidence longevity by adopters will mean
that setting higher security thresholds at the start will pay off will
lower, ongoing support/replacement/upgrade overheads for everyone in the
marketplace.
Quiz - in which commercial environment has electronic signatures been used
for over a decade, with high confidence and low fraud by all parties?
Lyal
John Savard wrote in message <[EMAIL PROTECTED]>...
>On Sat, 17 Jun 2000 19:52:13 GMT, Greg <[EMAIL PROTECTED]> wrote,
>in part:
>
>> WASHINGTON, June 16 -- The Senate voted unanimously
>> today to approve a bill that catapults electronic
>> commerce to a new level by allowing consumers and
>> businesses to sign contracts online and know that
>> their e-signature is just as binding as one in ink.
>
>> The bill, which passed 87 to 0, has already been
>> approved by the House and now goes to President
>> Clinton, who said today that he would sign it
>> into law.
>
>>Off topic a bit, but worth a mention. Kudos to all who have had any
>>hand in helping the government see the light (finally)...
>
>I really don't know if this is good news.
>
>A law that makes a digital signature "just as binding as one in ink",
>when it is so much easier to break into someone's house and read their
>hard drive than forge their signature perfectly makes ordinary people
>much more vulnerable to forgery than before.
>
>If my private keys, which I use to sign things, exist only in
>encrypted form on my computer - so that every time I sign something
>digitally, I have to enter my pass phrase - then I have the level of
>control needed.
>
>Right now, though, a secure credit card transaction is merely one
>encrypted by means of the vendor's public key: the person at the other
>end is only transmitting a credit card number. What if the law is so
>worded that this is considered a "digital signature", although no
>private key on the part of the "signing" party is involved? That is,
>what if a stolen credit card number now binds its legitimate owner as
>strongly as a signature in pen and ink? It's entirely possible the
>law, if it fails to discuss technical issues, could be so worded as to
>create such a situation.
>
>Even if that doesn't happen, it is almost certain that people will be
>making signatures legally "just as binding as one in ink" using
>whatever insecure software is provided by their bank or stockbroker or
>utility company...with little real choice in the matter. Hence, this
>law could lead to so many people being victimized by insecure systems
>- _as to create a clamor for a secure system, designed by the NSA,
>with built in key escrow_ as a *preferable* alternative!
>
>John Savard (teneerf <-)
>http://www.ecn.ab.ca/~jsavard/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Flattening of frequency distributions
Date: Sun, 18 Jun 2000 11:01:23 +0200
wtshaw wrote:
> Using the same technique, it seems usefull to even produce a deceptive
> profile as a defence.
You raised a very interesting point. A good cipher will output an
(almost) entirely flat distribution. Thus the way of doing post-processing
to obtain a contrived arbitrary frequency distribution must be through
extending the length of the ciphertext. For illustration, consider the
output of a cipher to be in units of hex digits. Then the homophone
technique can be applied to map each hex to a byte. It is apparent
that there is sufficient possibility here to obtain certain desired
frequency distributions. Since analysis in classical cryptography
depends heavily on frequency distributions, I wonder whether there
had not been applications of such deception techniques, though I
don't remember to have seen any descriptions in the old books.
M. K. Shen
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To:
alt.privacy,alt.privacy.anon-server,alt.security.pgp,comp.security.firewalls
Subject: Re: Evidence Eliminator Dis-Information Center
Date: Sun, 18 Jun 2000 10:21:48 +0100
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Sat, 17 Jun 2000 13:29:19
-0700]), tomstd <[EMAIL PROTECTED]> said :
>Then why do formats write ascii 'v' to each sector of the disk?
>(when I formated a floppy).
Because the routines for formatting floppies (low level formats) are
different from those used to format hard drives (high level formats).
it *is* possible to do a low-level reformat of a hd, but often the
tracks laid down are pretty sloppy and need redoing every few months;
in any case, it takes either a special utility or (in most cases) dos
DEBUG and a (g)o to the right routine.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Sun, 18 Jun 2000 11:53:43 +0200
John Savard wrote:
> I really don't know if this is good news.
>
> A law that makes a digital signature "just as binding as one in ink",
> when it is so much easier to break into someone's house and read their
> hard drive than forge their signature perfectly makes ordinary people
> much more vulnerable to forgery than before.
But if it is not equally binding, it, by definition, wouldn't be a
signature. So how should one go about, if one wants to reap the
benefits offered by electronics and decrease the frequency of
signing in ink?
M. K. Shen
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Comments requested: One way function blast()
Date: Sun, 18 Jun 2000 09:42:17 GMT
I don't know wether this has already been said (Deja seem's to be a bit
wonky) but a hash of 32-bit is too small.
A colliding message could be found in a few minutes on a pentium
machine, using the birthday attack........
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: test prog !!
Date: Sun, 18 Jun 2000 10:16:49 GMT
hello
i seek a program who plot to the screen
x,y point number of prng out
color increment if a point is plotted
twice
some comments for this source prog
http://www.visto.com/guest/fred9731
lfsrcrypt.c
polynomials are good or not
help give me a method for
find a good poly
primitive poly = maxi period
but it is a good poly ???
i seek also maurers test prog
in c if possible or executable
msdos !!!
bye bye !!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Jules and Rich" <[EMAIL PROTECTED]>
Subject: Encryption routine anyone?
Date: Sun, 18 Jun 2000 11:32:37 +0100
Help please!
Does anyone have (or know where I can find) example(s) of an
encryption routine in assembly? I need one for part of a college
assignment. Ideally it would be based on an 8-12 char
encryption key.
Any help gratefully received!
Julie
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: AWFUL PUN (was: Why the golden ratio?)
Date: 18 Jun 2000 06:52:35 EDT
Michael L. Siemon wrote:
>
>
>In article <8ihjf8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Dave Seaman) wrote:
>
>+ In article <[EMAIL PROTECTED]>,
>+ John Savard <[EMAIL PROTECTED]> wrote:
>+ >>Well, if that's the case, then there's a mathematician who went around
>+ >>telling us that Ramanujan and his equations were really something
>+ >>quite remarkable. I suppose he owes all of us an ... _apology_.
>+
>+ >Nobody commented on this awful pun? (As the mathematician in question
>+ >is deceased, I suppose he can't do anything but rest on his laurels.)
>+
>+ I can hard(l)y stan(d) it.
>
>Are you looking for a laurel, for this utterance?
I was thinking a Hardy would be a better choice.
------------------------------
From: "Darren Rhodes" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Fri, 16 Jun 2000 12:03:48 +0100
I tried to access the Shayler web site listed below but could not. This was
said to be due to an HTTP error 403 - Forbidden.
Has anyone had a similar experience?
Is this due to my ISP Globalnet?
Darren.
Anarchist Lemming <[EMAIL PROTECTED]> wrote in message
news:8hh0dl$h4f$[EMAIL PROTECTED]...
> You mean David Shayler. He has a website at www.shayler.com.
> I've left a message on his guestbook and emailed him about the RIP Bill
but
> I expect he gets loads of email so he might not reply.
>
>
> Lemming
> www.hellnet.org.uk
>
>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: I Will Make ANY Software for Anybody
Date: 18 Jun 2000 07:01:44 EDT
> I manage a VAST number of programmers with a wide spectrum of skills covering
> virtually all aspects of software development. I can help you develop any
> software that you can imagine at an extremely low cost. If you have an idea of
> software you would like to develop or are currently developing, I can help you
> develop it with extreme efficiency of both time and money (No project is too
> small, or too large to develop). Anything from state of the art web sites, to
> handling part of your workflow (orders), to developing GPS software. . .
> anything can be developed in a short period of time at an extremely low cost.
>
> Please email me with your ideas/projects, and I will shortly respond with a
> time frame and a price quote for the development of your software.
I have a simple BASIC program I want ported to C++....
START:
IF
this program has an infinite loop in it
THEN
END
ELSE
GOTO START
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Comments requested: One way function blast()
Date: 18 Jun 2000 04:22:37 -0700
Simon Johnson <[EMAIL PROTECTED]> writes:
> I don't know wether this has already been said (Deja seem's to be a bit
> wonky) but a hash of 32-bit is too small.
>
> A colliding message could be found in a few minutes on a pentium
> machine, using the birthday attack........
I know. I had intended to use it as a component in a cipher, but
I have given up on it as hopelessly broken. I just can't get good
statistics out of any variation. I suspect it just has too much
compression, resulting in too much inevitable linearity. Duno.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
Subject: Re: MD5 Expansion
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 04:35:08 -0700
>Sorry, my news server sucks, so I'm using Deja.
>Anyway, Your logic evades me. Just because we can
>find 2 messages that have the same MD5 hash
>doesn't mean those two messages, run through the
>linear function, will have the same 2nd hash!
>That is where I see the security of using 2
>hashes: Even when a collision is found in MD5, it
>will rarely have a collision in the 2nd hash
>because one bit change in the message will
>(supposed to) change on average half the bits of
>the hash. The attacker is back to searching...
>
No you missed it. You said you wanted to calculate one hash,
then perform some permutation of the (presumably) hash and make
another hash of it. This looks like
A = H(m)
B = H(L(A))
If for two messages the A values are equal the B value must be
equal as well. Even if you did
A = H(m)
B = H(L(A) || m)
I can break it faster then bruteforce and the bday paradox.
It's not a good idea.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Encryption routine anyone?
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 04:37:25 -0700
"Jules and Rich" <[EMAIL PROTECTED]> wrote:
>Help please!
>
>Does anyone have (or know where I can find) example(s) of an
>encryption routine in assembly? I need one for part of a college
>assignment. Ideally it would be based on an 8-12 char
>encryption key.
>
>Any help gratefully received!
What are the design considerations? I have tiny fast RC5 code,
and I know there are tinyIDEA and others floating around.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Sun, 18 Jun 2000 12:09:32 GMT
In article <01bfd8ad$f9f4e020$0100a8c0@downstairs>, "Michael Brown"
<[EMAIL PROTECTED]> wrote:
>Tom McCune <[EMAIL PROTECTED]> wrote in article
><pmR25.10526$[EMAIL PROTECTED]>...
>> Tom, please explain what you mean about RSA not being secure. I can't
>> think of a more secure signature than a 2048 bit RSA key using either
>> RIPEMD-160 or SHA1 for the hash.
>I'm not Tom, but I may be able to help.
>See my postings on "Logical attack on RSA". It's not proven, but its
>looking that way.
Thanks Michael,
Tom's comment seemed a lot more definite than referring to this possibility.
I wish you all the best in your attempt here, but hope that instead your
efforts support how strong RSA really is. :-)
Of course, if it isn't we are all better off knowing that.
Tom McCune
My PGP Page & FAQ:
http://www.McCune.cc/PGP.htm
------------------------------
From: "G. A. Edgar" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: AWFUL PUN (was: Why the golden ratio?)
Date: Sun, 18 Jun 2000 08:15:28 -0400
>> it is due to Srinavasa Ramanujan...
>
> >Oh, dear: that should be Srinivasa Ramanujan.
There are no vowels in Sanscrit, so we cannot criticize you for this.
--
Gerald A. Edgar [EMAIL PROTECTED]
------------------------------
From: "Alistair Krieg" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,uk.telecom
Subject: new books on conspiracy
Date: Sun, 18 Jun 2000 13:18:19 GMT
This is a one-time message, it will not be repeated.
There are two new books out. One Identifies the conspirators; the other
tells how and why they are successful.
Go to: http://www.kriegbooks.com
Thanks A. H. Krieg the Author
------------------------------
From: "G. Orme" <[EMAIL PROTECTED]>
Subject: Re: Flattening of frequency distributions
Date: Sun, 18 Jun 2000 13:53:30 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Exploiting knowledge of frequency distributions of plaintexts
> is one of the major tools of analysts in classical cryptology.
> Even if some modern ciphers are believed by many to be strong
> enough for direct encryption of natural language messages, I
> suppose it can nontheless be justifiable to do preprocessing
> to flatten the frequency distributions of single letters and
> n-grams, if one is conservative in matters of security.
>
> As far as I am aware, employing polyalphabetic substitution
> (on hexs or bytes) with a large substitution table and a long
> key or a dynamically generated random sequence as key flattens
> the frequency distributions to some significant extents.
> Another device that seems to be useful is bit rotations (by
> random amounts) done on group of bits (computer words).
>
> I should very much appreciate suggestions of other and
> better methods of flattening frequency distributions as
> well as discussions about them.
>
> M. K. Shen
G. One possibility is to break up words as follows. You count each letter
and space from left to right throughout the text so each has a number, this
number being the number of spaces from the start of the text. of course this
number is unique to each letter or space. Then you assign each letter a
number bigger than the number of characters in the text. Say then A you call
1000. It might be written as 1000 24 35 45 57.... where each number tells
you where an A appears in the text. You do the same for each letter. This
seems to hide the distribution.
>
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Encoding 56 bit data ---HELP---
Date: Sun, 18 Jun 2000 10:09:56 -0400
Reply-To: see.signature
Sundial Services wrote:
>
> [Discussion about discernible statistical characteristics of
> PKZIP'ed files and success in breaking the stream cipher of PKZIP,
> deleted]
>
> So... WHAT IF the attacker did "brute force the plaintext?"
You quoted a trimmed version of my message with some context information
left out. I'm not sure if your question is directed at me or the group
in general, but I will clarify my point.
In my previous message, the focus was whether there's any point in
making the key longer than the message in a *public-key* cipher. Andrew
Bortz wrote that because of the adversary's ability to perform trial
encryption, making the key longer than the message would simply force
the adversary to search the message space (instead of the key space). I
cautioned that there's an implicit assumption in the reasoning.
Generally speaking, exhaustive search of the key search is not the best
attack against known public-key ciphers. For that reason, "key size =
message size" is generally not the crossover point where exhasutive
search of the message space becomes easier than the best key-recovery
attacks.
There are other factors one needs to be careful about, such as
low-entropy messages, short block sizes (relative to exhaustive search)
etc. They can and need to be dealt with, but I'm not going to talk about
them here.
> > > the data would simply force an attacker to brute force the
> > >plaintext.
> >
> > You seem to have an implicit assumption that no attack better than
> > exhaustive search is available, which is not generally true (or
> > generally not true).
> >
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "World Online" <[EMAIL PROTECTED]>
Subject: Private key encryption that maintain length of plain text?
Date: Sun, 18 Jun 2000 14:20:50 GMT
Hi
I am pretty new to asymetric encryption, so it may be a stupid question!
I have a special application in mind where I operate with very small (in
byte length) plain text documents and I would also like to keep the
encrypted document as small as possible. I have made some test applications
with RSA and I see that the encrypted documents (private key) with a modulus
size of 512 bits get to become twice the size of the plain text document
(increase with bigger modulus sizes).
Are there any public key encryption algorithems that maintain the same size
encrypted as decrypted (as with most block cifers).
The plain text document will be known, and also the public key will be
known. Then a test will see if the encrypted version match the plain text
version.
Best regards
Benny Nissen
------------------------------
Subject: Re: Private key encryption that maintain length of plain text?
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 07:33:57 -0700
"World Online" <[EMAIL PROTECTED]> wrote:
>Hi
>
>I am pretty new to asymetric encryption, so it may be a stupid
question!
>I have a special application in mind where I operate with very
small (in
>byte length) plain text documents and I would also like to keep
the
>encrypted document as small as possible. I have made some test
applications
>with RSA and I see that the encrypted documents (private key)
with a modulus
>size of 512 bits get to become twice the size of the plain text
document
>(increase with bigger modulus sizes).
>
>Are there any public key encryption algorithems that maintain
the same size
>encrypted as decrypted (as with most block cifers).
>
>The plain text document will be known, and also the public key
will be
>known. Then a test will see if the encrypted version match the
plain text
>version.
Not really (from your perspective). Most asymmetric methods are
based on number theoretic problems (factoring, discrete
logarithm) and are only secure if large numbers (fields, curves,
etc..) are used.
In reality however, with a 1024-bit RSA key (for example) your
plaintext and ciphertext are always 1024 bits, no more no less.
So in this sense it never expands.
I can see if you want to encrypt only 20 bytes with a 1024-bit
key this could be viewed as an expansion but theoretically it
isn't.
IOW you can't get small block sizes using current methods
without sacrificing security.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: MDS theory?
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 08:04:22 -0700
"Paulo S. L. M. Barreto" <[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> I can't get to [Vincent Rijmen's] site because of his anti-ms
ego trip. So if
>> anyone has direct links to his papers I would appreciate it.
>
>Why don't you send him mail and request that he grant access to
people
>visiting via msie? <mailto:[EMAIL PROTECTED]>
>
>> What I got from Vaudenays analysis of multipermutations is
that
>> a (r + n)-multipermutation is a permutation from Zr to Zn (Z
is
>> a alphabet) such that any two pairs in the form (x, f(x))
cannot
>> collide in r positions.
>>
>> Where the pair (x, f(x)) is the input and output. So if you
had
>> a 4x4 code each would be eight bytes. If you had a (4 + 4)-
>> Multipermutation (is that possible?) that means any two pairs
>> will not share (collide) in four bytes (in/output).
>
>I don't think I understand it, but if all you can do with that
>construction is that any two (distinct) pairs won't collide in
*four*
>bytes, then the diffusion is clearly inferior to an MDS code
(where any
>two distinct pairs won't collide in at least *five* bytes).
This is
>because a difference in the first four bytes (i.e. in x) will
affect
>only three bytes of f(x), not all four of them. Maybe I'm
missing
>something here, though.
No it's me. I am still a bit shaky on the whole thing.
In Twofish they state that pairs such as
(x, f(x)) which could be considered as a vector with 8
components (bytes). They say that no two pairs can collide in
anything more then 3 bytes (such that the distance is 5). This
means that both the input and output must be different by at
least one byte...
For example if
a = (x, f(x)) = [ [ a, b, c, d ], [ e, f, g, h ] ]
and
b = (y, f(y)) = [ [ A, B, C, D ], [ E, F, G, H ] ]
For y != x
Then *at most* three pairs like (a, A), (b, B), etc.. may be
equal.
Is this how it is?
I still want to learn more about the construction of these
linear transforms and about the terminology revolving around
multipermutaions...
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
