RE: [office] Uselessness of table:protection-key - perfect key safety

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I looked over my earlier statement and have revised it to be entirely
descriptive with no use of normative terms (other than "may" in the sense of
possibility as used by JTC1).

But, before going on to more serious subjects, I also came upon a hilarious
way to use the table:protection-key in a way that will never be subject to
key compromise because the key is not known to anyone and it is unlikely
that there is a possible, let-alone guessable, input sequence that leads to
the hash value. 

Here's the drill:

1. Before protecting the document, save a copy with the lock not set, for
use in making future versions, modifications, etc.  (Or obtain the handy
utilities described in (4).)

2. Now, for the copy that is going to be distributed for people to use,
directly set the table:protection-key attribute using the following
procedure:
   2.1 Using a cryptographic random number generator, generate a 160-bit
random sequence stored in 20 octets.
   2.2 Convert the 20-octet sequence to a (30-character) Base64 encoding.
   2.3 Insert the table:protection-key attribute with the Base64 value on
the <table:table> element that has table:protected="true"
   2.4 Optionally, insert a
table:protection-key-digest-algorithm="http://www.w3.org/2000/09/xmldsig#sha
1".  It is probably even more fun to omit the
table:protection-key-digest-algorithm attribute altogether (and remove it
from the specification). 

3. That's it.  There is a lock, the lock is set, and there is no key to be
compromised.  The level with which removal of the lock is protected is as
strong as it can ever be.

4. If anyone is interested, we can probably cook up a little command-line
utility or a JavaScript to do the deed.  We can also make one that unlocks
the protected cells by extracting the table:protection-key element entirely
(we can call that the key-reset procedure).

	-	-	-	-	-	-	-	-	-

All right, here is the cleaned up statement that would be valuable to
include in the description of table:protection-key.

(1) The table-cell protection feature is provided as a safeguard against
accidental alteration of cells that are kept fixed in order to achieve an
intended purpose, such as use of tables as part of a form for data
collection and reporting.

(2) The locking of table-cell protection is provided as a safeguard against
careless over-riding of the table-cell protections.  Cell locking is not a
secure protection against unauthorized and un-noticed alteration of the
protected table cells.  Knowledge of the password is not required in order
for a knowledgeable party to over-ride the locking by manipulation of the
XML document directly.  Knowledge of the password is not required in order
to deleted the table:protection-key attribute and also to use it for the
locking of protected cells of other tables. 

(3) The hash code protects against casual discovery of the password by
inspection of the XML.  Hash codes of short texts such as memorable
passwords are easily attacked regardless of the strength of the hash code.
The consequences of password compromise can be limited by not using a
table-cell protection password for any other purpose.  The compromise of
passwords can be prevented entirely by generating random hash-code values
without choosing any password at all.


-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/office/200901/msg00009.html
Sent: Saturday, January 03, 2009 11:14
To: office@lists.oasis-open.org
Cc: 'Bob Jolliffe'; Patrick Durusau
Subject: RE: [office] Table Protection: Uselessness of table:protection-key

Bob, I think that's right.

Perhaps the way to say it is this:

(1) the table-cell protection feature is provided as a safeguard against
accidental alteration of cells that must be kept fixed in order to achieve
the intended purpose, such as use of tables as part of a form for data
collection and reporting.

(2) the locking of table-cell protection is provided as a safeguard against
careless over-riding of the table-cell protections.  Cell locking is not a
secure protection against unauthorized and undetected alteration of the
protected table cells.  Knowledge of the password is not required in order
for a knowledgeable party to over-ride the locking by manipulation of the
XML document directly.  

(3) The hash code is a barrier against casual discovery of the password by
inspection of the XML.  Hash codes of short texts such as memorable
passwords are easily attacked regardless of the strength of the hash code.
To limit the consequences of password compromise, passwords used for locking
the table-cell protection should not be used for any other purpose.

 - Dennis

-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
http://lists.oasis-open.org/archives/office/200901/msg00008.html
Sent: Saturday, January 03, 2009 10:17
To: office@lists.oasis-open.org
Subject: Re: [office] Table Protection: Uselessness of table:protection-key

Hi

2009/1/3 Patrick Durusau <patrick@durusau.net>:
http://lists.oasis-open.org/archives/office/200901/msg00007.html
> Dennis,
>
> While table/cell protection is an expected "feature," I am not sure how
far
> we should go in terms of warnings to users. In part because any warning we
> give will be of necessity incomplete.

I think users should simply know that cells are only protected against
accidental editing.  Currently it is most likely that most users
assume that some sort of actual protection is going on here.  Perhaps
the language of "protection" doesn't help. More neutral language like
"intended-read-only" rather than "protected" would be better.

Regards
Bob

[ ... ]
> Dennis E. Hamilton wrote:
>>
>> Forgot to address this to the list
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] Sent: Friday,
>> January 02, 2009 16:04
http://lists.oasis-open.org/archives/office/200901/msg00006.html
>> To: 'Bob Jolliffe'
>> Subject: RE: [office] Table Protection: Uselessness of
>> table:protection-key
>>
>> I like your suggestion about a warning in the specification and I
included
>> that in the final part of my analysis on what needs to be specified if
>> table:protection-key-digest-algorithm is going to be useful.
>>
>> In addition, I just realized that worrying about coming up with hash
>> collisions is actually a misplaced concern and the strength of the
message
>> digest algorithm is irrelevant.  The weakness here is that keys are short
>> compared to the kinds of messages that digests work well for.
>>
>> Because keys are short and usually memorable, one can simply attack the
>> key
>> directly.  [ ... ]


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php