"correcting" transactions

Derek Atkins warlord at MIT.EDU
Wed Feb 26 10:08:37 EST 2014


Mark Rousell <markr at signal100.com> writes:

> On 25/02/2014 15:49, Derek Atkins wrote:
>> Mark Rousell <markr at signal100.com> writes:
>> 
>>> One possible approach that occurs to me is to use public key
>>> cryptography. This approach is plausible but has obvious limits (which
>>> I'll outline below). Here is the approach I have in mind:
>>>
> [...]
>> 
>> The fact remains that someone could recreate the whole shebang.  You
>> don't know whether the data should start with Key0 or Key0' -- so an
>> attacker could just start over.  Same with the hashes.
>
> Remember, however, that what you describe here is not a problem unique
> to GnuCash. Any closed source software suffers from the identical
> problem. As I said in my earlier message (added text in square brackets):

Exactly!!  The problem I point out is with your proposed "security"
protocol.   It doesn't work.

>> Remember that
>> GnuCash writes out the whole XML data file every time.
>
> This is not a problem. Previous data sections only need to be re-written
> exactly as-is. I.e. They can be cached for re-writing as-is when the
> file is saved.

But an attacker wont do that, and there is no way for a verifier to
detect it without some external key storage.  Your proposed protocol is
fatally flawed in that there is no way to verify the root of the chain
of trust.  A verifier has no way to know what is the "right" key to use
to start the verification chain.  Your protocol *still* requires outside
knowledge, like a key written to a CDROM or acquired from a third party.
But once you do that you might as well just hand them to "non protected"
data file.

> My encryption approach merely offers auditability and non-editability
> *within* *an* *existing* *data* *file* which would put GnuCash on parity
> with closed source software in this respect (and possibly put it ahead
> in that it would use encryption rather than obscurity).

Unfortunately no, it does not.  Your approach only works if you have a
trusted keystore outside the data file that will give you assurance of
the root of your chain of trust of keys.

>> Intent is important; we cannot (and do not try to) protect against an
>> intended adversary, only an accidental one.
>
> Fair enough, although I would say that 'locking' already written data in
> an existing data file is more than about fighting an attacker (although
> it has been discussed so far in those terms). It is also about helping
> legitimate users ensure integrity of data within an existing data file,
> and this is surely of interest to users of all sizes.

You can do this at the UI level (and indeed GnuCash already does).  It
still doesn't help you with audits.  That's a completely separate issue.

-derek, wearing his Crypto Security hat

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-user mailing list