Skip to main content
Source Link

Is generating semirandom blake256 hashes until packed points is on the curve, a safe algorithm to avoid the discrete log between the generated points?

I know there are more robust methods, but I wanted to know about this specific one

For any distinct said randomly generated point : $P_i,P_j\in \{P_1,...,P_k\}$ it should be hard to find $s$ such that $P_i=s\cdot P_j$.

The points are successfully generated using this inefficient algorithm which is fully deterministic (the first $start\_index$ used and thus next ones are known) :

Return :
    point on the selected twisted Edwards Curve in cartesian coordinates (returns x and y)
Input :
    start_index
Prog :
    begin:
    while(!Is_packed_point_on_the_256_bits_twisted_Edwards_Curve( blake256(start_index)%Selected_Curve_Finite_Field )
        {start_index++}

    found_candidate_point=unpack_point(blake256(start_index)%Selected_Curve_Finite_Field)

    if(IsZero(found_candidate_point))
        {goto begin} // rare in my case, but continue otherwise to try for the next start_index candidates
    else
        {return( Edwards_scalar_multiply(3, unpack_point(blake256(start_index)%Selected_Curve_Finite_Field) ) )

In order to get the next $P_j$ (a different point of the last 1 generated), run the function with the last value of $start\_index$.

So, would it be impossible in such a case to find the discrete logarithm between 2 different points generated from 2 different $start\_index$ without plain discrete logarithm solving that don’t use any trick in how the points are generated ?