CRC adequate for electronic book authentication?
Jon Noring
request to.]
Hello,
One aspect of the coming electronic book era is the necessity to maintain
document integrity -- to provide a check by which an electronic book
document (tagged text, such as XML) is authenticated to be original and
unmodified/uncorrupted.
Using a CRC method looks to be of interest (I've already read a portion of
the "Painless Guide to CRC Error Detection Algorithms"). It should catch
random file corruptions. However, would any CRC method be adequate to
protect against intentional text modifications? I can envision that with
enough computing horsepower (future computers will be very powerful), that
somebody might be able to intentionally modify an electronic book text
document for whatever nefarious purpose, yet maintain the same CRC by adding
some random text fields here and there (maybe this is near impossible, and
I am worrying needlessly).
I'd like feedback on if a CRC would be adequate to protect against
intentional attempts at modification of e-book text.
Also, what CRC standard should I consider? I've heard of standards such
as CCITT-CRC, CRC-16, CRC-32c, etc., but I could not find specific
information on any of them, or how robust they are (I assume how many bytes
in length they are).
Let me know if there are any other authentication methods besides CRC which
may be appropriate for the use I am contemplating.
Thanks.
Jon Noring
--
_________________________________________________________________
Kama Sutra of Vatsyayana *** Perfumed Garden of Sheik Nefzaoui
http://www.exemplary.net/omnimedia/bookstore.html
-----------------------------------------------------------------
{lord snow}
> :One aspect of the coming electronic book era is the necessity to maintain
> :document integrity -- to provide a check by which an electronic book
> :document (tagged text, such as XML) is authenticated to be original and
> :unmodified/uncorrupted.
> :
> :Using a CRC method looks to be of interest.
I am no expert, but I'll give you my thoughts on this:
1. CRC was never intended for security purposes, only for error
correction. It seems to me that it would indeed be difficult to create
a same CRC checksum, but not impossible since it wsa not designed
to MAKE that impossible. As for using standard CRC system - I would
think this would only make it easier for others to fake a checksum. I
would use an adapted CRC method.
2. I would use a one-way hash function (for example, passwords are
never stored but 'hashed' so that a fingerprint results. The fingerprint
is stored and compared every time to the hash of any password
entered.) Since it would NOT do at all if different inputs (normally
passwords, but the text file in your case) result in the same
fingerprint the hash systems are designed to prevent this from
happening. (as much as possible).
I hope that helps at least a little
Bas
]lordsnow
]
] ICQ : 30557335
] www : come.to/lordsnow
] Email : lord...@hotmail.com
s_d...@my-deja.com
can be found like "digest" algorithms like MD4 and MD5 which have
been around for a zillion years (at least in internet time)...
(RFC 1321 describes RSA's Message Digest Algorithm 5, RSA-MD5)
Essentially "digest" algorthms are complicated hash functions that
are extremely difficult to invert so that it is nearly impossible
to just modify one letter or word in the message and compensate for
it in another part of the message and get the same numerical result.
With a CRC, it is much easier to make a small modification and
compensate for it elsewhere and thus the body of the text would
be vunerable to pair-wize modifications.
-slew
In article <7q21kv$1...@dfw-ixnews16.ix.netcom.com>,
nor...@netcom.com (Jon Noring) wrote:
> [Let me know if there are more appropriate newsgroups to post this
> request to.]
>
> Hello,
>
> One aspect of the coming electronic book era is the necessity to
maintain
> document integrity -- to provide a check by which an electronic book
> document (tagged text, such as XML) is authenticated to be original
and
> unmodified/uncorrupted.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Jean-Jacques Quisquater
What you need:
- a cryptographic hash function (SHA-1, RIPEMD-160, ...) applied to the
file
you want to protect: it is not enough, everybody is able to do after
any
alteration of the file (electronic book): the result will be a hash
value;
- a signature scheme (together a certification scheme for the purpose of
trusting the verification value) for signing this hash value;
the result will be a signature of the hash value, proving the
integrity
and the orign (authenticity);
- and, in some sense it is not enough, at least for proving ownership,
because everybody is able to remove the signature and to put his own
...
- add thus a watermarking putting some info inside the file and avoiding
in that
way the removing of any info ... We don't know any good public-key
scheme doing that.
There are other combined solutions: see, for instance,
www.intertrust.com.
Jean-Jacques Quisquater,
Herman
The length of a CRC32 is not adequate to protect a whole book, but it is
better than nothing and would provide you with an indication of
inadvertent modifications to the text. For protection against
inadvertent changes, I would calculate a CRC32 for each chapter. It is
however a simple matter to run a CRC backwards. One can modify a book
in such a way that the CRC will be the same. Therefore this method will
not provide protection against intentional changes.
You can use a simple and quick encryption algorithm such as DES,
Blowfish, IDEA or MD5 to generate a cryptographic checksum. These
things cannot be run in reverse and would allow you to protect the book
against all changes, except maybe something done by the NIS. But
changes by ordinary mortals will be detected. My personal favourite is
Blowfish, since it is very simple and therefore easy to verify that the
code is correct and I don't care that the NIS or MI6 can break the code
- they can break anything if they put their minds to it. Look at it
this way: If your PC can encrypt something in 1 second, you can be sure
that an NIS supercomputer can break it in 1 second...
There are several DLLs available on the net for these common algorithms,
but be sure to test them before using them, or buy a copy from a
reputable source. See my web site for the book "Applied Cryptography".
Cheers,
Herman
http://www.AerospaceSoftware.com
Robert Graham
Hash: SHA1
Jon Noring wrote:
>
> One aspect of the coming electronic book era is the necessity to
> maintain document integrity -- to provide a check by which an
> electronic book document (tagged text, such as XML) is
> authenticated to be original and unmodified/uncorrupted.
>
> Using a CRC method looks to be of interest
What you are proposing is a well-known problem. When I say
"well-known", I mean that the entire cryptographic community has
speant decades analyzing your problem and have essentially come up
with one, and only one, solution.
First of all, a CRC is a two-way hash. This means given a CRC, it is
easy to come up with something that produces that CRC. This means
that if I want to corrupt your message, I can simply make my changes,
then make other changes to come back to the same CRC. Therefore, you
need a one-way hash. This means that it is virtually impossible to
come up with two different files and come up with the correct value.
Examples of typical hashes are MD5 and SHA-1.
The second step is "signing": I can change both the message and the
hash, then you are not better off than you were before. Therefore,
you have to encrypt the hash. However, we have a problem: people have
to decrypt the hash before they verify it. Well, as it turns out that
back in the 1970s an interesting encryption technique was found
called "asymmetric encryption". This means you can encrypt with the
password "fred" and decrypt with the password "june". This means that
you ship "june" along with the encrypted password, and anybody can
decrypt it. However, nobody can change the hash, then reencrypt it,
because nobody has the password "fred". [Note: I've simplified things
here, you really start with two prime numbers, then play some magic
in order get two large numbers that you use to encrypt]. In our
terminology, this is called "private key" and "public key", where
nobody knows the key "fred" buy you, and everbody knows the key
"june".
There are more tricks to this, such as using a certificate authority
to countersign your key and validate your are who you say you are,
but that isn't strictly necessary.
This whole thing is called "PKI", "Public Key Infrastructure". It is
very well understood, and is really the only solution to the problem
you pose. More than that, tons of products are appearing to solve
this for you. The easiest is PGP. There are lots of opensource
implementations, but you could also simply download the freeware for
personal use from NAI.com. As an example, I've "signed" this e-mail
message in exactly the same way that you should sign your book. You
can not only verify the key is valid, but also compare it against the
one on my website:
http://www.robertgraham.com/pgp-key.asc
Again, I must reiterate. Right now, this is the ONLY reasonable
solution to what you want. I recommend that you get PGP right now and
use it.
- --
Robert Graham
robn @ NetworkICE DOT com
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
iQA/AwUBN8YqFEsZIfi0CwoYEQJZEACg2UEbtmjP2TiecYcIkK9O0krnGhEAn0VT
d/jWy9j3oPg9CuwU/thYtfEH
=EyMH
-----END PGP SIGNATURE-----
wtshaw
<12345r...@example.com> wrote:
> Jon Noring wrote:
> >
> > One aspect of the coming electronic book era is the necessity to
> > maintain document integrity -- to provide a check by which an
> > electronic book document (tagged text, such as XML) is
> > authenticated to be original and unmodified/uncorrupted.
> >
> > Using a CRC method looks to be of interest
>
> What you are proposing is a well-known problem. When I say
> "well-known", I mean that the entire cryptographic community has
> speant decades analyzing your problem and have essentially come up
> with one, and only one, solution.
....
> Again, I must reiterate. Right now, this is the ONLY reasonable
> solution to what you want. I recommend that you get PGP right now and
> use it.
>
Which is incorrect.
Consider that a book is distributed to an individual. The means of
reading it can be propriatory, and/or the keys necessary for that
individual can be licensed. The software can make it difficult to copy
the contents. Therefore, the licensee can be restricted from sharing his
key, and what it unlocks with another, and anyone having the means given
to someone else would mean that the first party violated the license.
The only essential requirement for safeguarding content is that the
program and keys be delivered securely, and that the licensee accept the
legal burden of not violating his agreement. The programs themselves
should do the whole job of decryption and presentation in a format
suitable to the display device.
PGP could fit in here, but it is probably inadequate and burdensome to get
into that tangled web where mere simple one on one information is
involved, and PGP is pretty much still a moving target with baking
somewhere near the half-way mark, sorry.
Sophistocated and adequate encryption to solve your problem does exist,
but it is not popular, and there are several options. PGP has its uses,
but this is not one for which it is efficiently designed, certainly not in
the user-friendly, appropriate presentation side. Using PGP takes time to
learn, reading a book has of necessity got to be almost completely
transparent to any user.
--
I'd rather have prime rib than prime numbers.
Moore's Law always yields to Les's Rule.
John Nagle
>I'd like feedback on if a CRC would be adequate to protect against
>intentional attempts at modification of e-book text.
No. You need a "message digest" function, like MD5. This
generates a 32-byte value from a text in such a way that it
is extremely difficult to create two texts with the same value,
even on purpose. You may then want to use a digital signature
system to "sign" the message digest value with a known public
key.
Try posting to "sci.crypt" for further advice.
John Nagle
Herman
CD, then it would be very hard to modify and there would be no need for
signatures...
Jon Noring
>I think we missed the obvious: Physical protection. Publish the book on
>CD, then it would be very hard to modify and there would be no need for
>signatures...
The future of electronic book distribution is the Internet, not on fixed
media, so I still need to consider a digital document integrity (DDI) system.
It looks like MD5 is a possible answer to this need, which I will look into.
Colin B. German
that CD writers are cheaper and more widespread? Even if the actual CD
cannot be modified, files can be modified in the process of copying to
another CD!!
--
E-mail:
cg...@usa.net
colin....@mt.pwcglobal.com
Herman wrote in message <37CD2BC6...@AerospaceSoftware.com>...
>I think we missed the obvious: Physical protection. Publish the book on
>CD, then it would be very hard to modify and there would be no need for
>signatures...
>
Herman
of the adversary. If I write a technical book, I'm not going to worry
about modifications to the text - other people can only improve it! If
it is government documents, then it should beprotected by physical
means. If I'm writing a religious scripture, then maybe, but the very
essence of religion is its adaptability and changes over time keeps it
alive...
Basically, I fail to see the need for strong protection, if original
copies can always be obtained from the author, meaning that there is a
trusted source.