July 2018 - cypherpunks-legacy

Re: [tor-talk] Choosing a name for a .onon
by Maxim Kammerer 06 Jul '18

06 Jul '18

On Fri, Mar 30, 2012 at 01:54, Seth David Schoen <schoen(a)eff.org> wrote: > Choosing the first 40 bits of a hash generally requires trying an average of 2b4b0 > possibilities; my laptop does about 3-4 million SHA1 operations per second > (per CPU core) so it would take me 3-4 days (per CPU core) of computation > to try that many possibilities on my laptop. Due to proliferation of Bitcoin, there are now very efficient SHA-256 generators for off-the-shelf GPUs. The numbers at [1] suggest performance that's at least two orders of magnitude faster than your laptop b and for double-SHA-256 instead of a single SHA-1 (which I assume can be done by the same software after some simple adaptation). [1] https://en.bitcoin.it/wiki/Mining_hardware_comparison > Of course this requires being able to change something trivial about the > public key when generating the .onion address. Not necessarily b you can generate the hash first, and then check whether the public key is legal. I.e., generate a 512-bit prime p, and then go on with producing a completely random 512-bit e, and checking whether SHA-1(ASN.1-RSAPublicKey(modulus=p*e, exponent=65537)) (which is how Tor computes the .onion address) produces the desired result. If it does, check whether e is prime. Density of primes in the range of e is ~1/512, so that's just 9 bits more of search space, and primality checking efficiency doesn't matter much. -- Maxim Kammerer LibertC) Linux (discussion / support: http://dee.su/liberte-contribute) _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- 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

[HacDC:Byzantium] Wi-fi range extension with phased pherical array antennae?
by briancady413 06 Jul '18

06 Jul '18

Perhaps wi-fi range could be extended without increased power with spherical phased arrays of antennae, which can be used to directionally amplify sent and received signals. Maybe a physics or engineering student could put into the public domain hardware designs to control signal directionality of such an icosahedral array, and open source software could be devised to discover other signal's direction, and transpond 'in' that right direction with that signal's transponder. Here's some related papers: http://www.jpier.org/PIER/pier.php?paper=06081101 http://www.ursi.org/Proceedings/ProcGA02/papers/p1274.pdf Brian -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To view this discussion on the web visit https://groups.google.com/a/hacdc.org/d/msg/Byzantium/-/Vnlm6e2pXG0J. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. ----- 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

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

Lynn.Wheeler(a)firstdata.com wrote: > > the current SSL domain name infrastructure supposedly exists because of issues > with trusting the domain name infrastructure ... except the SSL domain name > certificate issuer has to trust the same (untrusted) domain name infrastructure > when issuing a certificate (i.e. the SSL domain name certificate is no better > than the authentication authority that the certificate authority has to rely on > as the final arbitrator of domain name ownership). > > one of the integrity issues with the domain name infrastructure ... is that > domain names have been hijacked ... once hijacked ... you can go to certificate > authority and get a certificate with that domain name (and the certificate > authority will check with the domain name system and confirm that the requester > owns the domain name). The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

1 0