** On Feb 20, Peter T. Breuer scribbled:
> > > >encrypted_file(fs) -> read_encrypted_chunk
> > > >encrypted_chunk -> send_over_encrypted_link
> > > >remote_end -> receive_double_encrypted_data -> decode_the_transmission_data
> > > >encrypted_chunk_decode -> real_data
> > > >
> > > >The data is out of reach of the local root.
>
> Out of interest, why the encrypted link? I can only imagine it to be of
> use in setting up key pairs. That's one time only. Even then does it
Not always. The keys can be changed during the session at random times to
increase security.
> matter? All data is imported/exported/held on the server encrypted.
> It's only deciphered (-able) on the remote.
But the double encryption further increases security by making intercepting
the encrypted data read from the filesystem even harder.
> > > True, but the problem is that no remote machine exists. This is
> > > a workstation that is used locally, not via a network. That is a
> > > good solution for the remote case however IMHO.
> > In case of local-only, you can always ssh to the local machine when using
>
> Eh? You are suggesting that your entire session take place inside ssh
> in order to protect you from snooping on the same machine!
> Unfortunately, root can see you directly. You type ABC and root can see
> ABC. Yes, he might find it hard to break in to your session (see
> snoopd?). So what?
True, if root will look directly on your application's memory, then we can't
do anything about it, but if the terminal the client uses works in a
(hypothetical) encrypted mode the it would take a truly determined root to
read the transmission even locally. But, true, local connections in that
case would make the transmission encryption practically useless.
> > the protected data. True, the connection encryption key can be spoofed
> > during the ssh negotiation phase, but that's a bit tricky, so it takes a
> > really knowledgeable admin to do it, IMO.
>
> You're suggesting that root pretend to be the encrypted file system?
No, I suggest that root can snoop on the user's connection and intercept the
encryption keys used in the transmission - then he can decrypt everything
on the fly.
marek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:28 EST