Cryptography-Digest Digest #632, Volume #9 Tue, 1 Jun 99 16:13:03 EDT
Contents:
Re: Oriental Language Based Enryption (Jerry Coffin)
Re: RSA <> std.encryption (Jerry Coffin)
Re: OTP Problems ([EMAIL PROTECTED])
Re: Using symmetric encryption for hashing (Paul Onions)
Re: Viability of encrypted flash cards? ([EMAIL PROTECTED])
Obscure Code ("Oliver J. Hanau")
Re: SHA-1 output random? (Florian Weimer)
Question about Cryptography/Encryption... (Nicholas Zacca)
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
Re: 8Bit encryption code. Just try and break it. (Raymond Calande)
Re: Using symmetric encryption for hashing (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Oriental Language Based Enryption
Date: Tue, 1 Jun 1999 10:27:37 -0600
In article <[EMAIL PROTECTED]>, mok-
[EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> >
>
> > There's another effect to take into account here though: what would
> > start out as, say, 5 to 10 characters in English will often translate
> > to only 1 or 2 characters in Chinese. IOW, you get a compression of
> > something like (at a guess) 5:1 characters in translating from English
> > to Chinese. Since each character is (roughly) twice as large in
> > Chinese, you're getting something like 2.5:1 compression in terms of
> > bytes.
>
> Though on the one hand I intuitively believe the existence of
> certain 'compression', I am afraid that a numerical calculation of
> that may be subject to debate.
Oh, it undoubtedly is -- I didn't intend to convey the idea that it
was done with any great precision. My entire basis was three Korean
patents, of which I have English translations. The numbers above were
based on a quick comparison of file sizes, but I openly state that my
sample is small enough that I'm hard put to even guess at a level of
statistical significance, beyond "fairly low" -- we're only talking
about a few kilobytes of text altogether, and there are (at least)
Chinese, Japanese and Korean to contend with, and a couple of
different character sets in each to boot. In addition, Vietnamese has
what I believe is a completely unrelated set of characters as well.
IOW, without narrowing the target down considerably, it's impossible
to give any great precision.
At the same time, it's about the only number I have handy, so I
decided to throw it in, to at least get an idea of how it affected
things. As far as I can see, it doesn't have enough effect on the
overall outcome that it probably matters anyway -- if you assume
anything from no compression effect at all, anywhere up to (say) 20:1
compression, it looks to me like the conclusion is still pretty much
the same -- for a brute-force attack, it's still pretty trivial to
collect enough text, and for something like differential cryptanalysis
or linear cryptanalysis, it has no effect.
Of course, running English through something like Huffman compression
before you encrypt is also well known, and doing so is likely to
minimize such differences...
[ ... ]
> I like to add here something to a point which I only touched upon
> previously, namely the opponent's resources of language expertise.
> Especially in speech communiction, a comparatively seldom language
> spoken in a special (minority) dialect could in some sense compete
> well with the services rendered by encryption in written communication,
> particularly if the messages need only be unavailabe to the opponent
> for a relatively short time. I remember that Kahn's book has an
> example of that from WWII. Is this being praticed in modern times?
It's hard to guess, but probably to at least some extent. Ultimately,
even though security through obscurity gets slammed every chance we
get, sufficient obscurity CAN add enough of a delay to be useful under
some circumstances.
Probably the best example I know of is from the Korean conflict rather
than WWII though -- a guy got caught behind enemy lines, and wanted to
call in some firing coordinates. He didn't want to just say something
like "200 meters northwest", but he happened to be an _extremely_ avid
golfer -- to the point of having memorized directions and distances of
all the holes at a number of golf courses. To give directions, he
simply gave them something like "hole 4 at Torrey Pines" and they
looked up the distance and direction of that hole. IIRC, they also
gave him directions to get free in the same fashion.
In both cases, the delay needed was on the order of seconds or
minutes. Obviously after a shot came in, the enemy knew what
coordinates he'd given them. In escaping, they probably had a little
longer between his being given a direction and arriving at the
destination, but apparently the delay was still long enough.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: RSA <> std.encryption
Date: Tue, 1 Jun 1999 10:27:47 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Is there any way to compare the security of RSA and standard encryption?
Without knowing the key-length used with RSA, and the specific
"standard encryption" you're referring to (DES?), no, it's not
possible. It's certainly possible to give an idea of about the key
length needed to make RSA about as difficult to break as DES is, but
I'm not sure whether that's what you're asking or not. Given that DES
can be broken fairly quickly and easily at the present time, I'm also
a bit uncertain as to what, if anything, this would accomplish.
------------------------------
Date: Tue, 01 Jun 1999 02:33:10 -0400
From: [EMAIL PROTECTED]
Subject: Re: OTP Problems
Matthias Bruestle wrote:
>
> Mahlzeit
>
> [EMAIL PROTECTED] wrote:
> > A case in point. I'm pretty impressed with the specs of the iButton
> > device. The current (initial) version stores about 2^10 bits in a
> > physical device that is reasonably easy to deal with, yet is probably
> > secure against anything less than "national technical means". Certainly
>
> I doubt it can withstand a skillfull student. (See papers of Kuhn&Anderson)
Can you provide a pointer to a repository containing the referenced
papers?
------------------------------
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: Using symmetric encryption for hashing
Date: Tue, 01 Jun 1999 18:57:50 +0000
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Paul Onions
><[EMAIL PROTECTED]> wrote:
> >It's not one-way: given a hash output, simply "invent" the other ciphertext
> >bits and decrypt. This gives a preimage of the output.
>
> I am not sure what you mean by invent here since I don't think the
> other bits are that easy to find with out the original input text. If you
> think about it my scott19u contest is based on this being hard since in the
> contest the "key" is given only a few bytes of the encrypted output file
> need to be found.
We don't need to find the original ciphertext bits since there is no need
to try and recover the original message.
All we want to do is generate a message, any message, that will hash to a
given output. If we can do this then it shows that the proposed hash
function is not one-way.
You could replace "invent" by "generate at random".
> >It's not collision-resistant: as above, but "invent" two lots of ciphertext
> >bits and decrypt each. This gives two preimages with the same output.
>
> This is true but it is highly unlike that either preimage would be ascii
> or anything meaningful.
Irrelevent. A cryptographic primitive should not depend on the representation
of its input data for its strength.
> Also take some file 100 bytes in length and hash
> down to 64 bits. Just becuase of the size difference there would be many
> collisions. True it is easier to find streches of 100 bytes that collide with
> my method but that does not mean that there are more such collisions.
It is the ability of an adversary to find such collisions that is the important
thing here. And it is rather easy!
> All it means is that you have a way to calculate what the collisons are
> and as a matter of fact the collsions are the minimun number possible.
> since again going back to the 100 bytes of input hashing down to 64 bits
> (8 bytes). there are exactly 2**(92*8) ciphers that can be "invented" that
> decrypt back to files that have the exact same hash. And with this method
> every possible hash output has exactly the same number of possible input
> sequences.
Yes, so it is balanced, but this is not enough for cryptographic usage.
> This should besides the fact every bit new changes the hash
> should be a requirement for a good hash.
> For those whohave trouble following this is scott19u in the non lenght
> changing mode.
>
> >
> >So using any kind of invertible message transformation in this way is no
> >good for constructing a cryptographic hash.
> >
> >Paul(o)
> >
> I value your judgement and realize a hash should not be invertable but
> this is not actuallt invertable since only a subset of bits out go to the
> hash.
I meant choosing a subset of output bits from an invertible message transformation.
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
------------------------------
Date: Tue, 01 Jun 1999 02:37:09 -0400
From: [EMAIL PROTECTED]
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Interesting technical solution to a different problem. If you apply
this to the situation that instigated your suggestion you'll find it
does not help. Once the court orders the production of the documents
the newspaper has to produce them. If the material was encrypted it
would have to produce the keys. If they refuse to produce the keys the
sanctions are identical to refusing to produce the material in the first
place. So encrypting the material does not incluence the outcome no
matter how obstinant the newspaper wants to be.
[EMAIL PROTECTED] wrote:
>
> This message isn't too scientific, but I think the implications could
> be pretty broad if it turns out to work.
>
> Newspapers have traditionally considered their sources very saced.
> Last month there were some riots at Michigan State University and the
> cops wanted access to the papers' camera footage for use in convicting
> people. Obviously the papers declined, but a judge forced them to give
> their negatives to the cops. This hatched an idea in my mind.
>
> Some of the new digital cameras save their images on a tiny Flash RAM
> card. I already know that simple crypto has been implemented on
> smart-cards. How feasible would it be to make a RAM card that
> automatically encrypts data when it's stored, and forgets the key as
> soon as it's removed from the camera? Then only the person who
> programmed the key in at first would be able to read the pictures.
> Very similar to exposing the film in a regular camera.
>
> As an extension, we need cameras that'll recognize memory devices as
> "write only", so that the pictures can't be retrieved even while the
> card is still in the camera. The card would implement some form of a
> paired-key system so that it couldn't even decrypt its own contents.
> Much more secure than the above solution, more secure than traditional
> cameras.
>
> Alternately, the crypto could be built into the camera. This would
> give such a device an immediate edge in the marketplace, but it'd be
> harder to change cryptosystems if one implementation turns out to be
> weak.
>
> Thoughts?
------------------------------
From: "Oliver J. Hanau" <[EMAIL PROTECTED]>
Subject: Obscure Code
Date: Tue, 1 Jun 1999 21:00:04 +0200
Does anyone now if there is any kind of source on producing obscure
code, i.e. code that is hard for an attacker to analyze/debug?
(Assuming the decryption process takes place in an insecure
environment, and the attacker attempts to find the key and possibly
also the algorithm.)
I know that the whole point of such obscure code is *not* to let
people know how it's done, but maybe there is something despite that
fact? A source stating that there aren't any sources would also be
fine.
As this is for an important side-note of a li'l thesis I'm putting
together, I'd prefer a off-line sources (book/magazine).
Thanks a bunch,
Oliver.
------------------------------
From: Florian Weimer <[EMAIL PROTECTED]>
Subject: Re: SHA-1 output random?
Date: 01 Jun 1999 19:45:08 +0200
[EMAIL PROTECTED] (Lincoln Yeoh) writes:
> Right now for a program running on Linux, I'm supplying it about 31
> variably random bytes from /dev/urandom, and trying to use SHA-1 to
> concentrate stuff a bit. I'm not sure if the trade off is worth it - coz
I don't think so, because the data you get from /dev/urandom is
generated based on an entropy pool using SHA-1. That's the reason why
I'm interested in this property of SHA-1. ;)
Are there any one-way hash functions which could be used instead?
------------------------------
From: Nicholas Zacca <[EMAIL PROTECTED]>
Subject: Question about Cryptography/Encryption...
Date: Tue, 01 Jun 1999 19:42:29 GMT
Hi. I'm a high school student looking for information about cryptography
and software encryption. I'm doing a project on this topic and have been
searching the web for information on the history behind encryption (ie.
what was the first encryption? what came after that, etc. ) but I have
come up short. I keep finding pages on encryption programs and
algorithms but those really don't help me. :( Can anyone point me in
the right direction of a good web site/book/resource/company I could
contact, anything that would assist me with my topic? thanks for your
help! :)
Nick
------------------------------
Date: Tue, 01 Jun 1999 03:46:22 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Pro forma only...
Nathan Kennedy wrote:
>
> [EMAIL PROTECTED] wrote:
> > > Contrary what you seem to imply, you COULD NOT just use a key as large as
> > > the device... You couldn't rewrite a sector encrypted with the same key
> > > sector that the previous version was... you could use the two encrypted
> > > versions to easily derive both.
> >
> > Here you are making a false assumption, and, natuarally, reaching a
> > false conclusion. The threat model is not an adversary watching
> > everything that passes over the IO channel to the device. The threat
> > model is someone who obtains an image of the device, probably by theft
> > or seizure of the physical storage mechanism.
>
> All right, I read you now. But I think if anyone is making false
> assumptions, it's not me. You did say "ignore the rewrite issue", and
> naturally my response was "you can't." You did not limit the threat model.
>
> Naturally, with the threat model thus limited, you can ignore the rewrite
> issue. There's still the issue of having a OTP device the size of your
> working device, and hiding it, which would be a major pain for real-world
> scenarios. If you could keep 2 gig of data hidden, what good does keeping
> 2 gig of OTP secret do?
These question derive from the lack of a precise operational model.
Consider a (simplified for the purposes of discussion) situation where
we have a data repository (e.g., a disk subsystem) on which is stored
extremely valuable information. The value is such that we want to
absolutely minimize the chance of an adversary obtaining the
information, being willing to risk losing our own access in order to
deny the adversary any chance at getting access.
Again, for the purposes of discussion, and because the issues are
crypto, we'll assume "adequate" physical security. More precisely,
we've eliminated to the best of our ability any chance of _covert_
access to the repository. However, we cannot eliminate the possibility
of overt access (theft, etc.). This may, at first glance, appear to be
a strange assumption, but all it means is that any acess is going to
leave traces. I.e., records.
Finally, we assume sufficient reliability of storage to eliminate the
need for regular backups. This is not unreasonable. It can be met with
the same technology tat is used to provide 7x24 hot backups for critical
systems.
So, the adversary can obtain a copy of our working set (by force or
deceit), but probably not multiple images. The issue thus comes down to
securing the image that the adversary obtains.
Given the above operational model, the simplest answer is to make the
data repository volatile. We stated above that we could detect overt
access, so, if we can detect access in real time, we just evaoprate the
volatile storage medium (kill power to the RAM disk or whatever).
The problem with this scenario is that the information we are protecting
is not only valueable to the adversary, it is valueable to us as well.
Thus we'd like to secure it in such a way as to be able to recover from
an evaporation. Problem is that if we can recover, so can the
adversary. Thus the recovery operation has to require a key that
enables us to recreate the repository.
The OTP serves as such a key. An offsite, non-volatile image of the key
is much easier to secure than the data for several reasons. First, we
can use cheap, unpowered storage for the key, while the data has to
continuously accessible (powered, rotating, mounted, whatever) for the
entire system to perform useful work. Second, the key is a static image
where the protected data is updated continuously. Third, the key can be
distributed/stored/secured in sections where the complete data probably
has to be available in one place.
>
> The fact is, in the real world, you can't pick your threat model. Would
> users of Scramdisk or ppdd find your threat model acceptable? I don't
> think so.
Of course not. They are protecting against lesser threats.
Consider a civil rights group in China. They want to prevent the
Chinese Government from getting at their records covertly (crypto is
never going to protect against rubber hoses). This operational/threat
model is similar to that described above.
>
> > An intermediate threat model might include an adversary obtaining
> > multiple instances of an image backup or equivalent. But this is a
> > pretty remote scenario.
>
> Intermediate? Remote? If they can grab it once, how come not twice,
> without even being noticed? If they are allowed to physically come and
> remove it, why can't they come in and duplicate it a few times covertly?
> And the if they could, cracking any modified text would be trivial. I
> don't like your threat model.
The storm troopers are not going to visit twice. Covert access is going
to go after the plaintext, not the cipher text. Thus _no_ encryption
mechanism is going to protect against covert access adequately.
>
> > In order to protect against this threat you'd have to use something
> > other than 1:1 XOR as your fundamental operation. BFD.
>
> And if you introduced some other system which involved, say, a one-way
> function, you no longer have OTP. Sorry. But you knew that... OTP's
> fundamental operation must be provably a keyed reversible one-to-one
> mapping of possible plaintexts to possible ciphertexts with an effective
> keyspace equal to the number of possible mappings, which is why XOR, being
> the simplest, is used. A change of OTP's fundamental operation makes no
> difference.
Wrong. The key to the statement you are disputing is the 1:1 aspect,
not the XOR operation. Your statement
"OTP's fundamental operation must be provably a keyed reversible
one-to-one mapping of possible plaintexts to possible ciphertexts
with an effective keyspace equal to the number of possible
mappings..."
is false. The key space does not need to be equal to the number of
mappings. It can exceed the number of mappings without weakening the
cipher at all. Such an "excess key" OTP can be implemented at the macro
level, which makes it equivalent to simply changing the pad, or at the
micro level (char/block), where it replaces the fundamental operation.
Macht nicht.
The multiple-image threat is intermetiate to the single-image-only
threat, and the continuous monitoring threat. It can be countered by
altering the key map or altering the key after each image snapshot is
taken.
>
> > OF COURSE it won't be as convenient PGP, PGPdisk, Scramdisk, et al. OF
> > COURSE it is more hassle than a small-key cipher. But we don't know how
> > secure small-key ciphers are. We _do_ know how secure an OTP system is
> > if it is properly implemented. That may be valuable enough in some
> > circumstances to put up with the hassle.
>
> OTP is only provably secure when you can provably secure your OTP. When
> there is no issue of secret channel bandwidth, say, between two agents with
> a secure channel that closes, OTP makes sense. When you are dealing with a
> situation where you can only keep a much smaller secret, it doesn't.
>
> The fact is, for data storage involving one party, simple logic proves that
> OTP is inappropriate and doesn't work. If the person can securely stow X
> bits from disclosure (by memorizing, hiding, carrying...), he does not need
> to encrypt X bits. If he wants to store greater than X bits from
> disclosure, than he needs to obfuscate those bits according to a secret
> with less than or equal to X bits, hence, symmetric keyed encryption.
Nonsense. Please review the issues described abovd regarding key
storage vs data access. Keys are easy to store securely. Data is hard
to store securely.
>
> > > OTP could work for write once, read once/many mediums or archived data,
> > > albeit much worse and more inconveniently than traditional symmetric,
>
> And you note that I repudiated even that small concession made without
> thinking...
Good for you.
>
> > > but
> > > couldn't possibly be practical for random-access FS encryption.
> >
> > Here we disagree. Futher comment on your part appears to be pointless.
>
> Okay. Show me. Otherwise I agree, further comment on my part is
> pointless. I do not believe your threat model is realistic in the real
> world, especially if you're going to all that trouble for provable security
> to begin with, and I still do not think OTP makes sense for archive or FS
> encryption.
For archival storage in the real world no form of crypto makes sense.
Since it is archival, there is no need for access or transmission, so
physical security is a necessary and sufficient condition. OTP cypto
for archives is a waste because you have at least as much trouble
storing the keys as you do storing the data (their storage conditions
are identical in an archive). Finally, small-key crypto is a waste of
time because the lifetime of the data may match or exceed the lifetime
of the crypto system. (Multi-level encipherment might address this, but
I tend to think not sufficiently).
But, when you introduce "the real world" you bring in a host of issues
that you are a newgroup is not capable of handling. One such issue is
the fact that I have customers interested in solving just such a threat
model. I'm exposing my design solution to the harshest criticism I can
find (this ng being one) in order to find potential flaws in it.
Flaws consist of weaknesses in the proposed design or sub-optimal
solutions (where a better answer is known). Disbelief on the part of a
contributor does not consitute a flaw.
------------------------------
From: Raymond Calande <[EMAIL PROTECTED]>
Subject: Re: 8Bit encryption code. Just try and break it.
Date: Tue, 01 Jun 1999 12:38:52 -0700
Here's an idea. Given that you prefer not to publish your algorithm, why not show both
plaintext and the corresponding encypted text. You could also provide the key. If the
algorithm is any good, providing this data should not reveal it.
Phoenix wrote:
> thanks for trying to break my code. If you decrypt it ignore the
> contents of the message it was typed awhile back.
>
> If you succeed e-mail:
> [EMAIL PROTECTED]
>
> ------------------------------------------------------------------------
> 5�a��0P|�'���p�SҚ�6�&
>�T���Uh w��A�6��Pu}T��H${�v��S�t�^�9�S��C`��``�-T�Xhx�y��v���J�ȚU�
>
>����[a��E$���n0`��X)��YU-��x�WR�e5�f�!V�Ve��s�42 G���`�i�H���8(��6JP��$F��V��)����wr\I@.�';��65�(�*9
>
>��E�5r�S��17���h[,GL�8(-�ezT���̚`�+PQ��}�@�E����#%�A��(R�5*�W�PV/�"r>2]h
> <�@��6�#%����6�uU��7A���M�`��T��6d�2Ět��u�r`}�PF�0��&
>�#O�H�9%ݚ�a�Y��FU �f�6:P�L�2Ӛ2H�9%��pؚ���@p+�ҚD�R0zbi�Id�uPz��pR:bE�2$N�TR�4��Hw���2�xE{A=�Hr��b5�@��A( ��T�?i�e0�b�'6�p�r&��`��0�`��H$�c�KF�(Rz5�0UN�V��`�ۚD7��v����pG��v�Ce���5m�MuP
> �aw����e�����'eҚ�W�T�Ek�hs/h�I@�8(k�V� R5�2)���2�FP�E*�Q/U
>�a����h� @�g��Q���u?4�-�F@�uNCU���D�f��A�GV.�VU?R%Nv��u�
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Using symmetric encryption for hashing
Date: Tue, 01 Jun 1999 20:58:33 GMT
In article <[EMAIL PROTECTED]>, Paul Onions
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <[EMAIL PROTECTED]>, Paul Onions
> <[EMAIL PROTECTED]> wrote:
>> >It's not one-way: given a hash output, simply "invent" the other ciphertext
>> >bits and decrypt. This gives a preimage of the output.
>>
>> I am not sure what you mean by invent here since I don't think the
>> other bits are that easy to find with out the original input text. If you
>> think about it my scott19u contest is based on this being hard since in the
>> contest the "key" is given only a few bytes of the encrypted output file
>> need to be found.
>
>We don't need to find the original ciphertext bits since there is no need
>to try and recover the original message.
>
>All we want to do is generate a message, any message, that will hash to a
>given output. If we can do this then it shows that the proposed hash
>function is not one-way.
>
>You could replace "invent" by "generate at random".
>
>> >It's not collision-resistant: as above, but "invent" two lots of ciphertext
>> >bits and decrypt each. This gives two preimages with the same output.
>>
>> This is true but it is highly unlike that either preimage would be ascii
>> or anything meaningful.
>
>Irrelevent. A cryptographic primitive should not depend on the representation
>of its input data for its strength.
>
>> Also take some file 100 bytes in length and hash
>> down to 64 bits. Just becuase of the size difference there would be many
>> collisions. True it is easier to find streches of 100 bytes that collide with
>> my method but that does not mean that there are more such collisions.
>
>It is the ability of an adversary to find such collisions that is the important
>thing here. And it is rather easy!
>
I agree it is easy to find a set that hashes to the same thing. If this is
important for what the hash is to be used for then you are correct. But if one
is hashing for other reasons then this is not important. And I still think
that if it is used for ascii messages it would be very hard to find one that
hashes to same hash. It might be faster to try all ascii messages to see
if a matches occurres than to try the inverse of every cipher text to find
another message that produces the same hash.
As an extreme case suppose one is hashing one hundred ascii characters down
to a single byte. Since there are only 256 cases it would be much faster to
just try a several different ascii strings since one in every 256 map to the
byte one is looking for. It would take much longer to decrypt the random
cipher texts to come up with a valid ascii sentence.
>> All it means is that you have a way to calculate what the collisons are
>> and as a matter of fact the collsions are the minimun number possible.
>> since again going back to the 100 bytes of input hashing down to 64 bits
>> (8 bytes). there are exactly 2**(92*8) ciphers that can be "invented" that
>> decrypt back to files that have the exact same hash. And with this method
>> every possible hash output has exactly the same number of possible input
>> sequences.
>
>Yes, so it is balanced, but this is not enough for cryptographic usage.
>
>> This should besides the fact every bit new changes the hash
>> should be a requirement for a good hash.
>> For those whohave trouble following this is scott19u in the non lenght
>> changing mode.
>>
>> >
>> >So using any kind of invertible message transformation in this way is no
>> >good for constructing a cryptographic hash.
>> >
>> >Paul(o)
>> >
>> I value your judgement and realize a hash should not be invertable but
>> this is not actuallt invertable since only a subset of bits out go to the
>> hash.
>
>I meant choosing a subset of output bits from an invertible message
> transformation.
>
>Paul(o)
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
