Re: [Bitcoin-development] Preparing for the Cryptopocalypse
On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote: I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. Lamport signatures (and merkle tree variants that allow reuse) are simpler, faster, trivially implemented, and intuitively secure under both classical and quantum computation (plus unlikely some proposed QC strong techniques they're patent clear). They happen to be the only digital signature scheme that you really can successfully explain to grandma (even for values of grandma which are not cryptographers). They have poor space/bandwidth usage properties, which is one reason why Bitcoin doesn't use them today, but as far as I know the same is so for all post-QC schemes. Though I question the validity of the claim that ECC is so much more secure than RSA (with appropriate keysizes). The problems are intimately related, but under the best understanding ECC (with suitable parameters) ends up being the maximally hard case of that problem class. I do sometimes worry about breakthroughs that give index-calculus level performance for general elliptic curves, this still wouldn't leave it any weaker than RSA but ECC is typically used with smaller keys. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Safe auto-updating
For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 signature.asc Description: Message signed with OpenPGP using GPGMail -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Preparing for the Cryptopocalypse
Interesting! I will refrain from digging into QC right now, per Alan's suggestion. :) -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
If you want package authentication, you should at least throw in some digital signing, not just a checksum. With a compromised host, both the checksum and binaries can be changed undetectably, but if there's a signature made by a key that is not kept on the host, there's no way to fake a valid binary. There may be other issues people would want to bring up, but surely just a checksum is not sufficient. on 08/05/2013 10:39 AM Wendell said the following: For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
Indeed. You can hardcode a distributor public key in the software, and client software will only trust signed data from that key. Of course, the private key for that data is not kept on the server distributing the signed checksums. Ideally it would be kept offline, and the couple-times-per-year that you actually execute an upgrade, you sign the new checksums offline and upload the signed checksum to the distribution server. Then even if the server is compromised, the client-side software will not accept a bogus checksum because it won't bear the right signature. If you do this, it would be good to also have some kind of revocation process that can be used in the event of the offline key being compromised. You won't be able to switch keys, as that would defeat the purpose (the attacker who compromises the offline key could just issue a replacement with his own). Instead, it would be an irreversible broadcast that would force clients to start rejecting updates from that key. If the key is compromised (and find out), you broadcast the revocation and the users will stop auto-updating, and be given a warning that they should manually upgrade the software through trusted channels. It's not failproof, but it's a decent way to minimize damage if you discover compromise early enough. -Alan On 08/05/2013 11:54 AM, Daniel F wrote: If you want package authentication, you should at least throw in some digital signing, not just a checksum. With a compromised host, both the checksum and binaries can be changed undetectably, but if there's a signature made by a key that is not kept on the host, there's no way to fake a valid binary. There may be other issues people would want to bring up, but surely just a checksum is not sufficient. on 08/05/2013 10:39 AM Wendell said the following: For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
One approach you could use would be to use bitcoin signing on a list of the build artifacts together with their SHA256 hashes. If you have a look at the MultiBit release notes you get the overall idea: https://multibit.org/releases/multibit-0.5.13/release.txt Currently these aren't machine readable but you can imagine having a machine readable statement with: + a list of the files in the build + their SHA256 hashes + the above bitcoin signed by multiple signatures e.g. 2 of 3 The client can then download the file, check the signature, check the hashes and knows which files to download. The acceptable Bitcoin addresses for signatures would be a whitelist in the client code. On Mon, Aug 5, 2013, at 05:47 PM, Alan Reiner wrote: Indeed. You can hardcode a distributor public key in the software, and client software will only trust signed data from that key. Of course, the private key for that data is not kept on the server distributing the signed checksums. Ideally it would be kept offline, and the couple-times-per-year that you actually execute an upgrade, you sign the new checksums offline and upload the signed checksum to the distribution server. Then even if the server is compromised, the client-side software will not accept a bogus checksum because it won't bear the right signature. If you do this, it would be good to also have some kind of revocation process that can be used in the event of the offline key being compromised. You won't be able to switch keys, as that would defeat the purpose (the attacker who compromises the offline key could just issue a replacement with his own). Instead, it would be an irreversible broadcast that would force clients to start rejecting updates from that key. If the key is compromised (and find out), you broadcast the revocation and the users will stop auto-updating, and be given a warning that they should manually upgrade the software through trusted channels. It's not failproof, but it's a decent way to minimize damage if you discover compromise early enough. -Alan On 08/05/2013 11:54 AM, Daniel F wrote: If you want package authentication, you should at least throw in some digital signing, not just a checksum. With a compromised host, both the checksum and binaries can be changed undetectably, but if there's a signature made by a key that is not kept on the host, there's no way to fake a valid binary. There may be other issues people would want to bring up, but surely just a checksum is not sufficient. on 08/05/2013 10:39 AM Wendell said the following: For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk