From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45219fb00602060916p5b354e0r@mail.gmail.com> Date: Mon, 6 Feb 2006 18:16:44 +0100 From: =?ISO-8859-1?Q?Llu=EDs_Batlle?= To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Venti and the hash / public key in plan9 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <45219fb00602060836q7aa16bf7q@mail.gmail.com> Topicbox-Message-UUID: f3f15df2-ead0-11e9-9d60-3106f5b1d025 2006/2/6, Russ Cox : > > Hi... I've been reading the papers about Venti. There is an > > explanation about the low probability of the repetition of a hash > > string in a normal-sized nowadays hard disk. Anyway I've don't > > understood what does Venti do when a hash is found in the stored > > blocks, and the contents of the blocks are different (the > > low-probability case). I imagine there is some code which does not > > give a data-loss... Can someone give a small explanation about that? > > It responds to the write RPC with an error. So what should manage that error? The application? Maybe it try a different write size? In fact there should be another application layer between 9p and the RPC for venti, isn't it? (which?) > > > And also about public key management in plan9 for (at least) 9p > > connections. I've seen in the paper regarding Security that there's > > used only Shared-key authentication (p9sk1). Maybe there's something > > new in the actual distribution of plan9. > > p9sk1 is only an authentication protocol. > > Some 9P sessions are encrypted using TLS/SSL. > We just match the SHA1 hash of the remote public key against > a local list of okayed hashes. There is no attempt to > delve into the whole key hierarchy. This is discussed > in the Security paper. Ok, I'll keep on reading it (I didn't finish). > > Russ > Thanks a lot!