<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
* DocScrutinizer05
idly wonders how long until Snowden papers reveal the existence of that total RF surveillance incl U_TDOA I predicted
<DocScrutinizer05>
I mean ECHELON was when? 80s?
arcean has joined #neo900
<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
<DocScrutinizer05>
possibly even frm space
<DocScrutinizer05>
well, no. that's hardly possible ;-)
<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
<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
illwieckz has joined #neo900
<DocScrutinizer05>
dang, not even VPN makes mobile telephony really safe, they still can correlate the traffic bursts
<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
<DocScrutinizer05>
remedy: ping -f
<DocScrutinizer05>
but that will cut through your battery in really zero time
<DocScrutinizer05>
and eat up your fattest "flat rate"
che11 has quit [Ping timeout: 245 seconds]
<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
<DocScrutinizer05>
(given the provider has a sufficient 3..4figure number of concurrently serviced calls at least)
<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
<Wizzup>
DocScrutinizer05: even so, as long as your encryption is safe then I don't see the big deal
<DocScrutinizer05>
Wizzup: the encryption isn't safe anymore when the SIP relays your voice over the eavesdropnternet
<Wizzup>
SIP can be encrypted
<Wizzup>
no?
<DocScrutinizer05>
yes, ZRTP was a very fine method to give NSA headaches
<DocScrutinizer05>
actually prolly the only method they hardly ever can crack retrograde, not crack it realtime for now
<DocScrutinizer05>
s/not/nor/
<Wizzup>
Then encryption with SIP should be *okay*?
<DocScrutinizer05>
yes
<Wizzup>
:)
<DocScrutinizer05>
not covering the metadata at all, but very good for content
<Wizzup>
perhaps there should be some (u)blog entry on the website at some point, giving some update
<Wizzup>
It feels like quite a bit has happened
<DocScrutinizer05>
just like PGP for emals
<Wizzup>
(feels, I don't actually know)
<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
<DocScrutinizer05>
s/lick/kick/
<Wizzup>
but also on the sw side I think? some audio work?
<DocScrutinizer05>
that's not really related to Neo900 UG. Ask freemangordon and Pali
<DocScrutinizer05>
what's sw happening in Neo900 UG's domain is booting of a debian on a 1GB-pimped BB-xM
<DocScrutinizer05>
alas no OneNAND and no 2nd 512MB RAM bank yet
che11 has joined #neo900
<DocScrutinizer05>
waitinf for Nikolaus to finally resolder those 5 0R of SYSBOOT on the board
<Wizzup>
DocScrutinizer05: cool
<DocScrutinizer05>
this thing (evaluation of the 1GB PoP) takes ~9 weeks now
<Wizzup>
Is there a place to follow the sw-work more closely?
<DocScrutinizer05>
:-/
<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
<Wizzup>
right
<DocScrutinizer05>
the GDC sw work can get followed on GDC's site
<Pali>
ooo good news, it looks like sha1 and md5 omap hw support is working on N900 even without special X-loader!
<Pali>
but now I'm playing with sham (sha/md5) omap driver
<Pali>
and that does not crash
<arcean>
wow, nice
che11 has quit [Remote host closed the connection]
<Pali>
yes, omap-sham.ko working :-) no crash
<Wizzup>
where is that typically used? (md5/sha1 acceleration)
<Pali>
it can be used in luks (when using sha) or also by userspace application
<Pali>
there is API for it
<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
<DocScrutinizer05>
and of course the crypt IP might be more power-economic than the main CPU core
paulk-collins has joined #neo900
<Pali>
like theora decoding... arm+neon version provides more fps, but use 100% cpu... dsp version provides less fps, but cpu is basically idle
<DocScrutinizer05>
yes, exactly
<DocScrutinizer05>
the very core of embedded system architecture philosophy
<DocScrutinizer05>
this plus a completely event triggered architecture
<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
<DocScrutinizer05>
and replacing event driven approach by ever higher frequency polling
<DocScrutinizer05>
just because it's cheaper
<DocScrutinizer05>
not on energy consumption but on hw needed
<DocScrutinizer05>
and also on effort needed to implement the software, in the end
<DocScrutinizer05>
you could even go to the extent of saying this is one of the reasons why Nokia had own N900-specific kernel modules
<DocScrutinizer05>
often the PC-centric approach of mainline is not really suited for embedded
<DocScrutinizer05>
for example see how mainline implements accelerometer. Polling at max frequency and doing all event detection in software
<DocScrutinizer05>
very flexible and feasible approach for a PC powered from mains, but a complete nogo for battery-powered embedded
<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
<DocScrutinizer05>
exclusive unless you invest huge amounts of planning to support both concurrently in same driver
<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)
<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
<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
<DocScrutinizer05>
on GTA02 we had IHF speakers on ALSA "headset" controls, etc
<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
<DocScrutinizer05>
completely ignoring that those names are massively misleading when it comes to the *implemetation/integration* of that chip into a particular device