11.05.2021 21:41, Mark Rotteveel wrote:
I assume the G in that paper is a hash function. Otherwise the TomCrypt documentation
doesn't make sense to me: "The hash_idx parameter indicates which hash will be used to
create the PSS encoding.", and it also seems to match what happens in
On 2021-05-11 21:09, Dimitry Sibiryakov wrote:
11.05.2021 18:42, Mark Rotteveel wrote:
As far as I understand PSS, it will hash the message-hash + a
generated salt (+ maybe some more operations)
I see no hash operation in the PSS white paper, only some bit mixing
with salt.
I assume the G
11.05.2021 18:42, Mark Rotteveel wrote:
As far as I understand PSS, it will hash the message-hash + a generated salt (+ maybe some
more operations)
I see no hash operation in the PSS white paper, only some bit mixing with
salt.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
On 11-05-2021 18:34, Dimitry Sibiryakov wrote:
11.05.2021 18:10, Mark Rotteveel wrote:
It doesn't explain why
Ah, now I get it. The function doesn't hash anything itself, this
parameter just inform it which kind of hash it has on input and thus it
must match the hash function used for
11.05.2021 18:10, Mark Rotteveel wrote:
The TomCrypt documentation[1] says:
"""
This will PSS encode the message digest pointed to by in of length inlen octets. Next, the
PSS encoded hash will be RSA signed and the output stored in the buffer pointed to by out
of length outlen octets. The
On 11/05/2021 06:23, Alex Peshkoff via Firebird-devel wrote:
Also note that no implicit client time zone is passed when
DefaultTimeZone is not set. Doing so would create compatibility
problems
with date/time functions for who is not interested in time zones.
>>> May be
On 11-05-2021 17:49, Alex Peshkoff via Firebird-devel wrote:
Please suggest that in admin. I promise to make required changes during
24 hours after decision.
Done
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
I was just browsing the TomCrypt documentation[1], and I noticed the
function `rsa_sign_saltlen_get_max`, documented as
"""
As stated in the PKCS#1 RFC3447 ”Typical salt lengths in octets are hLen
(the length of the output of the hash function Hash) and 0”. This
function is provided to be
On 11-05-2021 17:55, Dimitry Sibiryakov wrote:
11.05.2021 17:41, Mark Rotteveel wrote:
Then I propose to at least rename the function to RSA_SIGN_HASH so it
1) matches the TomCrypt function name it basically calls directly, and
2) makes clear that it doesn't sign a message, but a hash, and
11.05.2021 17:41, Mark Rotteveel wrote:
Then I propose to at least rename the function to RSA_SIGN_HASH so it 1) matches the
TomCrypt function name it basically calls directly, and 2) makes clear that it doesn't
sign a message, but a hash, and sort the rest out later.
But such change raises
11.05.2021 17:46, Alex Peshkoff via Firebird-devel wrote:
With asymmetric crypto algorithms processing data with private key is traditionally called
"encryption" , and processing with public key - "decryption". In this terms signature is
decrypted value of hash, i.e. when signing a message RSA
On 5/11/21 6:41 PM, Mark Rotteveel wrote:
On 11-05-2021 17:33, Alex Peshkoff via Firebird-devel wrote:
On 5/11/21 6:24 PM, Mark Rotteveel wrote:
And I repeat: given RSA_SIGN has a HASH parameter, and applies PSS,
I assume it hashes the message using the supplied (or default) hash
algorithm,
On 5/11/21 6:31 PM, Dimitry Sibiryakov wrote:
11.05.2021 17:26, Alex Peshkoff via Firebird-devel wrote:
To be precise - signature is a decrypted hash of a message, verify
means encrypt it bak - and get same hash.
To be more precise verify is comparison of a hash of the message with
On 11-05-2021 17:33, Alex Peshkoff via Firebird-devel wrote:
On 5/11/21 6:24 PM, Mark Rotteveel wrote:
And I repeat: given RSA_SIGN has a HASH parameter, and applies PSS, I
assume it hashes the message using the supplied (or default) hash
algorithm, and then signs the resulting hash. Having
On 5/11/21 6:24 PM, Mark Rotteveel wrote:
And I repeat: given RSA_SIGN has a HASH parameter, and applies PSS, I
assume it hashes the message using the supplied (or default) hash
algorithm, and then signs the resulting hash. Having to hash this
yourself makes no sense to me.
It _might_ be
11.05.2021 17:26, Alex Peshkoff via Firebird-devel wrote:
To be precise - signature is a decrypted hash of a message, verify means encrypt it bak -
and get same hash.
To be more precise verify is comparison of a hash of the message with decrypted hash
from signature. That's why it is
11.05.2021 17:24, Mark Rotteveel wrote:
Having to hash this yourself makes no sense to me.
Perhaps someone can want signature to use to hash of hash of message thinking that it
is more secure...
--
WBR, SD.
Firebird-Devel mailing list, web interface at
On 5/11/21 6:18 PM, Dimitry Sibiryakov wrote:
11.05.2021 17:13, Alex Peshkoff via Firebird-devel wrote:
Stop-stop. You are mixing crypt and hash in single mix.
No, I don't. I just know what a "signature" is. All of sudden it is
an encrypted hash of the message (and some internal stuff).
On 11-05-2021 16:38, Alex Peshkoff via Firebird-devel wrote:
Depends upon implementation. In tomcrypt rsa_sign_hash() signs message
digests (hashes). I.e. one can't pass somethng long as input. See:
SQL> update test_rsa set encr = rsa_encrypt(K_PRV key k_pub );
Statement failed, SQLSTATE =
11.05.2021 17:13, Alex Peshkoff via Firebird-devel wrote:
Stop-stop. You are mixing crypt and hash in single mix.
No, I don't. I just know what a "signature" is. All of sudden it is an encrypted hash
of the message (and some internal stuff).
--
WBR, SD.
Firebird-Devel mailing list,
On 5/11/21 5:54 PM, Dimitry Sibiryakov wrote:
11.05.2021 16:38, Alex Peshkoff via Firebird-devel wrote:
In tomcrypt rsa_sign_hash() signs message digests (hashes)
Because it is supposed to have hash on input (and this fact is
reflected in its name). Tomcrypt is low-level library and its
11.05.2021 16:38, Alex Peshkoff via Firebird-devel wrote:
In tomcrypt rsa_sign_hash() signs message digests (hashes)
Because it is supposed to have hash on input (and this fact is reflected in its name).
Tomcrypt is low-level library and its user is supposed to do whole high-level work.
On 5/11/21 3:49 PM, Dimitry Sibiryakov wrote:
11.05.2021 14:39, Mark Rotteveel wrote:
On 2021-05-11 11:51, Alex Peshkoff via Firebird-devel wrote:
That may work only for very short (like in a sample) 'Test message'-
for real-size messages hash is used for signing. rsa_sign just would
not work
On 5/11/21 3:36 PM, Mark Rotteveel wrote:
On 2021-05-11 11:44, Alex Peshkoff via Firebird-devel wrote:
On 5/10/21 12:48 PM, Mark Rotteveel wrote:
How was the maximum size of the result of RSA_PRIVATE and RSA_PUBLIC
determined?
To have solid reserve.
A reserve of a factor 3+ for private and
On 11/05/2021 10:25, Gabor Boros wrote:
> 2021.05.11. 15:09 keltezéssel, Adriano dos Santos Fernandes írta:
>>
>> Because the index segment is now prefixed with RDB$PACKAGE_NAME.
>>
>>
>> Adriano
> Nice. And where is the backward compatibility? :-)
> Why modified the old and not a new index for
2021.05.11. 15:09 keltezéssel, Adriano dos Santos Fernandes írta:
Because the index segment is now prefixed with RDB$PACKAGE_NAME.
Adriano
Nice. And where is the backward compatibility? :-)
Why modified the old and not a new index for package+proc names?
Gabor
Firebird-Devel mailing list,
On 11/05/2021 10:05, Gabor Boros wrote:
> Hi All,
>
> I tried with employee...
>
> SQL> select 1 from rdb$procedures where rdb$procedure_name='x';
>
> 2.5.9.27139
> PLAN (RDB$PROCEDURES INDEX (RDB$INDEX_21))
>
> 3.0.8.33468
> PLAN (RDB$PROCEDURES NATURAL)
>
> 4.0.0.2478
> PLAN (RDB$PROCEDURES
Hi All,
I tried with employee...
SQL> select 1 from rdb$procedures where rdb$procedure_name='x';
2.5.9.27139
PLAN (RDB$PROCEDURES INDEX (RDB$INDEX_21))
3.0.8.33468
PLAN (RDB$PROCEDURES NATURAL)
4.0.0.2478
PLAN (RDB$PROCEDURES NATURAL)
Why? :-)
Gabor
Firebird-Devel mailing list, web
11.05.2021 14:39, Mark Rotteveel wrote:
On 2021-05-11 11:51, Alex Peshkoff via Firebird-devel wrote:
That may work only for very short (like in a sample) 'Test message'-
for real-size messages hash is used for signing. rsa_sign just would
not work with too long argument.
Also take into an
On 2021-05-11 11:51, Alex Peshkoff via Firebird-devel wrote:
That may work only for very short (like in a sample) 'Test message'-
for real-size messages hash is used for signing. rsa_sign just would
not work with too long argument.
Also take into an account - different people need different
On 2021-05-11 11:44, Alex Peshkoff via Firebird-devel wrote:
On 5/10/21 12:48 PM, Mark Rotteveel wrote:
How was the maximum size of the result of RSA_PRIVATE and RSA_PUBLIC
determined?
To have solid reserve.
A reserve of a factor 3+ for private and 7+ for public seems a bit
excessive to
On 5/10/21 2:02 PM, Mark Rotteveel wrote:
The example for RSA_SIGN in the release notes is:
```
select rdb$set_context('USER_SESSION', 'msg',
rsa_sign(crypt_hash('Test message' using sha256)
key rdb$get_context('USER_SESSION', 'private_key'))) from
rdb$database;
```
The use of
On 5/10/21 12:48 PM, Mark Rotteveel wrote:
How was the maximum size of the result of RSA_PRIVATE and RSA_PUBLIC
determined?
To have solid reserve.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 5/9/21 8:20 PM, Adriano dos Santos Fernandes wrote:
On 07/05/2021 12:23, Alex Peshkoff via Firebird-devel wrote:
On 5/6/21 9:23 PM, Adriano dos Santos Fernandes wrote:
What I want to ask about if it's clear/good is that DefaultTimeZone set
in client does not implicitly pass
34 matches
Mail list logo
