From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1C93221F19C for ; Sat, 26 Jan 2013 02:57:14 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1392342oag.31 for ; Sat, 26 Jan 2013 02:57:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T44mdaYdmfvgyxzmy9DoCmr0aLezBsuPrVb4PoHzWy8=; b=hOW+pUZ0gZpau1ALcsbg6OoPzqXAqHK10J7kBWu2uQA6JAEgamxtAWZh62hE2yjpDm d0++Ra75biScXXMQB4ifX2M3rZppuXcXOQR6yA/J+uvXL9sdUZCRbbyM2NX85W1spkOK 6Gc0ntr4MxNsHLQhUYxdRbzJiwQtuGL5wu4og5ZFnT2U7tHdkv2fGq1DtA1sMTiY06Yi KmIg59eEWnLSYP5j9avXANToxSndwEH/5MIa6d080OjZ/YmuqzCJFnzVbUOd9EHVpuNZ pS44UPgxU5wTQyUC3QBTKpzU5X8SXWwHwihZz1XRtNfgnwgh7Vzqg9894C3JnimnpLG3 mAQQ== MIME-Version: 1.0 X-Received: by 10.60.26.66 with SMTP id j2mr6365710oeg.102.1359197833079; Sat, 26 Jan 2013 02:57:13 -0800 (PST) Received: by 10.76.80.99 with HTTP; Sat, 26 Jan 2013 02:57:12 -0800 (PST) X-Originating-IP: [77.65.47.165] In-Reply-To: <1358804859.167924837@apps.rackspace.com> References: <1358804859.167924837@apps.rackspace.com> Date: Sat, 26 Jan 2013 11:57:12 +0100 Message-ID: From: Maciej Soltysiak To: dpreed@reed.com Content-Type: multipart/alternative; boundary=e89a8fb202b4052b1804d42ee81e X-Gm-Message-State: ALoCoQkmw6xQ2bM7eNDSu+Dsomty143voW36hsrkvHNpAHrbwX0cVAPxoFaDFRSHIoRiWGQV0uFy Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt-3.7.3-2 released X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 10:57:14 -0000 --e89a8fb202b4052b1804d42ee81e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think Dave was thinking of encrypting uftp traffic, which uses RSA. How random does that have to be? Depends how sofisticated is your adversary I guess. Do we only want to prevent clear text transfers or make it hard to decrypt? On Mon, Jan 21, 2013 at 10:47 PM, wrote: > How random do you need things to be? Security needs true randomness, bu= t > there is nothing else I know of where you need "entropy" sources to achie= ve > sufficient unpredictability to meet the need of some algorithm. A simple > pseudo-random sequence is good enough. > > > > -----Original Message----- > From: "Dave Taht" > Sent: Monday, January 21, 2013 2:47pm > To: cerowrt-devel@lists.bufferbloat.net > Subject: [Cerowrt-devel] cerowrt-3.7.3-2 released > > And is at: > > http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-2 > > + resync with openwrt > + uftp4 alpha > + quagga update > + Hopefully the last ipv6 instruction traps killed (thx ketan and robert!= ) > - I see rngd eating a ton of cpu on a given transfer. I'd been meaning to > look at the quality of the new entropy stuff for ages, and have long hope= d > to be rid of that daemon > > After we do a bit more testing I'll tag and push the source to this > version, and then get cracking on higher layers in the stack again. > > A bit about uftp4 support. My intent with getting uftp into cerowrt 18 > months ago was to have an easy multicast test, which would let someone (f= or > example) set a rate of 1Mbit and observe what happens to a wireless > network, observe packet loss at various distances from the AP, etc, as we= ll > as get a grip on the timing delays induced by the power save mode in wifi > (basically storing all multicast content and broadcasting it as "content > after beacon", (CAP, also known colloquially as "crap after beacon"))... > > Anyway, while I was thinking that as my basic use case in this project... > > Dennis Bush was actually off making a new version do more useful things. > We got to talking last week... I've tried the ipv4 support and it's nifty= . > Ipv6 didn't work but perhaps my x86 build is bad. > > -- > Dave T=C3=A4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > --e89a8fb202b4052b1804d42ee81e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Dave was thinking of encrypting uftp traffic, which uses RSA. = How random does that have to be?
Depends how sofisticated is your= adversary I guess. Do we only want to prevent clear text transfers or make= it hard to decrypt?
On Mon, Jan 21, 2013 at 10:47 PM, <dpreed@= reed.com> wrote:

How rand= om do you need things to be?=C2=A0=C2=A0 Security needs true randomness, bu= t there is nothing else I know of where you need "entropy" source= s to achieve sufficient unpredictability to meet the need of some algorithm= .=C2=A0 A simple pseudo-random sequence is good enough.

=C2=A0

-----Original Message-----
From: &qu= ot;Dave Taht" <dave.taht@gmail.com>
Sent: Monday, January 21, 2013 2:47pm To: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] cerow= rt-3.7.3-2 released

And is at:

http= ://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-2

+ resy= nc with openwrt
+ uftp4 alpha
+ quagga update
+ Hopefully the last ipv6 instruction= traps killed (thx ketan and robert!)
- I see rngd eating a ton of cpu o= n a given transfer. I'd been meaning to look at the quality of the new = entropy stuff for ages, and have long hoped to be rid of that daemon

After we do a bit more testing I'll tag and push the source to this= version, and then get cracking on higher layers in the stack again.
A bit about uftp4 support. My intent with getting uftp into cerowrt 18 mon= ths ago was to have an easy multicast test, which would let someone (for ex= ample) set a rate of 1Mbit and observe what happens to a wireless network, = observe packet loss at various distances from the AP, etc, as well as get a= grip on the timing delays induced by the power save mode in wifi (basicall= y storing all multicast content and broadcasting it as "content after = beacon", (CAP, also known colloquially as "crap after beacon"= ;))...

Anyway, while I was thinking that as my basic use case in this project.= ..

Dennis Bush was actually off making a new version do more useful= things. We got to talking last week... I've tried the ipv4 support and= it's nifty. Ipv6 didn't work but perhaps my x86 build is bad.

--
Dave T=C3=A4ht

Fixing bufferbloat with cerowrt: http:= //www.teklibre.com/cerowrt/subscribe.html


______________________________________________= _
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


--e89a8fb202b4052b1804d42ee81e--