Hi Michael,
On 30 May 2014 15:03, Michael van der Westhuizen michael@smart-africa.com wrote:
Hi Simon,
On 30 May 2014, at 10:50 PM, Simon Glass sjg@chromium.org wrote:
Hi Michael,
On 30 May 2014 14:47, Michael van der Westhuizen michael@smart-africa.com wrote:
Hi Simon,
Thanks for the feedback.
I'll take care of the nits and look into removing some special casing.
On 30 May 2014, at 9:04 PM, Simon Glass sjg@chromium.org wrote:
Hi Michael,
<snip>
/**
- num_pub_exponent_bits() - Number of bits in the public exponent
- @key: RSA key
- @k: Storage for the number of public exponent bits
- */
+static int num_public_exponent_bits(const struct rsa_public_key *key, int *k)
s/k/keyp/ or something like that.
Also is this function able to just use ffs() or similar?
flsll() yes, but that's not portable to Linux.
Does that matter?
This code compiles on the host, so unfortunately yes. That's the same reason I had to work around the lack of handy *_u64 fdt helpers when reading the public exponent.
OK, although Linux might have replacements. But if not, perhaps add a comment as to why you need the helper function.
[snip]
For example, if you did:
montgomery_mul(key, result, val, key->rr); /* acc = a * RR / R mod n */Yes, it's sizeof(uint32_t) - that would probably be a good thing to spell out too.
result points to tmp, which is going to be repeatedly overwritten in the loop, but we need a_scaled to stay constant (as the result of the first montgomery_mul) throughout... or did I misunderstand your point?
OK I see thanks. Perhaps add a new temporary instead of using memcpy()?
And set it up using montgomery_mul? Would that not be more expensive than a memcpy?
On the host? Not sure we care about that. I was really just wondering if an assignment is better than a memcpy() which makes assumptions about the format.
Regards, Simon