On Wed, Jun 09, 2010 at 08:55:35PM +0300, Ber Lost wrote:
> Thank you for your answers.
> I have some more questions regarding the procedure.
>
> 1.There is a difference between the result from the demo and the code in
> reference/a51.cpp.The first bit in the 64bit keystream produced from the c++
> code is the xor of the 19th,22nd,23rd bits whereas in the demo it is the xor
> after one clocking.Which one is the correct way?
our original reference code ("A pedagogical implementation of A5/1")
computes the output bit before the clocking and so do we. Except in the
demo which is a bug. Note that the reference code has been verified with
an actual GSM conversation.
>
> 2.Secondly in the demo the first bit of the keystream is in the msb of the
> keystream whereas in the a51.cpp it's in the lsb.Whick arrangement of bits
> in the keystream is the right one to xor with the round function?(I know
> it's just a demo and it's not maximum length either but been wondering about
> this because the next results will be different too.Is it right that
> whatever the arrangement of the bits with the proportional modification of
> the backlocking code will bear the same result internal state?)
the first output bit is combined with the LSBit of the round function LFSR,
that is the bit on the other side of the four taps. The demo does not
cover the round function, so the representation of the keystream does not
matter and it just prints them i a row ordered by time of production.
The round function values are considered opaque random values. So it does
not matter how you combine them with the keystream as long as you do it
consistently. I feel like i missed your point somehow... anyway the round
function is not involved in the backclocking process anymore and neither
is the keystream (except for the verification of candidate states)
>
> 3.What are the specifications of the lfsr used as a round function?I assume
> 64 bits maximum length,tap positions at 63,62,60,59 and initial value 0.If
> this is the case why the first result used to be xored with the keystream is
> FFFFFFFFFFFFFFF6 and not 0000000000000009?Shouldn't it be 9,c3,b6d and so
> on?
the lfsr uses XNOR to combine the taps and each round function is 64 LFSR
clockings apart from the the predecessor round function value. i dont know
how you get 9, c3 and b6d. note that the contents of the LFSR is used,
not an output or the feedback bit recorded 64 times.
>
> 4. From your answer in my previous question i gather that if supposedly I
> have 0xde001bc0006f0000 as a starting point then the first result to be
> checked if it is a dp will be the
> (keystream generated by the a5/1 XOR the first round function value).However
> In the code the xor is applied before the a51 clockings so the first result
> checked(for run=nruns) is the (start point XOR rf) which is then loaded into
> the a51 registers.Which one is the first to be checked as a dp?
the start value of a table chain XOR the round function 0 (the first RF of that
table) is checked for a DP condition (before any A5/1 is applied).
> 5.What do you mean in the code reverse the bit order to account for fpga
> optimization?
The FPGA A5/1 implementation that once once under development was more
efficient if the RF xor KEYSTREAM was inserted from the other side of
R1, R2 and R3 than how it was done in the reference implementation.
since the insertion of the last RF^KS is a 64bit assignment, all bits
are reversed. So either reverse all bits or change clockone() and the
constants R?MASK, R?TAPS, etc. The bit reversing is of course not done
in the production code that runs on the GPU, but there the register layout is
changed accordingly.
>
> I'm sorry for the long post.I would be grateful if you could answer any of
> my questions.Thank you again for your time.
keep em coming!
_______________________________________________
A51 mailing list
[email protected]
http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
