Cryptography-Digest Digest #881, Volume #10 Mon, 10 Jan 00 22:13:01 EST
Contents:
Re: "1:1 adaptive huffman compression" doesn't work ("Gary")
Re: WSO have really protected my home PC with Windows 98 ! (Liyang Hu)
Re: AES & satellite example (Nicol So)
Re: "1:1 adaptive huffman compression" doesn't work (SCOTT19U.ZIP_GUY)
Re: Simple Encryption ... ("r.e.s.")
Re: Password example encrypt/dycrypt! (Pelle Evensen)
Clearer (hopefully?) example of 1-1 problem. ("Gary")
Re: Simple Encryption ... ("Derek Potter")
Re: Simple Encryption ... ("Derek Potter")
Question about public key encryption in Z*_n (David Hopwood)
Re: Intel 810 chipset Random Number Generator (Vernon Schryver)
Re: Square root attacks against DSA? (David Hopwood)
Re: is signing a signature with RSA risky? (David Hopwood)
Re: Question about public key encryption in Z*_n (Paul Rubin)
Re: Simple Encryption ... ("r.e.s.")
----------------------------------------------------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Tue, 11 Jan 2000 00:11:02 -0000
>Non redundant original information forms the basis of all lossy compression
>algorithms.
Sorry that should be lossless.
------------------------------
From: Liyang Hu <[EMAIL PROTECTED]>
Subject: Re: WSO have really protected my home PC with Windows 98 !
Date: Mon, 10 Jan 2000 18:48:41 -0000
At Sun, 09 Jan 2000 04:29:50 GMT, in sci.crypt, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
said:
> Need to protect your compter? I did. That's why I wrote Windows
> Security Officer. It works with Windows 95 and 98 systems, and it can
> do the following for you :It's Natural Security System for Windows
> 95/98. Windows security officer is an autonomous provider of log-on and
> resource restriction security integrated with, yet independent of, the
> Windows 95/98 operating system.� It has the capay of providing
> extremely strong, secure control of who can access the personal
> computer resources; and exactly what and when they can do while they
> have access to those computer resources.� If a users time limit has
> been set and it has been reached, the computer shuts itself off and
> that user can not log-on again until their prescribed time range
> arrives. Windows security officer enables you to protect and totally
> control access to your personal computer. It offers administrative
> support for controlling which users are allowed to access your computer
> and the level of access each user may have. You can choose to restrict
> access to several Control panel applet functions, including Display,
> Network, Passwords,Printer, and System. It's not all or nothing -- for
> example: you can allow a particular user access to your wallpaper
> settings but not allow them to change your screen saver. You can also
> assign separate system profile folders to each user, providing each
> with their own custom desktop. You can additionally: disable Start menu
> items, hide your drives, disable the DOS prompt, hide desktop icons,
> and much more. You can even set an access timer (when and how long
> access will be allowed) and allow access only to programs on your
> personal computer you place on a restriction list. You can designate an
> access time period for each user. Also you have got an ability to
> prevent creating some windows on the user's desktop. Windows Security
> Officer is used by people at home,in schools, colleges, universities,
> offices and even in the US Army ! Eugene Mihailov,[EMAIL PROTECTED]
Most, if not all of the above features can be achieved with trivial
editing of the windoze registry, with exception of the timer features.
Win95/98 also comes with a policy editor which can be found on the install
CD which again gives you most of the above features, for those who are
slightly less knowledgeable about the registry.
Also, you're forgetting one thing - Windoze 95/98 is not meant to be
secure. It's pointless trying to patch up something like 95/98 to make it
secure, because you'll never succeed. (Our school has a similar system
implemented, which can be bypassed quite easily given the appropriate
know-how. Slight problem for me in that my teacher hates me now for
releasing that info...) If you want a secure OS, use WinNT, or better,
Linux.
Oh, by the way, this is considered spamming. Please stop this. This ng is
for the discussion of cryptography, not security. Please post your spam
elsewhere, eg. comp.security or something.
--
��,����`Liyang Hu/DenseBoy����,��,����http://www.nerv.cx/`����,��
| Real programmers don't bring brown-bag lunches. If the |
| vending machine doesn't sell it, they don't eat it. |
| Vending machines don't sell quiche. |
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Mon, 10 Jan 2000 19:21:00 -0500
Reply-To: see.signature
DJohn37050 wrote:
>
> I am writing a paper for 3rd AES and remember someone discussing in sci.crypt
> that a reason for having multiple AES winners were situations where hardware
> was used but was not able to be updated, as in satellites, Does anyone
> remember who said that?
Are you sure it is indeed difficult (or not possible) to update the
(hardware) encryption implementation on satellites? (I can think of a
fairly obvious yet secure solution to the problem).
--
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Mon, 10 Jan 2000 23:58:54 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John Savard)
wrote:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
>>What I don't yet understand is how one could use a 'probabilistic'
>>argument here. One has to take care of ALL possible cases (that
>>can occur) and not the most likely ones, nor even 'all but excepting
>>one case'. Or have I missed something essential?
>
>Yes, one has to take care of all cases.
>
>It's just that we would like the output from compression to be random:
>each bit in it should have a 50% probability of being a 0 or a 1, for
>the range of typical plaintext inputs.
>
>I can achieve that if I don't have to go to byte boundaries. I can
>achieve that if I'm allowed to use random padding with a length
>indicator. But trying to do it David Scott's way, that condition can
>no longer be achieved (well, I can always XOR my last byte with a
>checksum of the rest of the message to at least mask the bias...).
Yes it can be achieved but Mr JS is to lazy to look it at and he lacks
the focus to understand the problem. To pad with a random number is
just part of an encryption scheme seperate from compression. He does
not understand this point. The point is no bias is add since the method
can not add information. He also refused to acknowledge the method I
have of focusing the output is ending is different. There are many ways
tp play games with statistics. As john well knows he may be refering to
the fact that short bit string when converted to bytes tend to fill the last
byte with trailing zeros. but he seems to not understand that there are more
longer files than shorter files. Also take my latest ah2af.zip use just the
alphabet as a condition file. Compreess any text. Know chnge the last
byte to any of the 256 possibiltes. Each one of these decmpressed to
a unique text file. I think John is to dumb to test this himself so you will
have to try it on your own. John is encapable. He takes about methods
but where is his code or proof.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Mon, 10 Jan 2000 16:39:34 -0800
"Paul Koning" <[EMAIL PROTECTED]> wrote ...
: Derek Potter wrote:
: >
: > There are times when it would be cool (Ok, so
: > you now know this is going to be one of *those*
: > questions!) to be able to encrypt something not
: > so much to stop it being read by third parties
: > but to prove to the *recipient* that you have
: > some information but you aren't prepared to
: > divulge it *yet*.
:
: That's easy.
:
: Put the description in a text file, and sign it
: with a "detached signature" (as PGP calls it).
: Publish the signature. Keep the original
: file secret.
:
: At some later time you can publish the text file,
: and anyone can then verify that the previously
: published signature is valid for that file.
Wouldn't it be easier, and just as well, to simply
identify yourself in the plaintext document, then
publish a 1-way hash of the document (say with SHA1),
avoiding the use of keys altogether?
(The document, which you keep secret until ready
to reveal it, is the only one that will match the
published hash value, and it identifies you as the
author. Of course all these methods depend on the
relevant algorithm being available now & in future
-- maybe the document to be hashed should include
the source code as an addendum ;-)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Pelle Evensen <[EMAIL PROTECTED]>
Subject: Re: Password example encrypt/dycrypt!
Date: Tue, 11 Jan 2000 01:48:02 +0100
Mark van den Broek wrote:
> Hi,
>
> I'm using Borland C++Builder and i'm looking for sample program
> witch encrypt/decrypt passwords.
> Anyone got any suggestions for me??
> (p.s. I want to place a safe password procedure into my splashscreen)
Assuming it's a password, not a keyphrase/keyword, simply use a good message
digest function rather than a symmetric algorithm.
You can find the MDx, SHA-1 and others at
ftp://ftp.funet.fi/pub/crypt/hash/
Also see
http://www.usenix.org/events/usenix99/provos/provos_html/bcrypt.html
for an excellent paper on [expensive] password hashing.
/Pell
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Clearer (hopefully?) example of 1-1 problem.
Date: Tue, 11 Jan 2000 01:46:22 -0000
Compressed data can be seperated into 2 streams.
A) Data from the original uncompressed data.
B) Codes.
eg Run length encoding example
3,1,2,3,-5,7
B,A,A,A, B,A (A byte from uncompressed data, B Code)
The 1st number 3 (>0),indicates output next 3 bytes 1,2,3.
The following byte -5 (<0) indicates next byte 7 is duplicated 5 times.
decompressing to
1,2,3,7,7,7,7,7
Now take the following compressed data
3,7,7,7,-5,7
decompresses to
7,7,7,7,7,7,7,7
compresses to
-8,7
Redundancy in the original data stream of the compressed data doesn't result
in 1-1.
The same occurs if duplicate strings are added to dictionaries etc in ohter
schemes.
What about if redundancy in compressed data was used as codes.
For example in new RLE:
2+N duplicate bytes of B, followed by a byte value V indicates a run of
N*256+V of B.
so 1,2,3,4,3,3,3,1,6,7,8
uncompresses to
1,2,3,4, followed by 257 (256+1) 3's,6,7,8
this seems to compress back OK.
Unfortunately you can't compress data that has runs with length equal to the
byte value.
------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Tue, 11 Jan 2000 00:38:25 -0000
"Paul Koning" <[EMAIL PROTECTED]> wrote in message
> At some later time you can publish the text file,
> and anyone can then verify that the previously
> published signature is valid for that file.
That sounds good and I'll use it in future
when it serves the purpose.
OTOH, I have a slightly more complex agenda!
Using a ready-made encryption doesn't have
the same psychological effect on your opponent
as something which he must laboriously verify
by hand if he isn't a programmer. Or, even
more laboriously, crack. :)
Thanks to everyone who answered.
------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Tue, 11 Jan 2000 02:03:58 -0000
"r.e.s." <[EMAIL PROTECTED]> wrote
> Wouldn't it be easier, and just as well, to simply
> identify yourself in the plaintext document, then
> publish a 1-way hash of the document (say with SHA1),
> avoiding the use of keys altogether?
How big would the hash be compared with the
original document? I can see that an extra
m digits (base n) would give a maximum of
m^n -1 "wrong" de-hashes, if you see what I'm
saying, but can it be as efficient as that?
------------------------------
Date: Tue, 11 Jan 2000 02:12:28 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Question about public key encryption in Z*_n
=====BEGIN PGP SIGNED MESSAGE=====
Are there any public key encryption algorithms based on arithmetic
in the ring Z*_n, where n is composite, that do *not* require the
factorisation of n (or any equivalent information) to be known to
the private key holder?
Fiat-Shamir, and Ong-Schnorr-Shamir [*] are examples of signature
algorithms or identification protocols with this property, but
neither of them can be turned into encryption algorithms, as far
as I can see.
Blum-Blum-Shub is a stream cipher with this property, but it's not
a public key algorithm.
Alternatively, does anyone know of public key encryption algorithms
where the secret key includes a root (e.g. square root or e'th root
for gcd(e, phi(n)) = 1) of the public key, or a vector of such roots?
If it helps, the reason I'm asking is that this would help me in
constructing a public key encryption algorithm with a "forward
secrecy" property, similar to the property of perfect forward
secrecy for key agreement protocols. (I.e. a compromise of the
private key would not allow messages sent before a given time to
be decrypted.)
[*] Ong-Schnorr-Shamir is insecure, but that doesn't matter; even
an algorithm that is insecure as it stands might provide a
useful starting point.
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHqQ1TkCAxeYt5gVAQGuPAf/eyx7Gu0h/EweNdBMViQIzFTlPDChR+WR
NXvmbwGFKyr1DHyApdoCjlm/p1AJAYdg55fhBAcdkoYYqoZveb1mruAVYdSv0wpp
o1YqukLZqIbc91aWh0nna3aLNip52HE8RnCRG5MqkLBcOD8RoyNsPB9gb657udAX
8YvlxIJ6cUnMhpv/kjxZjAPrSBBIsLUgddUCG8LBaRk9DVi9eOUeiklcwfaOc8f9
BJBaICX5cXLF1Qr3kKxXER+bNCAJsUN1EmvKVmKN8bE0yNMJakuABxuJNbHLP0X8
b9OvG3sbROdg7SrnI3iS7Cjk48mena9BvZM+zSL9FEJJlYES7oQ6Fw==
=tNBM
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 10 Jan 2000 12:48:11 -0700
In article <[EMAIL PROTECTED]>,
James Felling <[EMAIL PROTECTED]> wrote:
>My personal belief is as follows. The RNG generates a bit at fixed
> intervals , if multiple apps are accessing it at the same time then they
> are each getting the same value. If this is the case, then there are
> issues with more than 1 thread accessing it at the same time. (i.e. if
> you are doing a montecarlo method of finding area, with thread 1 picking
> the x coord, and thread 2 the y coord, you will get an extreme bias
> toward values being on the line x=y.
That's an interesting idea almost makes the difference between multiple
threads and multiple applications relevant. However, it seems too
subtle to me. Depending on the operating system and the application,
a real "multi-threaded application" might use multiple processes instead of
what most people now (but not always) consider threads.
> Ny guess is that it is indeed
> intended as an entropy source for driving a /dev/random type randomness
> pool.
Yes, the warning is the standard Intel and other hardware vendor clue
intended to say "you need to do the usual operating system stuff with this
thing." I think I've seen those same beware-of-multi-threaded-applications
words in other Intel publications. No programmer who has (or can) actually
dealt with hardware much would infer alleged the doom and incompetence
from the words, even if they think the device is a crock for other reasons.
>>"Trevor Jackson, III" wrote:
>> ...
>> $100 says they didn't think about it at all. had they considered the
>> usage of the device the interface would look considerably different. I
>> suspect some engineer was handed a feature to implement and all the effort
>> went into the quality of the data and none went into the quality of the
>> interface. N.b., the interface would logically include the hardware device
>> registers and any software needed to drive it.
In the past, it was often true that hardware people knew nothing about
code. Today, they're likely to be running Linux or FreeBSD at home, and
writing simulations of their hardware in C and other languages at work.
No one, not even those criticizing Intel, has said that the interface is
in any way defective, wrong, or in need of improvement, other than that
it would be nice to have a way to detect the device, and it's not clear
to me that there is no way to detect the 801. Exactly what is wrong with
the interface? All that I can see is that the Intel tech-writers (not
designers) inflamed some netnews commentators who appear to have no
experience writing code that talks to hardware.
The appropriate emphasis is on the quality of the data, but it's not clear
to me that the data is very wonderfully random. In other words, what
evidence there is contradicts Mr. Jackson's claim about where the effort
went.
People who are computer hardware or software designers and developers know
that it would be silly for Intel to "include ... any software needed to
drive it." Even in the restricted, utterly provincial Microsoft world
that notion is silly, because the internals of Windows and NT change, and
the majority of the real code would involve operating system hassles.
Intel could publish prototype code in what they've been calling for 20+
years an "App Note". However, no one who might actually use a device with
as utterly trivial an interface as this would care about it. For that
matter, what professional programmer has ever been able to use an Intel
App Note as more than a general hint about what might work?
Any hardware registers that cannot be accessed more often than once a main
CPU cycle plus a small number of wait states will not be mapped into the
I/O space of applications. As everyone with a clue knows, if your code
tries to do an "IN" instruction to fetch the value (or MOV if the registers
are memory mapped) of such slow, shared hardware, it will instead be
trapped to a driver of some kind that will simulate the results of the
instruction.
In other words, the clue challenged might well write code that they think
fetches random values directly, but even in Windows they'll be taking to
system code that can do /dev/random stuff (perhaps not in Windows 98 S.E.,
but eventually).
Vernon Schryver [EMAIL PROTECTED]
------------------------------
Date: Sat, 08 Jan 2000 00:44:57 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Square root attacks against DSA?
=====BEGIN PGP SIGNED MESSAGE=====
I wrote:
[...]
> 6. Construct a table with entries (j, g^j mod p mod q), for
> j := 0..m-1. Sort this table by second component.
I forgot to define m (and accidentally used the same letter as for
the messages m_i).
m should be the next integer above sqrt(q).
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHaITjkCAxeYt5gVAQErLAf/di3G4S1nyrdrd6yg7ddEjPb8iibz+QHY
4vlSDOzSH9uTpITgYFzUvEbT+eJXci3lfiRdT8Jo/jgok/v06kd73PLcTTb+64Dz
jVdTPXX6cAvRVG01bBpcB+mwmA8i4k1GlbqAOc1CdkwmSkQtJQTryznK0a92JRli
cedxcf4PUvCQ1thEnIry6GfZpLxmMtqUvHxjff1lPLNF3YkshUXmJ0mPOxbJ4LyT
oYqUEnDHicgmvo10MMv2d4p2nCQeCH4t8btTlCUulZiSYMWjr/TlZKXAHprqWpxS
/DkI80HiBIYMb5a5kipKFddxRcLVoOdxUolHPbDF58JoymwxApoLBQ==
=UyGf
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 08 Jan 2000 01:15:37 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: is signing a signature with RSA risky?
=====BEGIN PGP SIGNED MESSAGE=====
Tim Tyler wrote:
>
> Pascal Scheffers <[EMAIL PROTECTED]> wrote:
>
> : With RSA, there is the risk that if you encrypt before signing the
> : other can fake a message. This is described on p473 of Applied
> : Cryptography 2nd.Ed.
>
> BS says there that: "It makes sense to sign a message before encrypting
> it".
>
> Any users who follow this advice should be aware that if the signature may
> be publicly validated, this can provide a concrete halting criterion -
> which allows keys to be automatically rejected on every signed message
> sent.
That's irrelevant in practice if the key space of the encryption is
large enough. Typical messages will always have sufficient redundancy to
be automatically verified or rejected.
> I believe you should normally sign outside at least one layer of strong
> encryption, because of this (with different key bits being used on "either
> side" of the signature).
This is adding significant complexity to your protocol, for little or no
security gain, IMHO.
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHaPeTkCAxeYt5gVAQEtHwf/VpRoUQIe/6Ojqd265QDZOJ9QeIqoSuPi
021Lu9XmP4p2odabnELly18N7xZ1PupmlXgcGKgoIOG0DQqWdSEnwuFe3pcQFwoU
He3IUXOHLY57LHpKEAjbhdz1EepfXWjGpevJz0vtjKJKCtGFRZ715BrE23mSwIuv
QjpGLtmWGmU+/TwxzKWASrT5VNRozFmgjXqIG1v6+dEJQqppftX8jNiUl4QQzOSi
funzpRJdPZqwNk3nl0wXHfRSlpsI+dh6d73gHMDw0RWO5r95bTiuGPzzsA+65Ycm
GPOTkinCx19jw7i/AWqNAsOeFBnb+0cm1teieBKp9uLS8kcC902iXA==
=Pv6E
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Question about public key encryption in Z*_n
Date: 11 Jan 2000 02:36:49 GMT
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> wrote:
>Are there any public key encryption algorithms based on arithmetic
>in the ring Z*_n, where n is composite, that do *not* require the
>factorisation of n (or any equivalent information) to be known to
>the private key holder?
Something wrong with Diffie-Hellman/El-Gamal? The security of
Diffie-Hellman over Z*_n for composite n was analyzed by Schmuel, I
think.
>If it helps, the reason I'm asking is that this would help me in
>constructing a public key encryption algorithm with a "forward
>secrecy" property, similar to the property of perfect forward
>secrecy for key agreement protocols. (I.e. a compromise of the
>private key would not allow messages sent before a given time to
>be decrypted.)
Again, why not use ordinary Diffie-Hellman over your favorite
commutative group (Z_p, an elliptic curve, or whatever)? I think
of forward secrecy as automatically meaning key agreement rather
than public key ("public key" => existence of a persistent secret key).
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Mon, 10 Jan 2000 18:42:33 -0800
===============begin SHA1===================
"Derek Potter" <[EMAIL PROTECTED]> wrote ...
:
: "r.e.s." <[EMAIL PROTECTED]> wrote
: > Wouldn't it be easier, and just as well, to simply
: > identify yourself in the plaintext document, then
: > publish a 1-way hash of the document (say with SHA1),
: > avoiding the use of keys altogether?
:
: How big would the hash be compared with the
: original document? I can see that an extra
: m digits (base n) would give a maximum of
: m^n -1 "wrong" de-hashes, if you see what I'm
: saying, but can it be as efficient as that?
SHA1 hashes "any" input document into 20 bytes of output
(illustrated below as 5 blocks of 4 hex chars each, with
each hex char represented by 2 ascii chars, and blocks
separated by a space, for a total of 44 characters.)
I don't know the practical limitations on just how large
the input can be without encountering problems, but it's
probably huge. Maybe one of the local gurus will answer
that for us?
(I've only been playing with SHA1 a bit. The hash for
the message you're now reading, between and including the
44-character begin & end lines, appears below.)
r.e.s.
[EMAIL PROTECTED]
================end SHA1====================
6B67A22E DDC8C5A2 104D33D5 DB4E358C 533791B4
------------------------------
** 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
******************************
