phc-discussions - RE: [PHC] Q: int return from PHS()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <003101ce0e6e$d4c2f120$7e48d360$@acm.org>
Date: Mon, 18 Feb 2013 23:00:27 -0800
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
Cc: <jeanphilippe.aumasson@...il.com>
Subject: RE: [PHC] Q: int return from PHS()

What I don't know is which case it is?

I have one response that says the returned int is a result code, with 0 for
success.

I have another response that says the returned int is the size of hash that
was actually produced.

What's intended?  Or is it implementation-defined?

 - Dennis

-----Original Message-----
From: Jean-Philippe Aumasson [mailto:jeanphilippe.aumasson@...il.com] 
Sent: Monday, February 18, 2013 22:43
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Q: int return from PHS()

On Mon, Feb 18, 2013 at 10:26 PM, Dennis E. Hamilton
<dennis.hamilton@....org> wrote:
> !? (glad I asked)
>
> If PHS( ) returns the length of the data delivered in the output buffer,
type disharmony is avoided by (1) making the result a size_t or (2) making
outlen an int.  In case (1), 0 is probably the failure result.  In case (2)
negative results can signify errors (and 0 is a strange success case?).  I'm
not clear whether (2) is now considered an archaic device.  I'm agnostic
about that.  I just want definiteness.
>
> If PHS( ) returns a straightforward result code (with 0 signifying
success), I would expect that outlen is a request for a specific size of
result and the function should fail if it can't deliver.
>

As the call states, at least the value 16 (i.e., 16 bytes) should be
supported. The function may then return an error (a non-zero value) if
the outlen received is not supported.


> In the case of failure/error in either case, the content of the output
buffer should be considered unpredictable and should also not leak anything.
(If it were up to me, I'd always clear the output buffer at the beginning
and endeavor to leave it that way except just before a success return.)
>

We don't care about such leaks in a reference implementation (as
opposed to a production implementation).

> -----Original Message-----
> From: Steve Thomas [mailto:steve@...tu.com]
> Sent: Monday, February 18, 2013 12:40
> To: discussions@...sword-hashing.net
> Subject: Re: [PHC] Q: int return from PHS()
>
>> On February 18, 2013 at 1:00 PM Samuel Neves <sneves@....uc.pt> wrote:
>>
>>
>> On 18-02-2013 18:46, Dennis E. Hamilton wrote:
>> > Reference implementations for submissions are requested to provide an
API
>> > having signature int PHS( ...)
>> >
>> > What are the prescribed return values and their significance?
>> >
>> > - Dennis
>> >
>> > PS: Sorry if this has been asked. I haven't found the list archive yet.
>> >
>> It has not been asked.
>>
>> In typical C fashion, return value should be 0 for success, and
>> otherwise for any error that may occur during computation. Error codes,
>> if any, should be up to implementors, since sources of error may wildly
>> vary between schemes/implementations.
>
> I was under the impression that the return value was the amount of data
copied to the output buffer.
>