please decrypt your manuals

[Doru Georgescu]

--- On Tue, 4/20/10, Keisial <keisial at gmail.com> wrote:

> From: Keisial <keisial at gmail.com>
> Subject: Re: please decrypt your manuals
> To: "Doru Georgescu" <headset001 at yahoo.com>, openssh-unix-dev at mindrot.org
> Date: Tuesday, April 20, 2010, 2:20 PM
> Doru Georgescu wrote:
> > The attacker does not have some private decryption
> key? Anyway, this is too involved for me now, but thank you
> anyway. 
> >
> > Doru 
> >   
> 
> No. The server private key [for the connection] is only
> held on the
> server memory. That's the reason sshd has a "long" startup
> time and is
> unsuitable to spawn a sshd on each connection from inetd.
> Moreover, the server ephemeral key (on ssh v1) is changed
> each
> KeyRegenerationInterval econds, and on ssh v2 RekeyLimit
> establishes
> after how much data transferred the session key (the key
> used connecting
> with this user) is renegotiated.
> 
> It is designed in such way that even if the attacker dumps
> all the
> network packets, and later it is able to compromise the
> machine, it
> still cannot figure out the contents of the transmission
> (this doesn't
> include logs of user actions as .bash_history, breaking in
> the machine
> with a "later" time so short that it can read the daemon
> memory...).

The ephemeral key is what I called the private decryption key, which is used to decrypt messages received by the host (server in this case), right? 

> 
> 
> > Precisely because ssh is the work of a community, it
> is largely meaningless for me to write a manual alone,
> without tight cooperation with that community. The manual
> should transmit information from developers to users. For
> this to happen, a language (symbols, terminology, structure,
> logical implication rules) should be developed. The very
> idea that I can do this alone, outside the developers'
> community, is absurd. Of course such a manual would be
> rejected, because it would not make any sense to the
> developers. 
> >   
> You can improve per sections, so you get immediate feedback
> on how you
> are doing, can correct easier and spend less resources if
> doing bad.
> Being smaller changes, it also eases review.
> 
> Summarising sparse explanations given in a mailing list
> from the
> /cognoscenti/ is a good way of creating documentation. But
> yes, it
> requires quite a bit of struggling to find the right
> information before
> "the perfect manual" can be made.
> 

I am doing this. :) 

>