Regarding SHA3 issue in library

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Regarding SHA3 issue in library

Kishor Lala

Hello All,

I am using the BC library “bcprov-jdk15on-154.jar” for SHA-3.

According to SHA-3 NIST standard ( FIPS 202 : SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions) and test vectors,  data(Both Input Message and the Padding bytes) is reversed before proceeding to the further processing.

Example:-           
  Data         => C5 => 1100  0101             Reversed  => A3 =>1010 0011

But what we have observed that Bouncy Castle only reversing the Padding Bytes not the Input Message.

Does anyone has seen similar issue?

Is this a issue and already known?  If yes, is there any plan to fix the issue and release new version?

Regards,
Krish

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

David Hook

Hi Krish,

I'm a little confused about this one. Would you mind pointing to an
actual test vector that's failing?

Both the Java and C# versions of these algorithms have been through CAVP
testing now, you can find the certifications
at:

http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html

1.54 shares the same code base (at least for this) as the FIPS API.

Regards,

David

On 23/06/16 21:59, Kishor Lala wrote:

>
> Hello All,
>
> I am using the BC library “bcprov-jdk15on-154.jar” for SHA-3.
>
> According to SHA-3 NIST standard ( FIPS 202 : SHA-3 Standard:
> Permutation-Based Hash and Extendable-Output Functions) and test
> vectors,  data(Both Input Message and the Padding bytes) is reversed
> before proceeding to the further processing.
>
> Example:-          
>   Data         => C5 => 1100  0101             Reversed  => A3 =>1010 0011
>
> But what we have observed that Bouncy Castle only reversing the
> Padding Bytes not the Input Message.
>
> Does anyone has seen similar issue?
>
> Is this a issue and already known?  If yes, is there any plan to fix
> the issue and release new version?
>
> Regards,
> Krish
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

Kishor Lala

Hello David,

Thanks for the reply.

Please see below example of NIST test vector. Output generated by Bouncy Castle 1.54 is not matching with NIST output.   

Algorithm SHA3-224:-

NIST Test Vector :-  http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA3-224_1600.pdf

Test vector Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from NIST example :-

9376816ABA503F72F96CE7EB65AC095DEEE3BE4BF9BBC2A1CB7E11E0

-----------------------------------------------------------------

Bouncy Castle 1.54 :-

Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from Bouncy Castle:-

38BCD8B1C79DD971039586A61C771B7499D2C8EE93C7D3E1FE93B1C2

Regards,

Krish

 

On Jun 24, 2016 3:03 AM, "David Hook" <[hidden email]> wrote:

Hi Krish,

I'm a little confused about this one. Would you mind pointing to an
actual test vector that's failing?

Both the Java and C# versions of these algorithms have been through CAVP
testing now, you can find the certifications
at:

http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html

1.54 shares the same code base (at least for this) as the FIPS API.

Regards,

David

On 23/06/16 21:59, Kishor Lala wrote:
>
> Hello All,
>
> I am using the BC library “bcprov-jdk15on-154.jar” for SHA-3.
>
> According to SHA-3 NIST standard ( FIPS 202 : SHA-3 Standard:
> Permutation-Based Hash and Extendable-Output Functions) and test
> vectors,  data(Both Input Message and the Padding bytes) is reversed
> before proceeding to the further processing.
>
> Example:-
>   Data         => C5 => 1100  0101             Reversed  => A3 =>1010 0011
>
> But what we have observed that Bouncy Castle only reversing the
> Padding Bytes not the Input Message.
>
> Does anyone has seen similar issue?
>
> Is this a issue and already known?  If yes, is there any plan to fix
> the issue and release new version?
>
> Regards,
> Krish
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

David Hook

Ah, okay, if you look on page 27 of FIPS PUB 202 there's a conversion algorithm for taking a SHA3 bit string and converting it into hexadecimal.

The problem you've run into is the bits in the test data are numbered

00 01 02 03 04 05 06 07 10 11 12 13 14 15 16 17 21...

Where the first digit is the byte number. So for the bit string in the file, the hex equivalent is actually "A3A3A3...." I think the rational for it was that it made it easier to explicitly represent partial bytes at the end of a string (as in you just say n0 n1 n2 n3 and you're done).

If the bit string is parsed correctly you will get the correct output. I appreciate this is not obvious.

Regards,

David

On 24/06/16 18:05, Kishor Lala wrote:

Hello David,

Thanks for the reply.

Please see below example of NIST test vector. Output generated by Bouncy Castle 1.54 is not matching with NIST output.   

Algorithm SHA3-224:-

NIST Test Vector :-  http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA3-224_1600.pdf

Test vector Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from NIST example :-

9376816ABA503F72F96CE7EB65AC095DEEE3BE4BF9BBC2A1CB7E11E0

-----------------------------------------------------------------

Bouncy Castle 1.54 :-

Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from Bouncy Castle:-

38BCD8B1C79DD971039586A61C771B7499D2C8EE93C7D3E1FE93B1C2

Regards,

Krish

 

On Jun 24, 2016 3:03 AM, "David Hook" <[hidden email]> wrote:

Hi Krish,

I'm a little confused about this one. Would you mind pointing to an
actual test vector that's failing?

Both the Java and C# versions of these algorithms have been through CAVP
testing now, you can find the certifications
at:

http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html

1.54 shares the same code base (at least for this) as the FIPS API.

Regards,

David

On 23/06/16 21:59, Kishor Lala wrote:
>
> Hello All,
>
> I am using the BC library “bcprov-jdk15on-154.jar” for SHA-3.
>
> According to SHA-3 NIST standard ( FIPS 202 : SHA-3 Standard:
> Permutation-Based Hash and Extendable-Output Functions) and test
> vectors,  data(Both Input Message and the Padding bytes) is reversed
> before proceeding to the further processing.
>
> Example:-
>   Data         => C5 => 1100  0101             Reversed  => A3 =>1010 0011
>
> But what we have observed that Bouncy Castle only reversing the
> Padding Bytes not the Input Message.
>
> Does anyone has seen similar issue?
>
> Is this a issue and already known?  If yes, is there any plan to fix
> the issue and release new version?
>
> Regards,
> Krish
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

Kishor Lala

Hello David,

Thanks for the reply David.

I am still bit confused on algorithm to be used on input and output.  

If I understood correctly,  input test vector bit string need to be converted (C5 -> A3) to hex equivalent by using the h2b (Algo 10 mentioned in page 26, though the algo name suggest hex to bit string) and the SHA-3 output need to be converted to bit string by using the b2h (Algo 11 mentioned in page 27).  May be I am bit obvious here or completely wrong. Please share a example if I going in wrong direction.
 
Also it is not clear whether these algorithm (b2h, h2b) should be part of the SHA-3 core library implementation.  I guess, Bouncy Castle expect input data to be in the form of hex equivalent of bit string. Similarly hex output generated by Bouncy Castle need to be converted to bit string.  So it seems that, algo(b2h and h2b) will not be part of SHA-3 implementation and the application using the SHA-3 should provide the input in hex and application need to parse the hex output to get bit string.

Thanks and Regards,
Krish

 


Ah, okay, if you look on page 27 of FIPS PUB 202 there's a conversion algorithm for taking a SHA3 bit string and converting it into hexadecimal.

The problem you've run into is the bits in the test data are numbered

00 01 02 03 04 05 06 07 10 11 12 13 14 15 16 17 21...

Where the first digit is the byte number. So for the bit string in the file, the hex equivalent is actually "A3A3A3...." I think the rational for it was that it made it easier to explicitly represent partial bytes at the end of a string (as in you just say n0 n1 n2 n3 and you're done).

If the bit string is parsed correctly you will get the correct output. I appreciate this is not obvious.

Regards,

David

On 24/06/16 18:05, Kishor Lala wrote:

Hello David,

Thanks for the reply.

Please see below example of NIST test vector. Output generated by Bouncy Castle 1.54 is not matching with NIST output.   

Algorithm SHA3-224:-

NIST Test Vector :-  http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA3-224_1600.pdf

Test vector Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from NIST example :-

9376816ABA503F72F96CE7EB65AC095DEEE3BE4BF9BBC2A1CB7E11E0

-----------------------------------------------------------------

Bouncy Castle 1.54 :-

Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from Bouncy Castle:-

38BCD8B1C79DD971039586A61C771B7499D2C8EE93C7D3E1FE93B1C2

Regards,

Krish

 

On Jun 24, 2016 3:03 AM, "David Hook" <[hidden email]> wrote:

Hi Krish,

I'm a little confused about this one. Would you mind pointing to an
actual test vector that's failing?

Both the Java and C# versions of these algorithms have been through CAVP
testing now, you can find the certifications
at:

http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html

1.54 shares the same code base (at least for this) as the FIPS API.

Regards,

David

On 23/06/16 21:59, Kishor Lala wrote:
>
> Hello All,
>
> I am using the BC library “bcprov-jdk15on-154.jar” for SHA-3.
>
> According to SHA-3 NIST standard ( FIPS 202 : SHA-3 Standard:
> Permutation-Based Hash and Extendable-Output Functions) and test
> vectors,  data(Both Input Message and the Padding bytes) is reversed
> before proceeding to the further processing.
>
> Example:-
>   Data         => C5 => 1100  0101             Reversed  => A3 =>1010 0011
>
> But what we have observed that Bouncy Castle only reversing the
> Padding Bytes not the Input Message.
>
> Does anyone has seen similar issue?
>
> Is this a issue and already known?  If yes, is there any plan to fix
> the issue and release new version?
>
> Regards,
> Krish
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

David Hook

Hi Krish,

The BC API is designed to process and produce byte strings.

As an example:

Msg = 3776c716154949

SHA3-224 = a6d0469626dcff199f8d3316f2265e166717300f0cc5f68de401f8db
SHA3-256 = 93c567dea903a818d2265173556da3e0348dc6f0e49177ea1459801cd9c2767c
SHA3-384 = 57626b6190616f133f76b25db0cabe9e2a51d18116af39ee704d389bf633fbbf3e0ab9bdabc4aaf0b3e2e6a054a1486c

The SHA3-224 result is also from a NIST test vector, but one described in hex.

Regards,

David

On 28/06/16 16:57, Kishor Lala wrote:

Hello David,

Thanks for the reply David.

I am still bit confused on algorithm to be used on input and output.  

If I understood correctly,  input test vector bit string need to be converted (C5 -> A3) to hex equivalent by using the h2b (Algo 10 mentioned in page 26, though the algo name suggest hex to bit string) and the SHA-3 output need to be converted to bit string by using the b2h (Algo 11 mentioned in page 27).  May be I am bit obvious here or completely wrong. Please share a example if I going in wrong direction.
 
Also it is not clear whether these algorithm (b2h, h2b) should be part of the SHA-3 core library implementation.  I guess, Bouncy Castle expect input data to be in the form of hex equivalent of bit string. Similarly hex output generated by Bouncy Castle need to be converted to bit string.  So it seems that, algo(b2h and h2b) will not be part of SHA-3 implementation and the application using the SHA-3 should provide the input in hex and application need to parse the hex output to get bit string.

Thanks and Regards,
Krish

 


Ah, okay, if you look on page 27 of FIPS PUB 202 there's a conversion algorithm for taking a SHA3 bit string and converting it into hexadecimal.

The problem you've run into is the bits in the test data are numbered

00 01 02 03 04 05 06 07 10 11 12 13 14 15 16 17 21...

Where the first digit is the byte number. So for the bit string in the file, the hex equivalent is actually "A3A3A3...." I think the rational for it was that it made it easier to explicitly represent partial bytes at the end of a string (as in you just say n0 n1 n2 n3 and you're done).

If the bit string is parsed correctly you will get the correct output. I appreciate this is not obvious.

Regards,

David

On 24/06/16 18:05, Kishor Lala wrote:

Hello David,

Thanks for the reply.

Please see below example of NIST test vector. Output generated by Bouncy Castle 1.54 is not matching with NIST output.   

Algorithm SHA3-224:-

NIST Test Vector :-  http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA3-224_1600.pdf

Test vector Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from NIST example :-

9376816ABA503F72F96CE7EB65AC095DEEE3BE4BF9BBC2A1CB7E11E0

-----------------------------------------------------------------

Bouncy Castle 1.54 :-

Input Message:- “C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5”

Output from Bouncy Castle:-

38BCD8B1C79DD971039586A61C771B7499D2C8EE93C7D3E1FE93B1C2

Regards,

Krish

 

On Jun 24, 2016 3:03 AM, "David Hook" <[hidden email]> wrote:

Hi Krish,

I'm a little confused about this one. Would you mind pointing to an
actual test vector that's failing?

Both the Java and C# versions of these algorithms have been through CAVP
testing now, you can find the certifications
at:

http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html

1.54 shares the same code base (at least for this) as the FIPS API.

Regards,

David

On 23/06/16 21:59, Kishor Lala wrote:
>
> Hello All,
>
> I am using the BC library “bcprov-jdk15on-154.jar” for SHA-3.
>
> According to SHA-3 NIST standard ( FIPS 202 : SHA-3 Standard:
> Permutation-Based Hash and Extendable-Output Functions) and test
> vectors,  data(Both Input Message and the Padding bytes) is reversed
> before proceeding to the further processing.
>
> Example:-
>   Data         => C5 => 1100  0101             Reversed  => A3 =>1010 0011
>
> But what we have observed that Bouncy Castle only reversing the
> Padding Bytes not the Input Message.
>
> Does anyone has seen similar issue?
>
> Is this a issue and already known?  If yes, is there any plan to fix
> the issue and release new version?
>
> Regards,
> Krish
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

Kishor Lala

Hi David,

Thanks for the reply.

BC API takes the inputs in byte string and generates the output in byte string.
In order to match NIST example output with BC output, i understood that BC output byte string need to be converted in hex by using b2h algo 11.

Regards,
Krish

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

David Hook

No.

Regards,

David

On 29/06/16 23:41, Kishor Lala wrote:

>
> Hi David,
>
> Thanks for the reply.
>
> BC API takes the inputs in byte string and generates the output in
> byte string.
> In order to match NIST example output with BC output, i understood
> that BC output byte string need to be converted in hex by using b2h
> algo 11.
>
> Regards,
> Krish
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

Kishor Lala

Hi David,

So, do we need to convert NIST hex output to byte string?

Regards,
Krish

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

David Hook

Hi Krish,

I'm still a bit confused about what you are asking - I can say the BC
implementation is correct.

Regards,

David

On 30/06/16 13:02, Kishor Lala wrote:
>
> Hi David,
>
> So, do we need to convert NIST hex output to byte string?
>
> Regards,
> Krish
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regarding SHA3 issue in library

Kishor Lala

Hello David,

Ok let me explain with some more details. In our SHA3 implementation, if we give the input in format (A3A3A3…) of the NIST example message bit string ( Msg as bit string 11000101 11000101…) we get the output which matches with BC library generated output.  So here it means BC library also taking the input in hex equivalent format (A3A3..). But the problem is that BC library generated output and our SHA3 implementation generated output doesn’t match with the NIST example output. Do we need to convert BC output?

Regards,
Krish

On Jun 30, 2016 1:07 PM, "David Hook" <[hidden email]> wrote:

Hi Krish,

I'm still a bit confused about what you are asking - I can say the BC
implementation is correct.

Regards,

David

On 30/06/16 13:02, Kishor Lala wrote:
>
> Hi David,
>
> So, do we need to convert NIST hex output to byte string?
>
> Regards,
> Krish
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Regarding SHA3 issue in library

Eckenfels. Bernd

There is no such thing as hex representation or output in BC, it works on raw byte[] arrays (which is conceptually a bit string as long as you use multiples of 8 bit).

 

The string representation of the NIST test vectors are purely for having a robust textual representation in the test suite, they typically are not used anywhere else (and not offered by BC as I see it).

 

Gruss

Bernd

 

 

 

From: Kishor Lala [mailto:[hidden email]]
Sent: Thursday, June 30, 2016 9:45 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [dev-crypto] Regarding SHA3 issue in library

 

Hello David,

Ok let me explain with some more details. In our SHA3 implementation, if we give the input in format (A3A3A3…) of the NIST example message bit string ( Msg as bit string 11000101 11000101…) we get the output which matches with BC library generated output.  So here it means BC library also taking the input in hex equivalent format (A3A3..). But the problem is that BC library generated output and our SHA3 implementation generated output doesn’t match with the NIST example output. Do we need to convert BC output?

Regards,
Krish

On Jun 30, 2016 1:07 PM, "David Hook" <[hidden email]> wrote:


Hi Krish,

I'm still a bit confused about what you are asking - I can say the BC
implementation is correct.

Regards,

David

On 30/06/16 13:02, Kishor Lala wrote:
>
> Hi David,
>
> So, do we need to convert NIST hex output to byte string?
>
> Regards,
> Krish
>






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Loading...