On 8/17/17 17:00, Joe Conway wrote:
>> Hence my original inquiry: "I suspect that this length was chosen based
>> on the example in RFC 5802 (SCRAM-SHA-1) section 5. But the analogous
>> example in RFC 7677 (SCRAM-SHA-256) section 3 uses a length of 16.
>> Should we use that instead?"
> Unless the
On 08/17/2017 01:50 PM, Peter Eisentraut wrote:
> On 8/17/17 12:10, Heikki Linnakangas wrote:
>> On 08/17/2017 05:23 PM, Peter Eisentraut wrote:
>>> On 8/17/17 09:21, Heikki Linnakangas wrote:
The RFC doesn't say anything about salt
length, but the one example in it uses a 16 byte string
On 8/17/17 12:10, Heikki Linnakangas wrote:
> On 08/17/2017 05:23 PM, Peter Eisentraut wrote:
>> On 8/17/17 09:21, Heikki Linnakangas wrote:
>>> The RFC doesn't say anything about salt
>>> length, but the one example in it uses a 16 byte string as the salt.
>>> That's more or less equal to the curr
On 08/17/2017 05:23 PM, Peter Eisentraut wrote:
On 8/17/17 09:21, Heikki Linnakangas wrote:
The RFC doesn't say anything about salt
length, but the one example in it uses a 16 byte string as the salt.
That's more or less equal to the current default of 12 raw bytes, after
base64-encoding.
The
On Thu, Aug 17, 2017 at 10:21 PM, Heikki Linnakangas wrote:
> On 08/17/2017 05:42 AM, Michael Paquier wrote:
>> That's now or never.
>
> Not really. That constant is just the default to use when creating new
> password verifiers, but the code can handle any salt length, and different
> verifiers c
On 8/17/17 09:21, Heikki Linnakangas wrote:
> The RFC doesn't say anything about salt
> length, but the one example in it uses a 16 byte string as the salt.
> That's more or less equal to the current default of 12 raw bytes, after
> base64-encoding.
The example is
S: r=rOprNGfwEbeRWgbNEkqO%
On Thu, Aug 17, 2017 at 9:21 AM, Heikki Linnakangas wrote:
> Different thing. That was the nonce length, now we're talking about salt
> length.
Actually that commit (0557a5dc2cf845639d384801b6861ebbd35dc7ee) changed both:
-#define SCRAM_RAW_NONCE_LEN 10
+#define SCRAM_RAW_NONCE_LEN
On 08/17/2017 04:04 PM, Robert Haas wrote:
On Wed, Aug 16, 2017 at 10:42 PM, Michael Paquier
wrote:
In the initial discussions there was as well a mention about using 16 bytes.
https://www.postgresql.org/message-id/507550bd.2030...@vmware.com
As we are using SCRAM-SHA-256, let's bump it up and
On Wed, Aug 16, 2017 at 10:42 PM, Michael Paquier
wrote:
> In the initial discussions there was as well a mention about using 16 bytes.
> https://www.postgresql.org/message-id/507550bd.2030...@vmware.com
> As we are using SCRAM-SHA-256, let's bump it up and be consistent.
> That's now or never.
T
On 16 August 2017 at 14:10, Peter Eisentraut
wrote:
> The SCRAM salt length is currently set as
>
> /* length of salt when generating new verifiers */
> #define SCRAM_DEFAULT_SALT_LEN 12
>
> without further comment.
>
> I suspect that this length was chosen based on the example in RFC 5802
> (
On Thu, Aug 17, 2017 at 12:10 AM, Aleksander Alekseev
wrote:
>> The SCRAM salt length is currently set as
>>
>> /* length of salt when generating new verifiers */
>> #define SCRAM_DEFAULT_SALT_LEN 12
>>
>> without further comment.
>>
>> I suspect that this length was chosen based on the exampl
He Peter,
> The SCRAM salt length is currently set as
>
> /* length of salt when generating new verifiers */
> #define SCRAM_DEFAULT_SALT_LEN 12
>
> without further comment.
>
> I suspect that this length was chosen based on the example in RFC 5802
> (SCRAM-SHA-1) section 5. But the analog
The SCRAM salt length is currently set as
/* length of salt when generating new verifiers */
#define SCRAM_DEFAULT_SALT_LEN 12
without further comment.
I suspect that this length was chosen based on the example in RFC 5802
(SCRAM-SHA-1) section 5. But the analogous example in RFC 7677
(SCRA
13 matches
Mail list logo
