Jacob Moody:
> I'm very glad we were able to communicate this and thank you for taking
> the time to talk about this here in this thread.
And thanks to you for pointing me to the GTX 4090 and https://crack.sh
Both real eye openers.
--
9fans: 9fans
> My point was only about the advantage of p9sk3 over p9sk1, not to
> compare it with anything else. The intent was to counter the implication
> that p9sk1 is terrible and completely broken, by suggesting that the
One error in our naming is that it might imply dp9ik completely replaced p9sk1.
On 5/13/24 05:18, Richard Miller wrote:
> Jacob and Ori, thank you for filling in some more details. Without
> the specifics I had been making some wrong assumptions about where
> the exact threat was.
>
> I think I now have a clearer picture:
>
> It's not particularly p9sk1 which is vulnerable,
>> (OK, I know that's delusional because I've installed go. But maybe
>> not for much longer, as google seems determined to introduce python3
>> as a dependency.)
>
> wat!??
The Go team is willing to replace the CI builders written in Go by the
Chromium builders, which are written in Python 3.
So
>
> (OK, I know that's delusional because I've installed go. But maybe
> not for much longer, as google seems determined to introduce python3
> as a dependency.)
wat!??
On Mon, 13 May 2024 at 13:48, Richard Miller <9f...@hamnavoe.com> wrote:
> cro...@gmail.com:
> > As for the proposed strawman
cro...@gmail.com:
> As for the proposed strawman `p9sk3`, I fail to see what advantage
> that would have over dp9ik
My point was only about the advantage of p9sk3 over p9sk1, not to
compare it with anything else. The intent was to counter the implication
that p9sk1 is terrible and completely
me:
>> I try to take a
>> minimum-intervention approach ...
cro...@gmail.com:
> Forgive my saying it, Richard, but I think this is a somewhat overly
> staid view of things.
You're welcome to say it. My minimalist attitude amounts to a religion,
and therefore I don't need to justify it ☺. I know
> Have a look at authsrv(6) in the manual. The authenticator sends a
> pair of tickets to the client, one encrypted with the client's own
> key and one encrypted with the server's key. That's what allows
> both the client and server to authenticate each other.
i stand corrected. also i confused
> So, if you have an authentication service exposed to the ipv4
> internet (or to the ipv6 internet with a findable address), and
> your authid or a known or guessable userid has a weak enough
> password to succumb to a dictionary search, it's probably right
> to say that a random attacker could
23h...@gmail.com:
> ... the server and client keys are the
> same in p9sk1 as far as i understood. i would welcome public/private
> key system though (is that what you were thinking of when separating
> "server key" and "client key". that would add yet another set of
> features that are currently
Jacob and Ori, thank you for filling in some more details. Without
the specifics I had been making some wrong assumptions about where
the exact threat was.
I think I now have a clearer picture:
It's not particularly p9sk1 which is vulnerable, but the protocol
for ticket request / response, which
On Sun, May 12, 2024 at 12:44 PM Richard Miller <9f...@hamnavoe.com> wrote:
> 23h...@gmail.com:
> > sorry for ignoring your ideas about a p9sk3, but is your mentioning of
> > ocam's razor implying that dp9ik is too complicated?
> > is there any other reason to stick with DES instead of AES in
> >
On Sun, May 12, 2024 at 02:16:47PM +0100, Richard Miller wrote:
>
> That's quadrillions of years. Not what most people would call "trivial".
> And that's generously assuming the implementation of meet-in-the-middle
> is zero cost. Without meet-in-the-middle, we're looking at a 168-bit
> keyspace
Quoth o...@eigenstate.org:
> Quoth Richard Miller <9f...@hamnavoe.com>:
> > I'm using a new subject [was: Interoperating between 9legacy and 9front]
> > in the hope of continuing discussion of the vulnerability of p9sk1 without
> > too many other distractions.
> >
> > mo...@posixcafe.org said:
>
Quoth Richard Miller <9f...@hamnavoe.com>:
> I'm using a new subject [was: Interoperating between 9legacy and 9front]
> in the hope of continuing discussion of the vulnerability of p9sk1 without
> too many other distractions.
>
> mo...@posixcafe.org said:
> > If we agree that:
> >
> > 1) p9sk1
> I thought of 3DES in the first instance because of this desire to be
> minimally disruptive. Support for DES is already there and tested.
> 3DES only needs extra keys in /mnt/keys, and because 3DES encryption
> with all three keys the same becomes single DES, there's a graceful
> fallback when
23h...@gmail.com:
> sorry for ignoring your ideas about a p9sk3, but is your mentioning of
> ocam's razor implying that dp9ik is too complicated?
> is there any other reason to stick with DES instead of AES in
> particular? i'm not a cryptographer by any means, but just curious.
My comments are
On 5/12/24 08:16, Richard Miller wrote:
> I'm using a new subject [was: Interoperating between 9legacy and 9front]
> in the hope of continuing discussion of the vulnerability of p9sk1 without
> too many other distractions.
>
> mo...@posixcafe.org said:
>> If we agree that:
>>
>> 1) p9sk1 allows
sorry for ignoring your ideas about a p9sk3, but is your mentioning of
ocam's razor implying that dp9ik is too complicated?
is there any other reason to stick with DES instead of AES in
particular? i'm not a cryptographer by any means, but just curious.
On Sun, May 12, 2024 at 3:17 PM Richard
I'm using a new subject [was: Interoperating between 9legacy and 9front]
in the hope of continuing discussion of the vulnerability of p9sk1 without
too many other distractions.
mo...@posixcafe.org said:
> If we agree that:
>
> 1) p9sk1 allows the shared secret to be brute-forced offline.
> 2)
20 matches
Mail list logo
