| Subject | Re: [Firebird-Architect] RC4 |
|---|---|
| Author | Jim Starkey |
| Post date | 2010-11-14T22:23:53Z |
On 11/14/2010 4:51 PM, Adriano dos Santos Fernandes wrote:
hashes to form digital signatures, which are part of the certificate
system. They aren't feasible for session keys. Also, there is nothing
special about the keys in certificates. The private key is used to
encode the digest (secure hash) of the certificate. The public key is
then used to decode the digest and thus verify the integrity of the
certificate.
None of this has anything to do with session keys. Random session keys
are always the best. What got WEP into trouble was concatenating a 24
bit number of a fixed key. The successful attacks were against the
keys, not the cipher.
was important, was to either require the use of certificates or make
that an option. Personally, I think they are more trouble than they are
worth for database / server interactions, but completely appropriate for
financial transactions.
The exposure to a man in the middle attack is approximately one
billionth the danger of the current system of sending login credentials
in the clear.
Is it your position that certificates should be part of the Firebird
security architecture, or this is just another random objection to doing
something?
> On 14-11-2010 19:08, Jim Starkey wrote:Public key crypto systems (pkcs) are used in conjunction with secure
>> On 11/14/2010 3:26 PM, Adriano dos Santos Fernandes wrote:
>>> On 14-11-2010 18:14, Brad Pepers wrote:
>>>> I'm not a big crypto guy but isn't this subject to man in the middle attacks?
>>>>
>>> It is, of course. :)
>>>
>>> To fix this problem it's necessary to have trust-able keys, not random
>>> ones generated at each connection.
>>>
>> I don't know what you mean by "trust-able keys". Could you explain what
>> you mean and what they do?
>>
> Keys signed by trust-able authorities, i.e., "ceritifcate"d and that the
> owner is recognized by the client.
hashes to form digital signatures, which are part of the certificate
system. They aren't feasible for session keys. Also, there is nothing
special about the keys in certificates. The private key is used to
encode the digest (secure hash) of the certificate. The public key is
then used to decode the digest and thus verify the integrity of the
certificate.
None of this has anything to do with session keys. Random session keys
are always the best. What got WEP into trouble was concatenating a 24
bit number of a fixed key. The successful attacks were against the
keys, not the cipher.
> Or the client could have a preloaded public key of the server it trust.Yes, and I said that. And the way to fixed that, if people thought it
>
> I don't see these approach on what you described, in fact you described
> as it don't have this. So yes, it's susceptible to man in the middle
> attacks.
was important, was to either require the use of certificates or make
that an option. Personally, I think they are more trouble than they are
worth for database / server interactions, but completely appropriate for
financial transactions.
The exposure to a man in the middle attack is approximately one
billionth the danger of the current system of sending login credentials
in the clear.
Is it your position that certificates should be part of the Firebird
security architecture, or this is just another random objection to doing
something?
>
> Adriano
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>