3 ms·

How is this any different than taking every mutation, signing it using whatever signing mechanism you'd like and adding a column, in addition to the ones you'd

How is this any different than taking every mutation, signing it using whatever signing mechanism you'd like and adding a column, in addition to the ones you'd like with the hash. Then, if anything changes you know it's been mutated because the computed signature has changed.

ianpurton 5y ago
Your solution wouldn't handle the case of row deletion. It's a little harder than you might think to make a database with tamper resistance.
- endisneigh 5y ago
  Oh I'm sure - but without delving into philosophy, how would you know that something was deleted and tampered with vs. Immudb (for example) being compromised and turns out it's possible to delete something without you knowing vs. it never existed to begin with? In my mind the only way to guarantee is to maintain a copy yourself and check against the "original", but if you're going to do that, then what I described is sufficient, no? I only mention this because the project mentions that the history is protected by clients, which I imagine is similar to what I'm describing, e.g. copying and checking against the original.
  - ianpurton 5y ago
    > In my mind the only way to guarantee is to maintain a copy yourself and check against the "original", but if you're going to do that, then what I described is sufficient, no? The attacker in that case could update your copy. But you have somewhat started to fix the issue. To cover the case where a bad admin has access to the DB and any copies, you need to send a hash every so often to an outside source. In this case they use clients (I'm not sure exactly how they do this). In fact you need a list of hashes one for every 100 rows for example. Re-generated the hashes and checking against an external source should detect a tamper. In the case of Bitcoin (which is extremely tamper resistant) every node operator is a validator. The hashes are stored in a merkle tree.
- hypertele-Xii 5y ago
  According to its own description, this database does not support deletion at all. "You can [...] never change or delete records."
  - rad_gruchalski 5y ago
    Aha, can one take the nodes offline or if I have PBs of data, it all has to stay online, always?
jeroiraz 5y ago
In some way, it’s basically that but on steroids… Note that if the signature includes the previous one then you are protecting the history of changes. However, this simple approach may not scale when dealing with considerable amount of data, proving some older entry was not tampered may require to validate all signatures from that point up to the latest one. immudb employs hash trees to optimise these proofs.
softveda 5y ago
Microsoft recently announced in preview Azure SQL Database Ledger with similar mechanism as you have suggested. https://docs.microsoft.com/en-au/azure/azure-sql/database/ledger-overview https://docs.microsoft.com/en-au/azure/azure-sql/database/le...

ianpurton 5y ago

Your solution wouldn't handle the case of row deletion. It's a little harder than you might think to make a database with tamper resistance.

endisneigh 5y ago
Oh I'm sure - but without delving into philosophy, how would you know that something was deleted and tampered with vs. Immudb (for example) being compromised and turns out it's possible to delete something without you knowing vs. it never existed to begin with? In my mind the only way to guarantee is to maintain a copy yourself and check against the "original", but if you're going to do that, then what I described is sufficient, no? I only mention this because the project mentions that the history is protected by clients, which I imagine is similar to what I'm describing, e.g. copying and checking against the original.
- ianpurton 5y ago
  > In my mind the only way to guarantee is to maintain a copy yourself and check against the "original", but if you're going to do that, then what I described is sufficient, no? The attacker in that case could update your copy. But you have somewhat started to fix the issue. To cover the case where a bad admin has access to the DB and any copies, you need to send a hash every so often to an outside source. In this case they use clients (I'm not sure exactly how they do this). In fact you need a list of hashes one for every 100 rows for example. Re-generated the hashes and checking against an external source should detect a tamper. In the case of Bitcoin (which is extremely tamper resistant) every node operator is a validator. The hashes are stored in a merkle tree.
hypertele-Xii 5y ago
According to its own description, this database does not support deletion at all. "You can [...] never change or delete records."
- rad_gruchalski 5y ago
  Aha, can one take the nodes offline or if I have PBs of data, it all has to stay online, always?

jeroiraz 5y ago

In some way, it’s basically that but on steroids… Note that if the signature includes the previous one then you are protecting the history of changes. However, this simple approach may not scale when dealing with considerable amount of data, proving some older entry was not tampered may require to validate all signatures from that point up to the latest one. immudb employs hash trees to optimise these proofs.

softveda 5y ago

Microsoft recently announced in preview Azure SQL Database Ledger with similar mechanism as you have suggested. https://docs.microsoft.com/en-au/azure/azure-sql/database/ledger-overview https://docs.microsoft.com/en-au/azure/azure-sql/database/le...