Re: [Hipsec] Memory-bound puzzles in BEX

On 05/27/2010 11:33 AM, Miika Komu wrote:
> On 27/05/10 15:18, Tobias Heer wrote:
>
> Hi Tobias,
>
> I'd be leaning a bit towards CPU-bound puzzles but perhaps just 
> because we've been just using them earlier. Big puzzles of both types 
> can be problematic for e.g. sensor devices with limited memory and CPU 
> capabilities, so in that sense it's a tie. Perhaps it's actually 
> battery life (drained by CPU usage) time that seems to suffer from 
> technological advances, so perhaps that could used to promote either 
> of the types.

Some good points. What is memory bound mean to a 8Gb notebook compared 
to a 64K sensor? How do you design a memory bound puzzle that fits each? 
Or does BEX have one and DEX have another?

Battery drain is a dangerous path to go down. Granted that CPU bound 
SHOULD be harder on a battery than memory bound.

>
> The current CPU-based puzzles are parallelizable which means that a 
> bot net could be used for solving a puzzle in a distributed way.

Does this lead to memory bound puzzles as a way to mitigate botnet 
attacks against a puzzle?

> As an alternative, we could also switch to serialized puzzles.

I am not getting what a serialized puzzle is.

> Anyway, I don't think this has big impact - I guess it's ok to 
> distribute the solving in the end.
>
>> Hi everyone,
>>
>> RFC5201 states that memory bound puzzles should be reconsidered for 
>> future versions of the document. The exact text is here:
>>
>> NOTE: The protocol developers explicitly considered whether
>> a memory bound function should be used for the puzzle
>> instead of a CPU-bound function. The decision was not to
>> use memory-bound functions. At the time of the decision, the
>> idea of memory-bound functions was relatively new and their
>> IPR status were unknown. Once there is more experience
>> about memory-bound functions and once their IPR status is
>> better known, it may be reasonable to reconsider this
>> decision.
>>
>> I am asking the list if the time for reconsideration has come. Should 
>> we delve deeper into non CPU-bound puzzles for RFC5201-bis or should 
>> we keep this note for future revisions.
>> Is there anyone with a background on memory-bound puzzles interested 
>> in having them in RFC5201-bis?
>>
>> Best regards,
>>
>> Tobias
>>
>>
>>
>>
>>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>