2001-09-23 04:12:44 +00:00
|
|
|
/*
|
|
|
|
* Written by Solar Designer and placed in the public domain.
|
|
|
|
* See crypt_blowfish.c for more information.
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* contrib/pgcrypto/crypt-gensalt.c
|
2006-03-11 04:38:42 +00:00
|
|
|
*
|
2001-09-23 04:12:44 +00:00
|
|
|
* This file contains salt generation functions for the traditional and
|
|
|
|
* other common crypt(3) algorithms, except for bcrypt which is defined
|
|
|
|
* entirely in crypt_blowfish.c.
|
|
|
|
*
|
|
|
|
* Put bcrypt generator also here as crypt-blowfish.c
|
2014-05-06 12:12:18 -04:00
|
|
|
* may not be compiled always. -- marko
|
2001-09-23 04:12:44 +00:00
|
|
|
*/
|
|
|
|
|
2001-10-15 19:15:18 +00:00
|
|
|
#include "postgres.h"
|
|
|
|
|
2001-09-23 04:12:44 +00:00
|
|
|
#include "px-crypt.h"
|
|
|
|
|
|
|
|
typedef unsigned int BF_word;
|
|
|
|
|
2006-07-13 04:15:25 +00:00
|
|
|
static unsigned char _crypt_itoa64[64 + 1] =
|
2001-10-25 05:50:21 +00:00
|
|
|
"./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
|
2001-09-23 04:12:44 +00:00
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
char *
|
|
|
|
_crypt_gensalt_traditional_rn(unsigned long count,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 15:35:54 -04:00
|
|
|
const char *input, int size, char *output, int output_size)
|
2001-09-23 04:12:44 +00:00
|
|
|
{
|
2001-10-25 05:50:21 +00:00
|
|
|
if (size < 2 || output_size < 2 + 1 || (count && count != 25))
|
|
|
|
{
|
|
|
|
if (output_size > 0)
|
|
|
|
output[0] = '\0';
|
2001-09-23 04:12:44 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
output[0] = _crypt_itoa64[(unsigned int) input[0] & 0x3f];
|
|
|
|
output[1] = _crypt_itoa64[(unsigned int) input[1] & 0x3f];
|
2001-09-23 04:12:44 +00:00
|
|
|
output[2] = '\0';
|
|
|
|
|
|
|
|
return output;
|
|
|
|
}
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
char *
|
|
|
|
_crypt_gensalt_extended_rn(unsigned long count,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 15:35:54 -04:00
|
|
|
const char *input, int size, char *output, int output_size)
|
2001-09-23 04:12:44 +00:00
|
|
|
{
|
|
|
|
unsigned long value;
|
|
|
|
|
|
|
|
/* Even iteration counts make it easier to detect weak DES keys from a look
|
|
|
|
* at the hash, so they should be avoided */
|
|
|
|
if (size < 3 || output_size < 1 + 4 + 4 + 1 ||
|
2001-10-25 05:50:21 +00:00
|
|
|
(count && (count > 0xffffff || !(count & 1))))
|
|
|
|
{
|
|
|
|
if (output_size > 0)
|
|
|
|
output[0] = '\0';
|
2001-09-23 04:12:44 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
if (!count)
|
|
|
|
count = 725;
|
2001-09-23 04:12:44 +00:00
|
|
|
|
|
|
|
output[0] = '_';
|
|
|
|
output[1] = _crypt_itoa64[count & 0x3f];
|
|
|
|
output[2] = _crypt_itoa64[(count >> 6) & 0x3f];
|
|
|
|
output[3] = _crypt_itoa64[(count >> 12) & 0x3f];
|
|
|
|
output[4] = _crypt_itoa64[(count >> 18) & 0x3f];
|
2006-10-04 00:30:14 +00:00
|
|
|
value = (unsigned long) (unsigned char) input[0] |
|
|
|
|
((unsigned long) (unsigned char) input[1] << 8) |
|
|
|
|
((unsigned long) (unsigned char) input[2] << 16);
|
2001-09-23 04:12:44 +00:00
|
|
|
output[5] = _crypt_itoa64[value & 0x3f];
|
|
|
|
output[6] = _crypt_itoa64[(value >> 6) & 0x3f];
|
|
|
|
output[7] = _crypt_itoa64[(value >> 12) & 0x3f];
|
|
|
|
output[8] = _crypt_itoa64[(value >> 18) & 0x3f];
|
|
|
|
output[9] = '\0';
|
|
|
|
|
|
|
|
return output;
|
|
|
|
}
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
char *
|
|
|
|
_crypt_gensalt_md5_rn(unsigned long count,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 15:35:54 -04:00
|
|
|
const char *input, int size, char *output, int output_size)
|
2001-09-23 04:12:44 +00:00
|
|
|
{
|
|
|
|
unsigned long value;
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
if (size < 3 || output_size < 3 + 4 + 1 || (count && count != 1000))
|
|
|
|
{
|
|
|
|
if (output_size > 0)
|
|
|
|
output[0] = '\0';
|
2001-09-23 04:12:44 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
output[0] = '$';
|
|
|
|
output[1] = '1';
|
|
|
|
output[2] = '$';
|
2006-10-04 00:30:14 +00:00
|
|
|
value = (unsigned long) (unsigned char) input[0] |
|
|
|
|
((unsigned long) (unsigned char) input[1] << 8) |
|
|
|
|
((unsigned long) (unsigned char) input[2] << 16);
|
2001-09-23 04:12:44 +00:00
|
|
|
output[3] = _crypt_itoa64[value & 0x3f];
|
|
|
|
output[4] = _crypt_itoa64[(value >> 6) & 0x3f];
|
|
|
|
output[5] = _crypt_itoa64[(value >> 12) & 0x3f];
|
|
|
|
output[6] = _crypt_itoa64[(value >> 18) & 0x3f];
|
|
|
|
output[7] = '\0';
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
if (size >= 6 && output_size >= 3 + 4 + 4 + 1)
|
|
|
|
{
|
2006-10-04 00:30:14 +00:00
|
|
|
value = (unsigned long) (unsigned char) input[3] |
|
|
|
|
((unsigned long) (unsigned char) input[4] << 8) |
|
|
|
|
((unsigned long) (unsigned char) input[5] << 16);
|
2001-09-23 04:12:44 +00:00
|
|
|
output[7] = _crypt_itoa64[value & 0x3f];
|
|
|
|
output[8] = _crypt_itoa64[(value >> 6) & 0x3f];
|
|
|
|
output[9] = _crypt_itoa64[(value >> 12) & 0x3f];
|
|
|
|
output[10] = _crypt_itoa64[(value >> 18) & 0x3f];
|
|
|
|
output[11] = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
return output;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static unsigned char BF_itoa64[64 + 1] =
|
2001-10-25 05:50:21 +00:00
|
|
|
"./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
|
2001-09-23 04:12:44 +00:00
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
static void
|
2009-06-11 14:49:15 +00:00
|
|
|
BF_encode(char *dst, const BF_word *src, int size)
|
2001-09-23 04:12:44 +00:00
|
|
|
{
|
2011-09-11 21:54:32 +03:00
|
|
|
const unsigned char *sptr = (const unsigned char *) src;
|
|
|
|
const unsigned char *end = sptr + size;
|
2001-10-25 05:50:21 +00:00
|
|
|
unsigned char *dptr = (unsigned char *) dst;
|
|
|
|
unsigned int c1,
|
|
|
|
c2;
|
2001-09-23 04:12:44 +00:00
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
do
|
|
|
|
{
|
2001-09-23 04:12:44 +00:00
|
|
|
c1 = *sptr++;
|
|
|
|
*dptr++ = BF_itoa64[c1 >> 2];
|
|
|
|
c1 = (c1 & 0x03) << 4;
|
2001-10-25 05:50:21 +00:00
|
|
|
if (sptr >= end)
|
|
|
|
{
|
2001-09-23 04:12:44 +00:00
|
|
|
*dptr++ = BF_itoa64[c1];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
c2 = *sptr++;
|
|
|
|
c1 |= c2 >> 4;
|
|
|
|
*dptr++ = BF_itoa64[c1];
|
|
|
|
c1 = (c2 & 0x0f) << 2;
|
2001-10-25 05:50:21 +00:00
|
|
|
if (sptr >= end)
|
|
|
|
{
|
2001-09-23 04:12:44 +00:00
|
|
|
*dptr++ = BF_itoa64[c1];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
c2 = *sptr++;
|
|
|
|
c1 |= c2 >> 6;
|
|
|
|
*dptr++ = BF_itoa64[c1];
|
|
|
|
*dptr++ = BF_itoa64[c2 & 0x3f];
|
|
|
|
} while (sptr < end);
|
|
|
|
}
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
char *
|
|
|
|
_crypt_gensalt_blowfish_rn(unsigned long count,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 15:35:54 -04:00
|
|
|
const char *input, int size, char *output, int output_size)
|
2001-09-23 04:12:44 +00:00
|
|
|
{
|
|
|
|
if (size < 16 || output_size < 7 + 22 + 1 ||
|
2001-10-25 05:50:21 +00:00
|
|
|
(count && (count < 4 || count > 31)))
|
|
|
|
{
|
|
|
|
if (output_size > 0)
|
|
|
|
output[0] = '\0';
|
2001-09-23 04:12:44 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2001-10-25 05:50:21 +00:00
|
|
|
if (!count)
|
|
|
|
count = 5;
|
2001-09-23 04:12:44 +00:00
|
|
|
|
|
|
|
output[0] = '$';
|
|
|
|
output[1] = '2';
|
|
|
|
output[2] = 'a';
|
|
|
|
output[3] = '$';
|
|
|
|
output[4] = '0' + count / 10;
|
|
|
|
output[5] = '0' + count % 10;
|
|
|
|
output[6] = '$';
|
|
|
|
|
2011-09-11 21:54:32 +03:00
|
|
|
BF_encode(&output[7], (const BF_word *) input, 16);
|
2001-09-23 04:12:44 +00:00
|
|
|
output[7 + 22] = '\0';
|
|
|
|
|
|
|
|
return output;
|
|
|
|
}
|
2025-04-05 19:16:58 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Helper for _crypt_gensalt_sha256_rn and _crypt_gensalt_sha512_rn
|
|
|
|
*/
|
|
|
|
static char *
|
|
|
|
_crypt_gensalt_sha(unsigned long count,
|
|
|
|
const char *input, int size, char *output, int output_size)
|
|
|
|
{
|
|
|
|
char *s_ptr = output;
|
|
|
|
unsigned int result_bufsize = PX_SHACRYPT_SALT_BUF_LEN;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/* output buffer must be allocated with PX_MAX_SALT_LEN bytes */
|
|
|
|
if (PX_MAX_SALT_LEN < result_bufsize)
|
|
|
|
ereport(ERROR,
|
|
|
|
errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
errmsg("invalid size of salt"));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Care must be taken to not exceed the buffer size allocated for the
|
|
|
|
* input character buffer.
|
|
|
|
*/
|
|
|
|
if ((PX_SHACRYPT_SALT_MAX_LEN != size) || (output_size < size))
|
|
|
|
ereport(ERROR,
|
|
|
|
errcode(ERRCODE_INTERNAL_ERROR),
|
|
|
|
errmsg("invalid length of salt buffer"));
|
|
|
|
|
|
|
|
/* Skip magic bytes, set by callers */
|
|
|
|
s_ptr += 3;
|
2025-04-08 19:12:03 +02:00
|
|
|
if ((rc = pg_snprintf(s_ptr, 18, "rounds=%lu$", count)) <= 0)
|
2025-04-05 19:16:58 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
errcode(ERRCODE_INTERNAL_ERROR),
|
|
|
|
errmsg("cannot format salt string"));
|
|
|
|
|
|
|
|
/* s_ptr should now be positioned at the start of the salt string */
|
|
|
|
s_ptr += rc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Normalize salt string
|
|
|
|
*
|
|
|
|
* size of input buffer was checked above to not exceed
|
|
|
|
* PX_SHACRYPT_SALT_LEN_MAX.
|
|
|
|
*/
|
|
|
|
for (int i = 0; i < size; i++)
|
|
|
|
{
|
|
|
|
*s_ptr = _crypt_itoa64[input[i] & 0x3f];
|
|
|
|
s_ptr++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We're done */
|
|
|
|
return output;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* gen_list->gen function for sha512 */
|
|
|
|
char *
|
|
|
|
_crypt_gensalt_sha512_rn(unsigned long count,
|
|
|
|
char const *input, int size,
|
|
|
|
char *output, int output_size)
|
|
|
|
{
|
|
|
|
memset(output, 0, output_size);
|
|
|
|
/* set magic byte for sha512crypt */
|
|
|
|
output[0] = '$';
|
|
|
|
output[1] = '6';
|
|
|
|
output[2] = '$';
|
|
|
|
|
|
|
|
return _crypt_gensalt_sha(count, input, size, output, output_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* gen_list->gen function for sha256 */
|
|
|
|
char *
|
|
|
|
_crypt_gensalt_sha256_rn(unsigned long count,
|
|
|
|
const char *input, int size,
|
|
|
|
char *output, int output_size)
|
|
|
|
{
|
|
|
|
memset(output, 0, output_size);
|
|
|
|
/* set magic byte for sha256crypt */
|
|
|
|
output[0] = '$';
|
|
|
|
output[1] = '5';
|
|
|
|
output[2] = '$';
|
|
|
|
|
|
|
|
return _crypt_gensalt_sha(count, input, size, output, output_size);
|
|
|
|
}
|