Is this an older model? I could see them turning off or using weak encryption on media if the hardware couldn't keep up with the amount of data they were writing.

▲

ryukoposting 3 hours ago | parent | next [-]

As another commenter pointed out, any cheapo ARM core from the last 10 years could do the job Flock needs it to do, as long as it has a (very cheap and common) crypto engine strapped to it.

But, a question for you: even if it was the case that the hardware was the limitation, isn't that also an indictment of Flock? Selling something that cannot exist securely within the bounds of current technology? Or, at a minimum, bad chip selection leading to a compromised design?

▲

megous 4 hours ago | parent | prev | next [-]

I'm in the process of optimizing a bootolader for my various SoC/SBCs and even the cheapest, oldest least powerful SoC from 15 years ago can manage AES-CBC via crypto accelerator at 50 MiB/s. There's no excuse.

▲

fullstop 3 hours ago | parent [-]

You can achieve 50MiB/s if that's all that you're doing. I've worked with some DSPs (TI's DaVinci line) where some operations would abort if DDR was overwhelmed.

For example, passing a frame of video (YUV) into the peripheral which can resize the overall image, would fail if the system was busy with other DMA transfers. You could attempt to resize again, but there were no guarantee that it would complete successfully. Your options are to reduce overall DDR utilization or drop frames. In an application like Flock's, dropping frames is likely something they need to avoid.

The system in question is doing similar tasks, and I don't think that what I'm suggesting is out of the question.

▲

megous 2 hours ago | parent [-]

They can choose the SoC that would be able to fill the requirements. Eg. almost all Rockchip SoCs have NoC with configurable QoS on master ports (even the cheapest IP camera targetted SoCs that cost like 2-3$), or some other interconnect mechanism that can make it so that SDRAM controller gets tasks in some user selected priority order (eg. you deprioritize CPU in favor of camera interface and other things). This is not a new tech. It already existed when Flock was founded.

And in any case. Passing compressed video streams or pictures through HW encryption engine will not saturate 1.5+ GiB/s or whatever even the lousiest 16-bit DDR3 at 400MHz would give you, not even close. It would be like a fraction of a percent of total bandwidth.

	▲	fullstop 2 hours ago \| parent [-]
		That's why I was asking if it was an older model initially.

▲

ohyoutravel 4 hours ago | parent | prev [-]

That would be an extremely bad trade.

▲

fullstop 3 hours ago | parent [-]

Why? Does Flock really care about encryption? It checks off a box for their sales team, even if it's done poorly.

▲

samudrijan 3 hours ago | parent [-]

Because data should be secure. Full stop.

	▲	fullstop 2 hours ago \| parent \| next [-]
		In a perfect world, yes, but this is a for-profit company and there's almost zero repercussion for doing it half-assed. They'd have to pay someone to implement it, and deal with the overhead and complexity. Now they are in a position where they can sell new models with enhanced encryption and more features.
	▲	criddell 2 hours ago \| parent \| prev [-]
		If it increases development or operating costs by $1 they won't do it unless there are consequences that could cost them more than that.