Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [cryptography] [ipv6hackers] opportunistic encryption in IPv6

Eugen Leitl eugen at leitl.org
Wed Jun 12 09:21:47 PDT 2013


----- Forwarded message from Adam Back <adam at cypherspace.org> -----

Date: Wed, 12 Jun 2013 18:20:55 +0200
From: Adam Back <adam at cypherspace.org>
To: Will Yager <will.yager at gmail.com>
Cc: cryptography at 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 <eugen at leitl.org> wrote:
> 
>> ----- Forwarded message from Jim Small <jim.small at cdw.com> -----
>> 
>> Date: Wed, 12 Jun 2013 03:31:10 +0000
>> From: Jim Small <jim.small at cdw.com>
>> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
>> Subject: Re: [ipv6hackers] opportunistic encryption in IPv6
>> Reply-To: IPv6 Hackers Mailing List <ipv6hackers at 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
>> Ipv6hackers at 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
>> cryptography at randombit.net
>> http://lists.randombit.net/mailman/listinfo/cryptography



> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

_______________________________________________
cryptography mailing list
cryptography at 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



More information about the liberationtech mailing list