July 2018 - cypherpunks-legacy

None
by Asymmetric 05 Jul '18

05 Jul '18

> The D/H is going to be used just to generate a key to securely transfer a > 4096 bit key for use in symmetrical crypto routines later in the program, You want to use a 4096-bit key for SYMMETRICAL crypto? Hello? Not only I don't know of ANY symmetrical algorithm with such a key, but why on Earth would you need it for? What attack do you know against a 128-bit or even 256-bit key that doesn't work against a 4096-bit one? > for actual encryption of the chat/voice/file data transfers. Using 1024 > bits of D/H is fine to generate a key-encryption key to just transfer the > 4096bit key. I chose 4096 because it's large enough to be used in any > symmetric crypto algorithm to max out it's key length. What symmetric crypto algorithm is that? > >The bigger risk, though, is the quality of random numbers available > >for seeding your DH keys. Don't even DREAM of using Delphi's builtins, > >if it has them - go find good crypto-quality-randomness work to reuse, > >unless you know you'll only run on Linux where there's /dev/random. > >At least use sound-card noise or user-entered mouse tracks to help. > >Lots of "secure" systems have been cracked by cracking their random seeds. > > Of course. ;) Did I mention that I wrote a Yarrow implementation in Delphi? <g> It passes DIEHARD, but it hasn't been otherwise checked. [Public domain, btw.] > First, It's GPL'd, or under a modified version of the GPL. I find the GPL > to be distasteful and it forms a barrier more than a bridge to continued > software development. I like this guy :) [All my code is public domain, but I hate the GPL for *forcing* people to share. Communism at its best.] Mark

1 0

None
by Asymmetric 05 Jul '18

05 Jul '18

> The D/H is going to be used just to generate a key to securely transfer a > 4096 bit key for use in symmetrical crypto routines later in the program, You want to use a 4096-bit key for SYMMETRICAL crypto? Hello? Not only I don't know of ANY symmetrical algorithm with such a key, but why on Earth would you need it for? What attack do you know against a 128-bit or even 256-bit key that doesn't work against a 4096-bit one? > for actual encryption of the chat/voice/file data transfers. Using 1024 > bits of D/H is fine to generate a key-encryption key to just transfer the > 4096bit key. I chose 4096 because it's large enough to be used in any > symmetric crypto algorithm to max out it's key length. What symmetric crypto algorithm is that? > >The bigger risk, though, is the quality of random numbers available > >for seeding your DH keys. Don't even DREAM of using Delphi's builtins, > >if it has them - go find good crypto-quality-randomness work to reuse, > >unless you know you'll only run on Linux where there's /dev/random. > >At least use sound-card noise or user-entered mouse tracks to help. > >Lots of "secure" systems have been cracked by cracking their random seeds. > > Of course. ;) Did I mention that I wrote a Yarrow implementation in Delphi? <g> It passes DIEHARD, but it hasn't been otherwise checked. [Public domain, btw.] > First, It's GPL'd, or under a modified version of the GPL. I find the GPL > to be distasteful and it forms a barrier more than a bridge to continued > software development. I like this guy :) [All my code is public domain, but I hate the GPL for *forcing* people to share. Communism at its best.] Mark

1 0

None
by Asymmetric 05 Jul '18

05 Jul '18

> The D/H is going to be used just to generate a key to securely transfer a > 4096 bit key for use in symmetrical crypto routines later in the program, You want to use a 4096-bit key for SYMMETRICAL crypto? Hello? Not only I don't know of ANY symmetrical algorithm with such a key, but why on Earth would you need it for? What attack do you know against a 128-bit or even 256-bit key that doesn't work against a 4096-bit one? > for actual encryption of the chat/voice/file data transfers. Using 1024 > bits of D/H is fine to generate a key-encryption key to just transfer the > 4096bit key. I chose 4096 because it's large enough to be used in any > symmetric crypto algorithm to max out it's key length. What symmetric crypto algorithm is that? > >The bigger risk, though, is the quality of random numbers available > >for seeding your DH keys. Don't even DREAM of using Delphi's builtins, > >if it has them - go find good crypto-quality-randomness work to reuse, > >unless you know you'll only run on Linux where there's /dev/random. > >At least use sound-card noise or user-entered mouse tracks to help. > >Lots of "secure" systems have been cracked by cracking their random seeds. > > Of course. ;) Did I mention that I wrote a Yarrow implementation in Delphi? <g> It passes DIEHARD, but it hasn't been otherwise checked. [Public domain, btw.] > First, It's GPL'd, or under a modified version of the GPL. I find the GPL > to be distasteful and it forms a barrier more than a bridge to continued > software development. I like this guy :) [All my code is public domain, but I hate the GPL for *forcing* people to share. Communism at its best.] Mark

1 0

None
by Asymmetric 05 Jul '18

05 Jul '18

> The D/H is going to be used just to generate a key to securely transfer a > 4096 bit key for use in symmetrical crypto routines later in the program, You want to use a 4096-bit key for SYMMETRICAL crypto? Hello? Not only I don't know of ANY symmetrical algorithm with such a key, but why on Earth would you need it for? What attack do you know against a 128-bit or even 256-bit key that doesn't work against a 4096-bit one? > for actual encryption of the chat/voice/file data transfers. Using 1024 > bits of D/H is fine to generate a key-encryption key to just transfer the > 4096bit key. I chose 4096 because it's large enough to be used in any > symmetric crypto algorithm to max out it's key length. What symmetric crypto algorithm is that? > >The bigger risk, though, is the quality of random numbers available > >for seeding your DH keys. Don't even DREAM of using Delphi's builtins, > >if it has them - go find good crypto-quality-randomness work to reuse, > >unless you know you'll only run on Linux where there's /dev/random. > >At least use sound-card noise or user-entered mouse tracks to help. > >Lots of "secure" systems have been cracked by cracking their random seeds. > > Of course. ;) Did I mention that I wrote a Yarrow implementation in Delphi? <g> It passes DIEHARD, but it hasn't been otherwise checked. [Public domain, btw.] > First, It's GPL'd, or under a modified version of the GPL. I find the GPL > to be distasteful and it forms a barrier more than a bridge to continued > software development. I like this guy :) [All my code is public domain, but I hate the GPL for *forcing* people to share. Communism at its best.] Mark

1 0

None
by Asymmetric 05 Jul '18

05 Jul '18

> The D/H is going to be used just to generate a key to securely transfer a > 4096 bit key for use in symmetrical crypto routines later in the program, You want to use a 4096-bit key for SYMMETRICAL crypto? Hello? Not only I don't know of ANY symmetrical algorithm with such a key, but why on Earth would you need it for? What attack do you know against a 128-bit or even 256-bit key that doesn't work against a 4096-bit one? > for actual encryption of the chat/voice/file data transfers. Using 1024 > bits of D/H is fine to generate a key-encryption key to just transfer the > 4096bit key. I chose 4096 because it's large enough to be used in any > symmetric crypto algorithm to max out it's key length. What symmetric crypto algorithm is that? > >The bigger risk, though, is the quality of random numbers available > >for seeding your DH keys. Don't even DREAM of using Delphi's builtins, > >if it has them - go find good crypto-quality-randomness work to reuse, > >unless you know you'll only run on Linux where there's /dev/random. > >At least use sound-card noise or user-entered mouse tracks to help. > >Lots of "secure" systems have been cracked by cracking their random seeds. > > Of course. ;) Did I mention that I wrote a Yarrow implementation in Delphi? <g> It passes DIEHARD, but it hasn't been otherwise checked. [Public domain, btw.] > First, It's GPL'd, or under a modified version of the GPL. I find the GPL > to be distasteful and it forms a barrier more than a bridge to continued > software development. I like this guy :) [All my code is public domain, but I hate the GPL for *forcing* people to share. Communism at its best.] Mark

1 0

Re: Wikipedia & Tor
by Jimmy Wales 05 Jul '18

05 Jul '18

Paul Syverson wrote: > I want to emphasize a central aspect of my suggestion: The goal is not > just to provide a filter for abusive posts, it's to change incentives. This is exactly the right approach! > We can't know for sure without running the experiment, but my guess is > that if abusive posts through Tor never succeed (OK perhaps virtually > never), and if the process of posting through Tor informs posters of > that fact, then Tor will become worth it for your admins. The abusers > will disappear or greatly diminish because they will know from being > warned, and if necessary from experience, that their attempts will > fail. Posts through Tor will then mostly have value (in the sense of > not being abusive in the ways that prompted this discussion.) I would say that even some fairly slight changes to the incentive structure may help a lot. The less desirable Tor is for problem users, the more they will shift to traditional broken open proxies. We can play whack-a-mole with these as we do now, while at the same time leaving Tor more open. > Yes, I know (and I'm sure Jimmy knows) that this won't solve the > longterm underlying issues. Abusive posters will just move on to > another avenue than Tor. But I think it will be a quick, cheap, and > big win for both Tor and Wikipedia. Yes, but I don't really mind them moving to other avenues. That's the point. If I didn't love Tor, I wouldn't care about blocking Tor either. Let them abuse broken proxy servers, let them do whatever, that's fine, we can deal with it. We just want to open up to Tor. > Yes, as Marc Abel suggested you could implement passwords, pseudonyms, > or hell ZKPs. But this is stepping onto the slippery slope of trying > to solve the more longterm problem that using IP addresses in the way > Wikipedia does is a temporarily useful kludge. (Kludges are great, but > function creep is dangerous and can make for bigger problems in the > long run.) Let me see if I can explain a bit more of the math behind this. I'm just going to make up a hypothetical example. Suppose 100 out of every 1,000,000 edits to Wikipedia is malicious. And suppose we study them and discover, hmm, 25 of them come from Tor, which is easily blockable. 50 of them come from static ips or dynamic ips that are expensive for users to get new. 25 of them are from broken proxies. Now, our present solution is to block Tor, do various things in other situations, and this works reasonably well. Of the 25 bad edits we block from Tor, some portion of them surely shift to other means, but not all of them. So we find it to be a net win. Except. Except we don't really like to block Tor. Now, fast forward, and imagine that the "expensive ip" situation goes away in a few years, either due to widespread onion routing, or whatever you may want to dream up that makes our temporary kludge of using ips no longer functional. Then we'll still only have 100 out of every 1,000,000 edits to Wikipedia as being malicious. How we'll deal with that is how we'll deal with that, but that's fine. We'll manage. For now the key thing to do is to shift the incentives on the bad users so that Tor is less desirable for them than playing with the broken proxies or just doing whatever with a dialup account or aol addresses or whatever. --Jimbo ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [tahoe-dev] keeping private grids private
by Brian Warner 05 Jul '18

05 Jul '18

On 3/9/12 7:39 PM, Vladimir Arseniev wrote: > Let's say that we have a private grid, with both local and hosted > servers. But our introducer.furl falls into the wrong hands, and > uninvited nodes start appearing. Maybe they're just leeching storage. > Maybe they're disrupting the grid through flapping, running deep-check > all the time, or whatever. Maybe they're actively attacking the grid. > > How do we exclude them? Can introducers be configured to accept only > known nodes? Could we create a new introducer, and circulate its furl > to authorized nodes? Or would that just create a new grid? Like Markus said, we're getting closer, but we aren't quite there yet. The most important fix is to make the introducer.furl actually secret (currently it's guessable by anyone who knows the tubid): ticket #860 is related (but I can't find the actual ticket). Once fixed, then keeping the introducer.furl from falling into those wrong hands will work. It gives you a sort of secret-frat-party security system: anyone who's in the club can invite anyone they like, and there's no way to kick someone out (knowledge of the introducer.furl is irrevocable). We don't want to add new security measures to the Introducer itself (like giving it a list of "good" clients so it can ignore the rest), because we want to get rid of the Introducer entirely. We want to replace it with a distributed gossip-based system (#68), and you can't rely on a bunch of gossiping nodes to enforce access-control policies. So we're looking in different directions to provide the sort of control you're looking for. The next step is the explicit-server-selection work: #467. When that's done, each client will be able to indicate which servers they want to use, ignoring rogue servers. That will fix the availability problems (servers connecting, accepting shares, then disappearing). The configuration of this is still a matter of debate: one approach is to list the pubkey of the servers you want to use, but that can be labor-intensive for larger grids, and makes it hard to share files if the uploader uses a different list than the downloader. Another approach is to delegate membership to a "grid manager" of some sort: more moving pieces but probably easier to use. The step after that is part of Accounting (#666), in which servers reject operations by unauthorized clients. This would include both storage (leeching) and network bandwidth (downloading shares, running deep-check, etc, but not basic DoS). But for now, yeah, IP-address filtering is a good quick answer. cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

None
by Asymmetric 05 Jul '18

05 Jul '18

> The D/H is going to be used just to generate a key to securely transfer a > 4096 bit key for use in symmetrical crypto routines later in the program, You want to use a 4096-bit key for SYMMETRICAL crypto? Hello? Not only I don't know of ANY symmetrical algorithm with such a key, but why on Earth would you need it for? What attack do you know against a 128-bit or even 256-bit key that doesn't work against a 4096-bit one? > for actual encryption of the chat/voice/file data transfers. Using 1024 > bits of D/H is fine to generate a key-encryption key to just transfer the > 4096bit key. I chose 4096 because it's large enough to be used in any > symmetric crypto algorithm to max out it's key length. What symmetric crypto algorithm is that? > >The bigger risk, though, is the quality of random numbers available > >for seeding your DH keys. Don't even DREAM of using Delphi's builtins, > >if it has them - go find good crypto-quality-randomness work to reuse, > >unless you know you'll only run on Linux where there's /dev/random. > >At least use sound-card noise or user-entered mouse tracks to help. > >Lots of "secure" systems have been cracked by cracking their random seeds. > > Of course. ;) Did I mention that I wrote a Yarrow implementation in Delphi? <g> It passes DIEHARD, but it hasn't been otherwise checked. [Public domain, btw.] > First, It's GPL'd, or under a modified version of the GPL. I find the GPL > to be distasteful and it forms a barrier more than a bridge to continued > software development. I like this guy :) [All my code is public domain, but I hate the GPL for *forcing* people to share. Communism at its best.] Mark

1 0

Re: Wikipedia & Tor
by Jimmy Wales 05 Jul '18

05 Jul '18

Paul Syverson wrote: > I want to emphasize a central aspect of my suggestion: The goal is not > just to provide a filter for abusive posts, it's to change incentives. This is exactly the right approach! > We can't know for sure without running the experiment, but my guess is > that if abusive posts through Tor never succeed (OK perhaps virtually > never), and if the process of posting through Tor informs posters of > that fact, then Tor will become worth it for your admins. The abusers > will disappear or greatly diminish because they will know from being > warned, and if necessary from experience, that their attempts will > fail. Posts through Tor will then mostly have value (in the sense of > not being abusive in the ways that prompted this discussion.) I would say that even some fairly slight changes to the incentive structure may help a lot. The less desirable Tor is for problem users, the more they will shift to traditional broken open proxies. We can play whack-a-mole with these as we do now, while at the same time leaving Tor more open. > Yes, I know (and I'm sure Jimmy knows) that this won't solve the > longterm underlying issues. Abusive posters will just move on to > another avenue than Tor. But I think it will be a quick, cheap, and > big win for both Tor and Wikipedia. Yes, but I don't really mind them moving to other avenues. That's the point. If I didn't love Tor, I wouldn't care about blocking Tor either. Let them abuse broken proxy servers, let them do whatever, that's fine, we can deal with it. We just want to open up to Tor. > Yes, as Marc Abel suggested you could implement passwords, pseudonyms, > or hell ZKPs. But this is stepping onto the slippery slope of trying > to solve the more longterm problem that using IP addresses in the way > Wikipedia does is a temporarily useful kludge. (Kludges are great, but > function creep is dangerous and can make for bigger problems in the > long run.) Let me see if I can explain a bit more of the math behind this. I'm just going to make up a hypothetical example. Suppose 100 out of every 1,000,000 edits to Wikipedia is malicious. And suppose we study them and discover, hmm, 25 of them come from Tor, which is easily blockable. 50 of them come from static ips or dynamic ips that are expensive for users to get new. 25 of them are from broken proxies. Now, our present solution is to block Tor, do various things in other situations, and this works reasonably well. Of the 25 bad edits we block from Tor, some portion of them surely shift to other means, but not all of them. So we find it to be a net win. Except. Except we don't really like to block Tor. Now, fast forward, and imagine that the "expensive ip" situation goes away in a few years, either due to widespread onion routing, or whatever you may want to dream up that makes our temporary kludge of using ips no longer functional. Then we'll still only have 100 out of every 1,000,000 edits to Wikipedia as being malicious. How we'll deal with that is how we'll deal with that, but that's fine. We'll manage. For now the key thing to do is to shift the incentives on the bad users so that Tor is less desirable for them than playing with the broken proxies or just doing whatever with a dialup account or aol addresses or whatever. --Jimbo ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [tahoe-dev] keeping private grids private
by Brian Warner 05 Jul '18

05 Jul '18

On 3/9/12 7:39 PM, Vladimir Arseniev wrote: > Let's say that we have a private grid, with both local and hosted > servers. But our introducer.furl falls into the wrong hands, and > uninvited nodes start appearing. Maybe they're just leeching storage. > Maybe they're disrupting the grid through flapping, running deep-check > all the time, or whatever. Maybe they're actively attacking the grid. > > How do we exclude them? Can introducers be configured to accept only > known nodes? Could we create a new introducer, and circulate its furl > to authorized nodes? Or would that just create a new grid? Like Markus said, we're getting closer, but we aren't quite there yet. The most important fix is to make the introducer.furl actually secret (currently it's guessable by anyone who knows the tubid): ticket #860 is related (but I can't find the actual ticket). Once fixed, then keeping the introducer.furl from falling into those wrong hands will work. It gives you a sort of secret-frat-party security system: anyone who's in the club can invite anyone they like, and there's no way to kick someone out (knowledge of the introducer.furl is irrevocable). We don't want to add new security measures to the Introducer itself (like giving it a list of "good" clients so it can ignore the rest), because we want to get rid of the Introducer entirely. We want to replace it with a distributed gossip-based system (#68), and you can't rely on a bunch of gossiping nodes to enforce access-control policies. So we're looking in different directions to provide the sort of control you're looking for. The next step is the explicit-server-selection work: #467. When that's done, each client will be able to indicate which servers they want to use, ignoring rogue servers. That will fix the availability problems (servers connecting, accepting shares, then disappearing). The configuration of this is still a matter of debate: one approach is to list the pubkey of the servers you want to use, but that can be labor-intensive for larger grids, and makes it hard to share files if the uploader uses a different list than the downloader. Another approach is to delegate membership to a "grid manager" of some sort: more moving pieces but probably easier to use. The step after that is part of Accounting (#666), in which servers reject operations by unauthorized clients. This would include both storage (leeching) and network bandwidth (downloading shares, running deep-check, etc, but not basic DoS). But for now, yeah, IP-address filtering is a good quick answer. cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0