----- Forwarded message from Adam Back <a...@cypherspace.org> ----- Date: Wed, 12 Jun 2013 18:20:55 +0200 From: Adam Back <a...@cypherspace.org> To: Will Yager <will.ya...@gmail.com> Cc: cryptogra...@randombit.net Subject: Re: [cryptography] [ipv6hackers] opportunistic encryption in IPv6 User-Agent: Mutt/1.5.21 (2010-09-15)
You know apparently there people working on scrypt ASICs in the bitcoin context (because litecoin the main alt-coin is using scrypt as its proof of work vs the hashcash proof of work in bitcoin main). Also scrypt is GPU friendly enough that people are litecoin mining using GPUs. However I suspect part of that is the litecoin scrypt parameters as I understand it were chosen to fit in 128KB of ram usage to be CPU friendly (so your other cores and main memory IO is not clobbered so that our other apps arent unduly degraded by mining on a subset of your CPU cores.) The parameters were apparently selected to be CPU friendly (modulo the additional requirement of not killing general app performance) and GPU unfriendly. However it turns out that didnt quite work and GPUs are 10x faster than CPUs or thereabouts in mining litecoin. Perhaps different parameters could be used for password stretching, that aim to use RAM and not fit in L3 cache, however you have to be careful that things still work on a variety of devices (smartphone, tablet, laptop, desktop, server) without the entire thing fitting into server L3 cache. And some of the server chips are coming with larger and larger L3 caches eg up to 30M. Also another scrypt issue is it is inherently memory CPU tradeable. Ie you can voluntarily choose to expend more CPU to reduce the RAM required. So maybe someone with a quite large but not quite large enough multicore CPU can still gain a massive advantage over memory. (L3 cache vs main memory cycle difference is interestingly "large"). Adam On Wed, Jun 12, 2013 at 11:08:27AM -0500, Will Yager wrote: > The process of randomly generating and calculating a public key for every > brute-force attempt will slow the process considerably. However, for further > key stretching, perhaps many iterations of SHA-* et al. is not the best > option. Since web servers may be processing thousands of new connections per > second, thousands of iterations of SHA and co. per > connection may be prohibitively time-intensive for servers to implement. At > the same time, attackers with GPUs/FPGAs/ASICs will have an advantage of > several orders of magnitude. Perhaps in this case, it would be wise to > leverage a universally slow algorithm like Scrypt. It's not more difficult to > implement than SHA et al. but it's slower to brute-force with dedicated > crypto hardware. > > On Jun 12, 2013, at 5:21, Eugen Leitl <eu...@leitl.org> wrote: > >> ----- Forwarded message from Jim Small <jim.sm...@cdw.com> ----- >> >> Date: Wed, 12 Jun 2013 03:31:10 +0000 >> From: Jim Small <jim.sm...@cdw.com> >> To: IPv6 Hackers Mailing List <ipv6hack...@lists.si6networks.com> >> Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 >> Reply-To: IPv6 Hackers Mailing List <ipv6hack...@lists.si6networks.com> >> >>>> Here's an interesting question more relevant to the list and the paper >>> though - are IPv6 CGAs useful? It seems like SeND is dead. But does anyone >>> on the list think that CGAs could provide a useful competitive advantage for >>> IPv6 over IPv4? Are these a useful building block? >>> >>> I believe CGAs solves PKI problem entirely. If using CGAs one does not need >>> any PKI or CA certificate at all. >> >> True as long as you don't need authentication. But I have to concede, the >> whole point of OE is just to encrypt the traffic. >> >>> Each node having CGA can give self signed certificate. The certificate is >>> used >>> only to extract public key (PK), modifier, collision counter and any >>> extension >>> fields. >>> >>> Extracted information can be used to verify that host address is valid CGA >>> with the given public key. >>> >>> Next step is symmetric key negotiation. If during key negotiation messages >>> are encrypted with the specified public key then only node having the >>> corresponding private key can decrypt key negotiation messages. >>> >>> This step ensures that MITM is not possible if you are using CGA generated >>> not from your own public/private key pair. If you use your own >>> public/private >>> keys then you no longer can easily choose your address. >>> >>> If using CGA+IPSEC then IKE daemon can do the key negotiation part when >>> given authenticated public key. >>> >>> In SEND PKI is used only to protect from rogue routers. Only certificates >>> signed by the CA should be able to send router advertisements. >>> >>> TLDR: >>> For address authentication (protection against MITM) when using CGA no >>> PKI is needed. >> >> Per RFC 3972, "CGAs are not certified." I read the RFC as assuming a strong >> hash and secure private key, once someone uses a CGA someone else can't >> hijack/impersonate that address. So they are great for unauthenticated >> encryption. >> >>> CGAs is holy grail for opportunistic encryption. Node can immediately start >>> using opportunistic encryption by generating self signed certificate and >>> CGA. >>> >>>> One thing I wonder about is a 64 bit hash is pretty small - I wonder > if >>>> that >>> is sufficiently complex to provide security for the coming > decade+? >>> >>> When generating CGA you can choose security level which allows to slow >>> down brute force attacks (search for modifiers which would generate specific >>> CGA address). >>> >>> Security level is encoded in the first three bits of the address. >>> Because of that CGAs with lower security does not overlap with stronger >>> CGAs. >> >> True, but I wonder how well this fairs against modern massive parallel GPU >> crackers. SHA-1 is a weak hash. Would be nice to see an update using >> SHA-2/SHA-3 and to mandate longer key lengths - say >= 2048 bits. Otherwise >> doesn't it seem like we're going down the WEP path again? >> >> Still - it's a great point, CGAs do seem well suited for OE if you can live >> with the limitations. Is there anything that currently supports this? I'm >> wondering how much IPv6 market value this has... >> >> --Jim >> >> >> _______________________________________________ >> Ipv6hackers mailing list >> ipv6hack...@lists.si6networks.com >> http://lists.si6networks.com/listinfo/ipv6hackers >> >> ----- End forwarded message ----- >> -- >> Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org >> ______________________________________________________________ >> ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org >> AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 >> _______________________________________________ >> cryptography mailing list >> cryptogra...@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ > cryptography mailing list > cryptogra...@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
