Re: Bitcoin P2P e-cash paper
>Satoshi Nakamoto wrote: >> I've been working on a new electronic cash system that's fully >> peer-to-peer, with no trusted third party. >> >> The paper is available at: >> http://www.bitcoin.org/bitcoin.pdf > >We very, very much need such a system, but the way I understand your >proposal, it does not seem to scale to the required size. > >For transferable proof of work tokens to have value, they must have >monetary value. To have monetary value, they must be transferred within >a very large network - for example a file trading network akin to >bittorrent. > >To detect and reject a double spending event in a timely manner, one >must have most past transactions of the coins in the transaction, which, > naively implemented, requires each peer to have most past >transactions, or most past transactions that occurred recently. If >hundreds of millions of people are doing transactions, that is a lot of >bandwidth - each must know all, or a substantial part thereof. > Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node. The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices. If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal. Satoshi Nakamoto - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Bitcoin P2P e-cash paper
Satoshi Nakamoto wrote: I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdf We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size. For transferable proof of work tokens to have value, they must have monetary value. To have monetary value, they must be transferred within a very large network - for example a file trading network akin to bittorrent. To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Wouter Slegers <[EMAIL PROTECTED]> writes: >Timing analysis is quite possible to pull of in straightforward >implementations as demonstrated over the Internet on OpenSSL prior to their >implementation of blinding ( >http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf). But frankly, I have >never heard of such an attack actually being used in the field. Real side >channel analysis (DPA, EMA etc) seems mostly limited to academics and labs, >not the field. One of the XBox attacks, allowing rollback to a vulnerable kernel, was a timing attack. I'd heard it was also tried in some form (unsuccessfully) against the Wii as part of the breadth-first attack approach. >I'm afraid that the best at this moment is mostly rumors. There is some >knowledge about attacks in the field but it is spread out a lot and the ones >that aggregate this information are not sharing this (it also gives the >attackers a view on what works and what not). You can see this with the games-console hacking, the attackers try and release the least amount of information possible so they've got something in reserve when the countermeasures appear. In some cases they use attack method A to find a weakness and then exploit it using unrelated method B, allowing reuse of method A once B is patched by the vendor. >As I read his story, he eavesdropped the bus between the bridge chip and the >CPU to recover the real bootloader code with the real RC4 key, Sorry, I was referring to two different attacks in the same sentence, and on re-reading managed to make the result quite unclear :-). The timing attack didn't directly recover the authentication key directly but avoided the need to know it, thus allowing unauthorised vulnerable kernels to be loaded. >not the incorrect one in the ROM (very nasty trick, kudo's for the Microsoft >development team there ;-) ). Often the simplest tricks are the most effective, e.g. stick a PGP header on the data to be protected and the attackers spend forever trying to decrypt it when in fact the processing function is (in pseudocode): seek( file, 16 );// Skip red-herring junk at start processData( file ); (the problem with this one was that they memcpy()'d the fixed header on and the lengths were wrong, but apart from that it would probably have distracted attackers for some time). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
L.S., Peter convinced my to publicly comment on this. Thierry Moreau <[EMAIL PROTECTED]> wrote: > >>But they've all been unlocked using easier attacks, surely? That was also my first response. In evaluation labs specialized in checking devices (mostly smartcards and other financial devices) the whole spread of attacks are tested against. Side-channel analysis is arguably the most sexy of them all, but I have yet to see any hint let alone proof that it is used in the field. Perturbation attacks (messing with the execution of the code) by means of glitches in the supply voltage is still the undisputed number 1 in field attacks on individual smartcards. Protocol/API-level attacks are the biggest one on system level in my opinion. Card sharing is currently a good example. Timing analysis is quite possible to pull of in straightforward implementations as demonstrated over the Internet on OpenSSL prior to their implementation of blinding (http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf). But frankly, I have never heard of such an attack actually being used in the field. Real side channel analysis (DPA, EMA etc) seems mostly limited to academics and labs, not the field. >From that regard, side channel analysis is currently the more expensive attack (the academic papers are good, but do not underestimate the difficulty in implementing it in non-ideal noisy environments), which suggest that protecting for it is not such a high priority at the moment (it is not the weakest link). > >The published ones seem to be the (relatively) easy ones, but the > >ones that have been tried (and either not published or just had the > >easy outcome published) have been pretty amazing. Which suggests that keeping side channel analysis as part of the possible attacks is a good idea. The broad scope of attacks seems to be done in the field, which means that it is interesting for the defenders to invest effort in that also. In a way, the enthousiast attackers on the internet form a sort of loosly parallel attack, not so much obviously focussing on one weak spot but using a broad spectrum approach. > >This is another one of these things where real figures are going to > >be near-impossible to come by, even harder than my hypothetical > >public vendor survey of who uses SCA protection. I'm afraid that the best at this moment is mostly rumors. There is some knowledge about attacks in the field but it is spread out a lot and the ones that aggregate this information are not sharing this (it also gives the attackers a view on what works and what not). I've seen quite a few publicly available examples of voltage manipulation on old style smartcards, (not so-)secure embedded CPUs. Old style physical reverse engineering is getting within the range of students now (recent reverse engineering of crypto-1 is a good example). Examples of side channel analysis on real systems I however have never seen in the field. Any rumors would be highly appreciated. > >attacks for example, there's everything from security 101 lack of > >checking/validation and 1980s MSDOS-era A20# issues through to Bunnie > >Huang's FPGA-based homebrew logic analyser and use of timing attacks > >to recover device keys (oh, and there's an example of a real-world > >side-channel attack for you), ?? As I read his story, he eavesdropped the bus between the bridge chip and the CPU to recover the real bootloader code with the real RC4 key, not the incorrect one in the ROM (very nasty trick, kudo's for the Microsoft development team there ;-) ). Ref http://www.xenatera.com/bunnie/proj/anatak/AIM-2002-008.pdf Nevertheless, this is a good example of economically unreasonable attacks: Bunnie spent something like 4 months of his master thesis' time on hacking the Xbox and then gave that knowledge away for free on the internet. 4 months of "honest work" would have bought him that Xbox and all consoles he could have wanted for quite some time... [snip good list of things to consider] > This gives an idea of analyses that drives security-related spendings > (in my limited experience). Clients (intend to) pay for protections that > will prevent financial losses and major public relations impacts (and > then cut operating budgets soon after the project gets its > authorization!). The consultant study must clearly link attackers' > motivations to impacts and to countermeasures. I agree. From commercial point of view, the developer's point of view of side channel analysis protection (and most other protections I think) is I think: Costs: - Additional resources in the device (memory, CPU time). Unless the device is severely resource bound (like a very tight power budget, really limited memory sizes like in a smartcard), this is not really a cost. - Significant and specialized additional development resources to implement the countermeasures well. To do the whole protection, not just the blinding, well is a real engineering effort. It also requires a specific
