This paper discusses an e-cash strategy to encourage participation in p2p networks. They compare their approach to existing methods with the intention of reducing the bandwidth and computational overhead of implementing such a system.
The paper focuses on the proposed protocol and makes some assumptions. Although their focus is the protocol, and it is the most important part if the assumptions hold, I will discuss the correctness of their assumptions.
This may really come down to me not accepting that an ecash protocol can work. The authors make the assumption that the reason peers may not participate is bandwidth, but I disagree. Bandwidth is very high for most users and there programs available to choke P2P bandwidth allocation to what is available so it does not disturb other traffic which is important to the user in real time. It certainly is a big factor but not the factor for every user.
A part not really discussed is the economy of such a system. Real economies take a lot of work to maintain. Their proposed system does not address the fact that money must grow with product. That is, with more files being available to trade and more users trading, more ecoin needs to be in circulation. Furthermore, money must also disappear when the amount of product shrinks or the value shrinks. They do not address this very complex problem.
Fluctuation in ecoin value can result in tokens being too scarce in which case users will turn to non token networks like bitTorrent. On the other hand, if tokens are too plentiful: this system provides no extra incentive but only hogs extra bandwidth and computation.
Wednesday, September 26, 2007
Tuesday, September 11, 2007
FERNS
First let me begin with congratulations to Dan for the recognition his work is receiving. I like how the followup paper compares related work; I know that some of that work was not yet published when he wrote his thesis. Some of the points I would like to make about FERNS have already been made, since we have discussed this topic while Dan was still working on it at UMASS, so I may miss some obvious points in this discussion.
Since the FERNS method takes into account two potential uses of the same physical phenomena, there can be some confusion by some readers as to how both identification and RNG can be achieved from the same data. This is apparent if one checks some of the Slashdot postings to FERNS. I understand that the way to extract both is by using different algorithms on the data, since it contains both random and (statistically) static bits (I believe the paper mentions a figure like 96% chance for a 'static' bit to settle to its 'known' value but I may be wrong on the exact number).
Dan uses two terms to refer to the identification number generated by the SRAM. He calls the averaged term a 'known' value, while any individual result of the algorithm on a piece of data is a 'latent' value. This is where I have some confusion to what he is proposing. I understand that this 'known' value would be generated after some trails; this is of course trivial because the bits used for ID have a high probability of settling to either '1' or a '0'.
The part that I'm not sure I fully understand is this: the paper states FERNS can eliminate the need to hold a static ID in some non-volatile memory (it points out the extra manufacturing steps are expensive); however, if you don't have non-volatile memory how can you build up this average?
Before I make myself sound like I only read half the paper, I will point out the paragraph where it discusses how the 'known' and 'latent' IDs are used. Dan writes:
1) SRAM Chip: Hamming Distance identification performed
on 2 latent prints from each of the 5,120 logical SRAM chips
partitions shows a 100% reliable fingerprint. This indicates that
for each of the 10,240 latent prints being considered, the known
print returned by the hamming distance based matching algorithm
(out of 5,120 possibilties) was the known print of the same chip
that had generated the latent print every single time, using
only 8 bytes of initial SRAM state.
Is the above paragraph trying to say that although the 'latent' print is not a 'known' print, but given enough bits they are indistinguishable? If that is the case, perhaps some insight to the algorithm is desirable? Maybe this part needs to be elaborated?
The second part of FERNS is using the data for RNG. Here I have no misunderstanding. While a similar problem occurs here as in the ID part of FERNS, in RNG it is of no consequence. In the case of the ID, the 'random' bits of the SRAM are certainly a problem when generating a static ID, but in the case of RNG the opposite is not true.
Certainly not all the bits are random, in fact (I'm drawing on memory here) I believe the paper states that most bits have a tendency towards either '1' or '0'. This is intuitive since random bits would require nearly no mismatch and mismatch is difficult (if not impossible) to avoid. Therefore a fraction of the bits are random.
The reason this does not pose an issue is because of a property of random numbers. Namely when a random number and non-random number are added or multiplied, the result is still random. While using the DIRECT output of the SRAM would weaken security because some bits would be predictable, if that output is passed through a function that make the output dependent on the data dump of the SRAM, it would be a RANDOM result. The fact that not all bits were random is inconsequential as long as they are operated on by the random bits and this could be achieved without knowing which bits are random and which are static.
In closing, it is a very good paper and I wish Dan the best.
Since the FERNS method takes into account two potential uses of the same physical phenomena, there can be some confusion by some readers as to how both identification and RNG can be achieved from the same data. This is apparent if one checks some of the Slashdot postings to FERNS. I understand that the way to extract both is by using different algorithms on the data, since it contains both random and (statistically) static bits (I believe the paper mentions a figure like 96% chance for a 'static' bit to settle to its 'known' value but I may be wrong on the exact number).
Dan uses two terms to refer to the identification number generated by the SRAM. He calls the averaged term a 'known' value, while any individual result of the algorithm on a piece of data is a 'latent' value. This is where I have some confusion to what he is proposing. I understand that this 'known' value would be generated after some trails; this is of course trivial because the bits used for ID have a high probability of settling to either '1' or a '0'.
The part that I'm not sure I fully understand is this: the paper states FERNS can eliminate the need to hold a static ID in some non-volatile memory (it points out the extra manufacturing steps are expensive); however, if you don't have non-volatile memory how can you build up this average?
Before I make myself sound like I only read half the paper, I will point out the paragraph where it discusses how the 'known' and 'latent' IDs are used. Dan writes:
1) SRAM Chip: Hamming Distance identification performed
on 2 latent prints from each of the 5,120 logical SRAM chips
partitions shows a 100% reliable fingerprint. This indicates that
for each of the 10,240 latent prints being considered, the known
print returned by the hamming distance based matching algorithm
(out of 5,120 possibilties) was the known print of the same chip
that had generated the latent print every single time, using
only 8 bytes of initial SRAM state.
Is the above paragraph trying to say that although the 'latent' print is not a 'known' print, but given enough bits they are indistinguishable? If that is the case, perhaps some insight to the algorithm is desirable? Maybe this part needs to be elaborated?
The second part of FERNS is using the data for RNG. Here I have no misunderstanding. While a similar problem occurs here as in the ID part of FERNS, in RNG it is of no consequence. In the case of the ID, the 'random' bits of the SRAM are certainly a problem when generating a static ID, but in the case of RNG the opposite is not true.
Certainly not all the bits are random, in fact (I'm drawing on memory here) I believe the paper states that most bits have a tendency towards either '1' or '0'. This is intuitive since random bits would require nearly no mismatch and mismatch is difficult (if not impossible) to avoid. Therefore a fraction of the bits are random.
The reason this does not pose an issue is because of a property of random numbers. Namely when a random number and non-random number are added or multiplied, the result is still random. While using the DIRECT output of the SRAM would weaken security because some bits would be predictable, if that output is passed through a function that make the output dependent on the data dump of the SRAM, it would be a RANDOM result. The fact that not all bits were random is inconsequential as long as they are operated on by the random bits and this could be achieved without knowing which bits are random and which are static.
In closing, it is a very good paper and I wish Dan the best.
Subscribe to:
Posts (Atom)
