> The attacker simply uses the same IP address as a valid client ???
No, not at all.
The spoofer will never receive a reply from the target to complete the
three-way handshake, and since getting this right involves knowing the
target's next TCP sequence number, not ever getting that reply means
> >> If there's any interest, I have some ideas on how to handle
> >> unattended startup of an encrypted database that we could kick around.
> > I would like to have such a discussion, since I have found the discussion of
> the whole "key holder" discussion a little obtuse and seemingly mixing
>
On 14/11/15 22:16, Jim Starkey wrote:
> While's it possible to fake the originator IP address with UDP, I don't
> think it's possible with TCP.
The attacker simply uses the same IP address as a valid client ???
If the valid client is offline, that's a simple attack. However, chances
are valid ad
14.11.2015 23:16, Jim Starkey wrote:
> So here's a simple scheme. The basic idea of a redundant set of
> lightweight key servers running at various points in the network. When a
> database wants to start up, it runs through a list of key server
> addresses looking for one that is actually running.
On 11/14/2015 3:51 PM, Leyne, Sean wrote:
> Jim,
>
>> If there's any interest, I have some ideas on how to handle unattended
>> startup of an encrypted database that we could kick around.
> I would like to have such a discussion, since I have found the discussion of
> the whole "key holder" discus
Jim,
> If there's any interest, I have some ideas on how to handle unattended
> startup of an encrypted database that we could kick around.
I would like to have such a discussion, since I have found the discussion of
the whole "key holder" discussion a little obtuse and seemingly mixing remote
On 11/14/2015 9:48 AM, Dimitry Sibiryakov wrote:
> 10.11.2015 10:13, Alex Peshkoff wrote:
>> Does anybody see problems with suggested approach?
>> If not - I will add a ticket to the tracker for myself.
> After a good sleeping on it, I'm sure that verify the key by decrypting
> something kept
10.11.2015 10:13, Alex Peshkoff wrote:
> Does anybody see problems with suggested approach?
> If not - I will add a ticket to the tracker for myself.
After a good sleeping on it, I'm sure that verify the key by decrypting
something kept
in DB header is a very bad idea. In fact, it provides to
14.11.2015 3:47, Claudio Valderrama C. wrote:
> can I ask naively why the thing needs to be so complex and now it has to be
> RefCounted, too? Is this a kind of functionality that will be used only by
> the core developers? In this case, it can be as complex as one wishes if
> this makes FB more ob
