3 ms·

This is a new topic for me, so apologies if this is an obvious notion, but what if one of the properties of a super-peer is a certain level of transparency and

This is a new topic for me, so apologies if this is an obvious notion, but what if one of the properties of a super-peer is a certain level of transparency and auditability so that any peer can verify its operation? That is, the super-peer contributes bandwidth and reliability because those are the resources unique to it, but the decision-making aspects and operational state of being a super-peer could be out in the open.

PeterisP 12y ago
You can't verify the 'decision-making aspects and operational state' of a human or remote server, they can fake anything that you can check. Crypto tech allows us to verify possession of some information or token, or a proof of work, but that's it. Either the supernode can't do anything bad even if it's malicious (such as bitcoin miners) and you don't need the transparency or it can do something bad and then you can't audit it remotely, you need trust. If "something bad" is altering data, then if you can detect if the data is 'proper' (such as bitcoin transactions), then a node simply can't fake data; but if you can't detect it then you need to trust the node. The same for reading data, if it's cryptographically impossible for the node to read your messages, then you don't need to audit that node; but if it's possible, then you can't be really sure unless (and probably even if) the node is under your full control. [edit] Ahh, and if by 'verify' we mean not 'automatic verification that the system can do' but 'human verification where I check that Bob seems to be a nice guy, and thus his node can't be evil', then we're back to the original post - either centralized certificate authority chain, or Sybil problems.
- walterbell 12y ago
  > You can't verify the 'decision-making aspects and operational state' of a human or remote server If the node is running an operating system that supports a dynamic root of trust, it's theoretically possible to perform a remote attestation for binary hashes of all software & config running on the remote node. Not suggesting that is easy, but it can be done with the right hardware (TXT, TPM) and Linux software stack.
  - PeterisP 12y ago
    Nope, that's just delegating the problem to the trust chain - it assumes that the TPM does as it should be; and that noone in the chain ever signs anything wrong. That assumption is obviously wrong, there are many public incidents that show that the core signing keys of pretty much any 'trusted organization' can be used by three letter agencies to sign malicious code as, say, valid windows updates; and that both hardware and OS should be assumed to contain backdoors - especially in the TPM chain. In addition, having a true and valid hash of my OS, software and config doesn't give you any true assurance - a security hole in that software or OS can easily give an ability to execute arbitrary code, so the "proper configuration" can behave in whatever way, despite being verified. That's what I meant by saying that you can't be sure if it's not doing anything bad, even if you completely control the node - if the underlying math ensures that reading or altering X isn't possible, then it's okay; but otherwise you have to hope/trust that it doesn't. This is meant by zero-knowledge systems as opposed to 'secure' systems that simply ignore knowledge that they shouldn't look at.
    - walterbell 12y ago
      > a security hole in that software or OS can easily give an ability to execute arbitrary code > if the underlying math ensures that reading or altering X isn't possible, then it's okay If an attacker has access to a zero-day exploit that can compromise the OS, could they compromise random generation of numbers and weaken the zero-knowledge system?
      - PeterisP 12y ago
        They can weaken your part of the system by compromising your machine or your keys, but compromising the centralized node (either by an exploit or a subpoena) shouldn't change anything if that system is zero-knowledge; a compromised node can do no more than an actively malicious node.

PeterisP 12y ago

You can't verify the 'decision-making aspects and operational state' of a human or remote server, they can fake anything that you can check. Crypto tech allows us to verify possession of some information or token, or a proof of work, but that's it. Either the supernode can't do anything bad even if it's malicious (such as bitcoin miners) and you don't need the transparency or it can do something bad and then you can't audit it remotely, you need trust. If "something bad" is altering data, then if you can detect if the data is 'proper' (such as bitcoin transactions), then a node simply can't fake data; but if you can't detect it then you need to trust the node. The same for reading data, if it's cryptographically impossible for the node to read your messages, then you don't need to audit that node; but if it's possible, then you can't be really sure unless (and probably even if) the node is under your full control. [edit] Ahh, and if by 'verify' we mean not 'automatic verification that the system can do' but 'human verification where I check that Bob seems to be a nice guy, and thus his node can't be evil', then we're back to the original post - either centralized certificate authority chain, or Sybil problems.

walterbell 12y ago
> You can't verify the 'decision-making aspects and operational state' of a human or remote server If the node is running an operating system that supports a dynamic root of trust, it's theoretically possible to perform a remote attestation for binary hashes of all software & config running on the remote node. Not suggesting that is easy, but it can be done with the right hardware (TXT, TPM) and Linux software stack.
- PeterisP 12y ago
  Nope, that's just delegating the problem to the trust chain - it assumes that the TPM does as it should be; and that noone in the chain ever signs anything wrong. That assumption is obviously wrong, there are many public incidents that show that the core signing keys of pretty much any 'trusted organization' can be used by three letter agencies to sign malicious code as, say, valid windows updates; and that both hardware and OS should be assumed to contain backdoors - especially in the TPM chain. In addition, having a true and valid hash of my OS, software and config doesn't give you any true assurance - a security hole in that software or OS can easily give an ability to execute arbitrary code, so the "proper configuration" can behave in whatever way, despite being verified. That's what I meant by saying that you can't be sure if it's not doing anything bad, even if you completely control the node - if the underlying math ensures that reading or altering X isn't possible, then it's okay; but otherwise you have to hope/trust that it doesn't. This is meant by zero-knowledge systems as opposed to 'secure' systems that simply ignore knowledge that they shouldn't look at.
  - walterbell 12y ago
    > a security hole in that software or OS can easily give an ability to execute arbitrary code > if the underlying math ensures that reading or altering X isn't possible, then it's okay If an attacker has access to a zero-day exploit that can compromise the OS, could they compromise random generation of numbers and weaken the zero-knowledge system?
    - PeterisP 12y ago
      They can weaken your part of the system by compromising your machine or your keys, but compromising the centralized node (either by an exploit or a subpoena) shouldn't change anything if that system is zero-knowledge; a compromised node can do no more than an actively malicious node.