Dear Prof. Marc Fischlin,
I am sorry to bother you for a couple minutes.
I had read your paper 'The Cramer-Shoup Strong-RSA Signature Scheme Revisited' where it published on PKC 2003, LNCS 2567, pp. 116-129, 2003.
I may misinterpretation some thing.
May I have some questions to ask you please?
Q1:
In page 118. Signing: To sign a message m compute the l-bit hash value H(m) with a collision-intractable hash function H(·).
Does hash function value H(.) a string or a number (integer)?
Q2:
In page 119. Signing: To sign a message m calculate the l-bit hash value H(m) with a collision-intractable hash function H(·). Pick a random (l+1)-bit prime e, a random l-bit string α and compute a representation (-\alpha,-(\alpha xor H(m)), y) of x with respect to h1, h2, e, n, i.e.,
y^{e}= xh_{1}^{\alpha}h_{2}^{\alpha xor H(m)}\pmod{n}.
If hash function value is a number (integer), how did bitwise two different data types H(.) and \alpha?
As you know, only when the parameter α transferred to number (or H(.) transferred to string type), two strings can do bitwise operating.
And then using string-to-intger function (\alpha xor H(.)) changed to the integer (number).
Thank you who had more patient to read my email.
I am looking forward to hear you reply near future.
Best regards and Merry X'mas to you.
> Q1:
> In page 118. Signing: To sign a message m compute the l-bit hash value
> H(m) with a collision-intractable hash function H(·).
> Does hash function value H(.) a string or a number (integer)?
I'm not quite sure if I understand correctly. It's an l-bit hash, so
it's a bit string.
(I think all modern hash functions like SHA-1 are defined over strings.)
> Q2:
> In page 119. Signing: To sign a message m calculate the l-bit hash
> value H(m) with a collision-intractable hash function H(·). Pick a
> random (l+1)-bit prime e, a random l-bit string α and compute a
> representation (-\alpha,-(\alpha xor H(m)), y) of x with respect to
> h1, h2, e, n, i.e.,
> y^{e}= xh_{1}^{\alpha}h_{2}^{\alpha xor H(m)}\pmod{n}.
> If hash function value is a number (integer), how did bitwise two
> different data types H(.) and \alpha?
>
> As you know, only when the parameter α transferred to number (or H(.)
> transferred to string type), two strings can do bitwise operating.
> And then using string-to-intger function (\alpha xor H(.)) changed to
> the integer (number).
Again, I'm not sure if I understand. The values \alpha and H(m) are
originally bit strings, ie,
\alpha xor H(m) is the bitwise exclusive-or of these two strings. Once
you use it in the exponent,
this string needs to be converted to an integer. This is done in the
usual way, the string x=x1..xn
is converted to an integer via x1 + x2 *2 + ..+ xn*2^{n-1}. (Otherwise,
I think that the value h_2
to a string is not really defined, at least I wouldn't know how to
compute h_2^{some string}.)
Does this answer the questions?
Marc Fischlin
===== 信结束 =====
显然, 连 Marc Fischlin 教授 也不能确定他是否真得知道真正的答案。
他只能就大家所接受的那些定义来理解我所提出的问题，并做解释。
我是这样想的,
不管是 bit string 也好, integer 也罢, 在 memory 里都是 一传长串的 data type,
不同的系统,可能解释不同,但本质上的内容还是一样地,
所以, 任何的 bit string , 不论其 data type 是 character 还是 number, 都能转化成 GF(2^{n}) 的型态,
所以, 以这角度来看这个你曾在 74 楼回帖 http://bbs.pediy.com/showpost.php?p=1145202&postcount=74
" 对于构造HASH碰撞很有意义" 就是相同的思路及观点。
