Hi Dan,
Sorry for keep posting broken English.
I shouldn't difficult.
>
It shouldn't be difficult.
Looking forward more than handful, useful and common hash_hkdf()
application
examples for PHP that justify the API. If you would not like to spend time
for working
code, just ideas are OK also.
R
Hi Dan,
I appreciate your feedback, regardless of your opinion towards this issue.
On Wed, Sep 6, 2017 at 8:04 PM, Dan Ackroyd wrote:
> On 6 September 2017 at 02:15, Yasuo Ohgaki wrote:
> > What should we do for this?
>
> Not us, you.
>
OK. It is recorded that you think current API is totally
On 6 September 2017 at 02:15, Yasuo Ohgaki wrote:
> What should we do for this?
Not us, you.
You should start listening to other people's feedback.
You continually refuse to accept any feedback that doesn't agree with
your world-view, not only on the subject of hkdf, but on validation
and other
Hi all,
This is the last recommendation for hash_hkdf[1]. In fact,
this would be the last chance to fix because we'll have 7.2 soon.
The issue is secure usage and API consistency.
Currently hash_hkdf() has following signature:
hash_hkdf(string $algo , string $ikm [, int $length = 0 [,
string $i
Hi Andrey,
On Thu, Feb 9, 2017 at 7:59 PM, Andrey Andreev wrote:
>
>> I suppose most developers will use 'length' for shorter length.
>> i.e. Weaker output keys. If it's not too short, shorter key length works.
>>
>>
> Shows that you shouldn't be trusted with anything related to cryptography
> e
Hi Scott and all,
On Thu, Feb 9, 2017 at 10:52 PM, Scott Arciszewski
wrote:
>
>
>> HKDF relies on PRK being cryptographically strong.
>>
>>
>
>
>
> Yes, but not for the reasons you might suspect.
>
> The main use case of HKDF is to completely prevent related-key attacks,
> while splitt
On Thu, Feb 9, 2017 at 7:51 AM, Yasuo Ohgaki wrote:
> Hi Andrey,
>
> How the manual page would be. Would it be
>
> "Even though 'slat' is the last optional parameter that users may omit
> easily
> by mistake, users _must_ set strong salt for weak $ikm. This is
> mandatory
> requirement
Hi Andrey,
How the manual page would be. Would it be
"Even though 'slat' is the last optional parameter that users may omit
easily
by mistake, users _must_ set strong salt for weak $ikm. This is
mandatory
requirement for HKDF to work. In addition, it is advices to set salt
whenever
Hi Yasuo,
The fact that you continue to talk about passwords and other low-entropy
data as IKM shows, yet again, that you don't understand HKDF.
It is simply not a password-based KDF; if you want that - use PBKDF2.
Please read Section 4* of the spec:
https://tools.ietf.org/html/rfc5869.html#sectio
Hi all and Scott,
On Wed, Feb 8, 2017 at 11:22 PM, Scott Arciszewski
wrote:
> On Wed, Feb 8, 2017 at 6:27 AM, Andrey Andreev wrote:
>
>> Hi,
>>
>> On Tue, Feb 7, 2017 at 10:22 PM, Scott Arciszewski
>> wrote:
>>
>>>
>>>
>>> Although the RFC itself says that salts are optional, the argument to
>
Hi Andrey,
On Wed, Feb 8, 2017 at 8:27 PM, Andrey Andreev wrote:
> On Tue, Feb 7, 2017 at 10:22 PM, Scott Arciszewski
> wrote:
>
>>
>>
>> Although the RFC itself says that salts are optional, the argument to
>> make them required in PHP's implementation has merit. The only downside is:
>> If yo
On Wed, Feb 8, 2017 at 4:16 AM, Yasuo Ohgaki wrote:
> Hi Scott,
>
> There are applications that do not require salt. In this case, all users
> has to do is
> $salt = NULL
> to omit $salt.
>
Great.
On Wed, Feb 8, 2017 at 6:27 AM, Andrey Andreev wrote:
> Hi,
>
> On Tue, Feb 7, 2017 at 10:22 PM
Hi,
On Tue, Feb 7, 2017 at 10:22 PM, Scott Arciszewski
wrote:
>
>
> Although the RFC itself says that salts are optional, the argument to make
> them required in PHP's implementation has merit. The only downside is: If
> you're integrating with an implementation that doesn't require salts, and
>
Forgot to mention the most important.
On Wed, Feb 8, 2017 at 6:16 PM, Yasuo Ohgaki wrote:
> Is that enough of a downside to dismiss an argument for better security?
> Maybe
I suppose so.
It is very clear that "salt" is the most important for derived key security,
"info" is next, then "length".
Hi Scott,
On Wed, Feb 8, 2017 at 5:22 AM, Scott Arciszewski
wrote:
>
> One such real-world use case: Defuse v1 used HKDF without a salt.
>
> https://github.com/defuse/php-encryption/blob/
> b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L157-L170
> https://github.com/defuse/php-encryption/b
On 2/7/17 3:22 PM, Scott Arciszewski wrote:
One such real-world use case: Defuse v1 used HKDF without a salt.
https://github.com/defuse/php-encryption/blob/b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L157-L170
https://github.com/defuse/php-encryption/blob/b87737b2eec06b13f025cabea847338f
On Tue, Feb 7, 2017 at 2:35 PM, Yasuo Ohgaki wrote:
> Hi Nikita, Andrey and all,
>
Regards,
>
> P.S. I'll be more careful, but I become very sloppy mail reader sometimes.
> I appreciate if you could let know via private email. Thank you!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
Hi,
Hi Nikita, Andrey and all,
My apologies, I misread mails by super sloppy reading.
I'll explain basis by my idea clearly and properly this time.
This mail is long.
Basis of my idea is
- Salt is made to optional only for applications that such value is not
available. (From RFC 5869)
- Omitting sa
18 matches
Mail list logo
