Brian Candler wrote:
> Ashrith Barthur wrote:
>> 1. There is a bit wise operation that is required between 2 Hex values 
>> and this will only occur if both of them are Integer-Hex or Integer 
>> anything.
> 
> "Integer-Hex" doesn't really mean anything.
> 
> The specification says it works on 32-bit unsigned integer values, and 
> that each 64-byte block of source data is treated as 16 x 32-bit words. 
> You can get this via
> 
>    # data is a 64-byte string
> 
>    w = data.unpack("N16")
>    # now w is an array of 16 Integers
> 
>> For example lets say the string is 'abc'
>> a gives 61 when unpacked in hex. so now. if the array holding this is
>> messageHex and the position of a is [0] then we will have to explicitly 
>> say
>> messageHex[0].hex.to_i this will ensure that it is a integer in hex.
> 
> String#hex will give you an Integer directly; the to_i is superfluous.
> 
> But in any case, the conversion into hex-ascii in the first place is 
> superfluous. Unpack directly to Integers, as shown above.
> 
>> Next thing.. appending strings '0x80' or '0x00' is felt not to be 
>> appropriate by me because.. if you were to use 0x80 or 0x00 then ruby 
>> thinks that its an integer already and you dont need to do any explicit 
>> type casting.
> 
> Sorry, but I am unable to make any sense of that sentence at all. The 
> input data to SHA1 is an arbitary-sized string of bytes (*); the padding 
> algorithm requires you to add more bytes (*) to the end, to achieve 
> alignment into 64-byte blocks. So adding padding bytes is exactly what 
> is required.
> 
> (*) actually an arbitary-sized string of *bits*, but most 
> implementations assume that it's a whole number of bytes, i.e. n*8 bits.
> 
>> Also ruby does not explicitly give you a value in hex if you do any 
>> mathematical or bitwise operation in hex, it always defaults to dec.
> 
> I think you may have lost the distinction between a number, and its 
> external representation.
> 
> Doing a bitwise operation "in hex" or "in decimal" doesn't make any 
> sense. The number is stored internally in binary - this is a digital 
> computer, after all - and the bitwise operations are done on those bits. 
> It is only converted into a hex or decimal representation at the point 
> where you input or output the number.
> 
>   a = 20
>   a.to_s        # converts to string "20"
>   a.to_s(16)    # converts to string "14"
> 
> Anyway, maybe you would like to submit this as a ruby quiz, as you'd 
> probably get some good implementations to look at.
> 
> Brian.

Hi Brian..

Pretty much did on the same lines and Instead of N16 I unpacked it as 
H8*16 just because the display has to be in hex mode.

Additionally.. I am in a tight spot right now. I have coded the complete 
algorithm. I do get the values out, or the digest...

You know how for SHA-1 we need to do a looping for 80 times so that the 
bits are rotated and the a,b,c,d are changed and the keys are used... 
well.. this is the funny thing that happens with my code.

It works perfectly fine with in give the loop 64 times.. that is

for i in 0..63 then moment i say.

for i in 0.79 the code returns with an error saying
"`[]=': index 64 out of string (IndexError)"

I earlier thought that ruby arrays are limited to only 64 of them.. 
which i feel is a stupid assumption on my part, but I just gave it a 
shot and recoded to handle the loop more than 64 but still its does not 
work.

I searched far and wide on the internet and I don't see anyone posting 
this kind of an error .. I really dont get it as to why the code would 
work with 64 loops but not 79 loops.

Is it gotta do with the amount of numbers that are being inserted in 
each value of the array? while unpacking I have defined it as H8*16 so 
does that limit the size of each value in array? would it work if i say 
N16? or is it a completely different error?

-- 
Posted via http://www.ruby-forum.com/.