[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Uselessness of table:protection-key - perfect key safety
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]