11:36 <DocScrutinizer05> ((great-sim-heist)) [Tue 17 February 2015] [17:20:40] <DocScrutinizer05> so encryption is effective in the U-TDOA records [Tue 17 February 2015] [17:20:56] <DocScrutinizer05> as long as it's effective at all

11:42 <DocScrutinizer05> I mean ECHELON was when? 80s?

11:43 <DocScrutinizer05> when they did ECHELON in the 80s, I'd be very surprised when they wouldn't do 0..8GHz full-scope incl phase and direction today

11:44 <DocScrutinizer05> possibly even frm space

11:44 <DocScrutinizer05> well, no. that's hardly possible ;-)

11:49 <DocScrutinizer05> (U-TDOA) I wonder how many stations you'd really need to cover a country like Germany. I mean, compare GPS, it works the inverse way but can handle signal levels down to some -160dB (and distances between sender(s) and receiver up to 10,000s of km) and yet it only takes seconds to get a fix with an accuracy down to the 10feet range

11:50 <DocScrutinizer05> considering that, a 3 main stations would almost cover complete europe, as long as you have some ultra-cheap local remote receivers providing the "encoding" aka pattern

11:58 <DocScrutinizer05> dang, not even VPN makes mobile telephony really safe, they still can correlate the traffic bursts

12:00 <DocScrutinizer05> based on correlation they possibly could even spot the open SIP datapackets your SIP provider sends out to one of their gateways (or SIP peer), even when you'd connect to the SIP provider's infra with VPN - which iirc some SIP providers actually offer as a service to their customers

12:02 <DocScrutinizer05> remedy: ping -f

12:03 <DocScrutinizer05> but that will cut through your battery in really zero time

12:03 <DocScrutinizer05> and eat up your fattest "flat rate"

12:06 <DocScrutinizer05> well, ok, at least during (shortly before until shortly after) a SIP call such ping -f can cover the unique signature of data packet bursts in your VPN. So NSA and friends will know "there's happening severe data traffic over a VPN to a SIP provider" but they can't correlate you to a particular unencrypted outbound stream from that provider anymore

12:07 <DocScrutinizer05> (given the provider has a sufficient 3..4figure number of concurrently serviced calls at least)

12:08 <DocScrutinizer05> but beware, when a particular phone number is getting called from that SIP provider a dozen times and each time your stealth ping was active, you're exposed again

12:09 <Wizzup> DocScrutinizer05: even so, as long as your encryption is safe then I don't see the big deal

12:09 <DocScrutinizer05> (same rationale why swapping SIMs doesn't really help)

12:10 <DocScrutinizer05> Wizzup: the encryption isn't safe anymore when the SIP relays your voice over the eavesdropnternet

12:11 <Wizzup> SIP can be encrypted

12:11 <Wizzup> no?

12:11 <DocScrutinizer05> yes, ZRTP was a very fine method to give NSA headaches

12:12 <DocScrutinizer05> actually prolly the only method they hardly ever can crack retrograde, not crack it realtime for now

12:12 <DocScrutinizer05> s/not/nor/

12:12 <Wizzup> Then encryption with SIP should be *okay*?

12:12 <DocScrutinizer05> yes

12:12 <Wizzup> :)

12:13 <DocScrutinizer05> not covering the metadata at all, but very good for content

12:13 <Wizzup> perhaps there should be some (u)blog entry on the website at some point, giving some update

12:13 <Wizzup> It feels like quite a bit has happened

12:13 <DocScrutinizer05> just like PGP for emals

12:13 <Wizzup> (feels, I don't actually know)

12:15 <DocScrutinizer05> actually apart from me licking off securing of sufficient number of 1GB RAM chips and N900 used devices for revamp, way too little has happened during last ~8 weeks, I suck at performing while sick

12:15 <DocScrutinizer05> s/lick/kick/

12:17 <Wizzup> but also on the sw side I think? some audio work?

12:18 <DocScrutinizer05> that's not really related to Neo900 UG. Ask freemangordon and Pali

12:19 <Wizzup> right

12:20 <DocScrutinizer05> what's sw happening in Neo900 UG's domain is booting of a debian on a 1GB-pimped BB-xM

12:21 <DocScrutinizer05> alas no OneNAND and no 2nd 512MB RAM bank yet

12:21 <DocScrutinizer05> waitinf for Nikolaus to finally resolder those 5 0R of SYSBOOT on the board

12:23 <Wizzup> DocScrutinizer05: cool

12:23 <DocScrutinizer05> this thing (evaluation of the 1GB PoP) takes ~9 weeks now

12:23 <Wizzup> Is there a place to follow the sw-work more closely?

12:23 <DocScrutinizer05> :-/

12:24 <DocScrutinizer05> well, freemangordon and Pali seem to chat "a lot" here in this chan, and occasionally publish stuff to githup and even post a mini news about it on ~fptf

12:25 <Wizzup> right

12:25 <DocScrutinizer05> the GDC sw work can get followed on GDC's site

12:26 <Pali> ooo good news, it looks like sha1 and md5 omap hw support is working on N900 even without special X-loader!

12:26 <DocScrutinizer05> e.g here http://git.goldelico.com/?p=gta04-xloader.git;a=summary

12:26 <Pali> I will check this with another n900 where was never flashed that special X-Loader

12:29 <DocScrutinizer05> Wizzup: also http://irclog.whitequark.org/neo900/2015-02-06#11758212; http://talk.maemo.org/showthread.php?p=1459843#post1459843

12:30 <Wizzup> thx

12:31 <DocScrutinizer05> http://projects.goldelico.com/p/neo900/issues/678/

12:31 <arcean> Pali: How so? No more crashes?

12:31 <Pali> there are crashes for AES

12:31 <DocScrutinizer05> hi Pali :-)

12:31 <Pali> but now I'm playing with sham (sha/md5) omap driver

12:31 <Pali> and that does not crash

12:31 <arcean> wow, nice

12:53 <Pali> yes, omap-sham.ko working :-) no crash

13:08 <Wizzup> where is that typically used? (md5/sha1 acceleration)

13:11 <Pali> it can be used in luks (when using sha) or also by userspace application

13:11 <Pali> there is API for it

13:24 <DocScrutinizer05> efficiency for non-concurrent (MP) use yet to be seen/evaluated/investigated. Probably the ARM CPU is faster on doing same en/de-cryption algos, so a real benefit would only be seen when running the crypt on that dedicated hardware in parallel and non-blocking to the main CPU

13:30 <DocScrutinizer05> and of course the crypt IP might be more power-economic than the main CPU core

13:38 <Pali> like theora decoding... arm+neon version provides more fps, but use 100% cpu... dsp version provides less fps, but cpu is basically idle

13:39 <DocScrutinizer05> yes, exactly

13:40 <DocScrutinizer05> the very core of embedded system architecture philosophy

13:42 <DocScrutinizer05> this plus a completely event triggered architecture

13:44 <DocScrutinizer05> both mostly unknown or neglected on common PC system architecture. Actually PC architecture frequently goes the opposite way, moving tasks away from dedicated subsystems and "emulating" it with mere CPU power

13:44 <DocScrutinizer05> and replacing event driven approach by ever higher frequency polling

13:45 <DocScrutinizer05> just because it's cheaper

13:45 <DocScrutinizer05> not on energy consumption but on hw needed

13:49 <DocScrutinizer05> and also on effort needed to implement the software, in the end

13:51 <DocScrutinizer05> you could even go to the extent of saying this is one of the reasons why Nokia had own N900-specific kernel modules

13:51 <DocScrutinizer05> often the PC-centric approach of mainline is not really suited for embedded

13:52 <DocScrutinizer05> for example see how mainline implements accelerometer. Polling at max frequency and doing all event detection in software

13:53 <DocScrutinizer05> very flexible and feasible approach for a PC powered from mains, but a complete nogo for battery-powered embedded

13:58 <DocScrutinizer05> the real probelm is: a chip like e.g. accelerometer can get used both ways, and depending on minor circuit implementation details one or the other of both (event driven vs CPU-centric) approaches may not even be feasible - e.g. when not connecting the IRQ line of accel which obviously defeats the event-driven concept. So what shall a universal (kernel) driver implement for e.g. lis302? The both approaches are more or less mutually

13:58 <DocScrutinizer05> exclusive unless you invest huge amounts of planning to support both concurrently in same driver

14:02 <DocScrutinizer05> basically we would need both: lis302-joystick.ko for polling on PC (~== mainline driver), and lis302-irq.ko for embedded (~== what Nokia and Openmoko did)

14:06 <DocScrutinizer05> my point probably being: a driver depends not only on the chip used in a subsystem but at least as much on the (often considered trivial) way how it gets connected and integrated into the complete device

14:08 <DocScrutinizer05> the more complex the chip, the more evident this gets. See e.g. audio codec/mixer where a 2 dozen analog IO lines can have completely different meaning depending on how they are connected in the device

14:08 <DocScrutinizer05> on GTA02 we had IHF speakers on ALSA "headset" controls, etc

14:10 <DocScrutinizer05> the ALSA devels refused to acknowlede this issue and insisted on naming the controls according to some rather arbitrary and often made-up names they derived from the chip datasheet

14:12 <DocScrutinizer05> completely ignoring that those names are massively misleading when it comes to the *implemetation/integration* of that chip into a particular device