Well, one example of a timing attack is replaying. It’s a fucking classic, chefs kiss kind of signaling attack where you bypass the need to understand what’s going on by just saying it verbatim using your capacity to accurately reproduce some information, easily sidestepping all kinds of shibboleths.

Before computers replaying was used during both ww1 and ww2 to confuse and misdirect radio operators and back when keyless entry was a newfangled thing it was used to spoof the unique signals each manufacturer chose to use. Even after they all switched to rolling codes, replaying is a way to both desynchronize the owners fob and replay their command at almost the same time, getting you into the car.

In computing, replaying would be a fantastic way for a man in the middle to pretend like he knew some password or was some service, indicated by an encrypted or hashed transmission the man in the middle could just store and replay. Darla can listen in to the way alfalfa says the password to the he man woman haters club and with good practice, recite it convincingly!

If Darla were a computer then even alfalfas securely hashed password would be no problem because she doesn’t need to pronounce it, but just reproduce it in all its unpronounceable hexadecimal glory.

But if the instructions for the he man woman haters club authentication was instead an encrypted transmission saying “the clubs clock says it’s 4:15.45.6789 pm April twentieth 1969. When you reply with your password hash, include the clubs clock time down to the millisecond.” Now Darla can’t just replay alfalfas hashed authentication token because it’s the wrong time!

Because of ntp, girls remain not allowed.

How would such an attack affect the printer? Who can say! I can speculate that an interloper could make it do things the user could, like print stuff, burn up the nozzle or smash into its extents. The printer controller is basically just a little computer so gaining access to it as an authenticated user might make it easier to escalate privileges and use it like any other computer might be used by a malicious actor as well.

Let’s say though, that part of the out of the box setup is connecting to the printer through some app or program. You want encrypted tls for that and you want the user or their software to exchange certificates to make it all official, but that technology requires that time be synchronized between the two devices in order to do so. If the printer has inaccurate enough time it can’t even negotiate a secure connection with the owners phone app they use to send it instructions.

So ntp makes sense in this case. If you’re gonna be doing communication you gotta do it responsibly and it’s good that iot stuff like this is making some effort!

The types of attacks can be mischaracterized as “race conditions but over the network”. Theres about forty years of history here and it’s way more complicated so unless you really wanna get into it I’ll leave it there.

The printer doesn’t know if it’s plugged into a private network or is internet facing. Timing attacks can occur on private networks as well as on the internet. Having accurate utc is almost always a prerequisite for communicating with other devices.

Therefore, the printer needs to know what time it is. It does this through ntp on port 123 just like phones, computers and network connected paper and ink printers do.

Anything that connects to the network needs a synchronized clock with other devices it directly communicates with in order to make sure it’s not being subjected to timing attacks. This has been standard practice for 25 years, maybe more, in the end user world because some high profile computer screw ups made use of it. People with weird systems, off the gridders of olde and ppl still on dial up in the teens had some interesting problems to solve when generally all ISPs got drug kicking and screaming to the table by os updates that made synchronized clocks a non negotiable requirement.

100%!

One of the operation types that benefitted from much of that money and software development time is cryptography, where entire chunks of silicon are dedicated to quickly performing the (for better or worse) pipelined calculations that allow us to conduct secure transmissions along to their destinations.

There’s a lot of technical differences I just wanted to go a step above saying “arm is just a lil guy and x86 is a muscly dude who can’t function without his protein”, which seems appropriate to me.

There’s already some really good replies, but think critically for a second about what you’re asking for:

You want a summary of content made by “reject convenience” about the data broker and removal request industry, shouted into the void on social media, specifically on the insanely easy to infiltrate and subvert fediverse.

Real black comedy posting hours who’s up?

You’re getting bad advice.

If you don’t expect to actually be shuffling packets back and forth or doing any kind of quality of service or vpn or really anything then the pi will be the better choice just barely because of its super low power consumption at idle. In that situation you would be at idle enough to actually justify using the pi. It would suck in the same way that using a pi for stuff usually sucks but you could justify it maybe.

If you plan to have a bunch of hosted stuff, a seedbox, qos, manage vpn connections and especially upgrade your lan to 1gb + later on down the line, the mini pc will actually be more efficient per cycle. In that circumstance you’d be at idle less, and the mini pcs more powerful processor, wider bus and expandability would make it less of a bottleneck presently and down the road.

Risc CPUs like the arm in the raspberry pi are really good at not doing anything, or doing a really small subset of things (it’s in the name!), but x86 is great at doing some stuff and being able to do a wide variety of stuff with its big instruction set. If you raise an eyebrow at my claim, consider that before gpus were the main way to do math in a data center it was x86. If the people who literally count every fraction of a watt of power consumption as billable time think it’s most efficient it probably is!

With ~08+ CPUs ability to turn cores and functions off at the clock tree and communicate back and forth with the os to orchestrate and coordinate it, there’s not as much daylight between the power usage of a pi and a mini pcs as some of these comments might make you think.

The long and the short of it is that you’ll most likely have a better time using the mini pc than the pi and claims that it’ll bankrupt you with power bills are greatly exaggerated.

In terms of privacy, I’d go for the mini pc. All your packages are most likely going to be open source, but the x86 stuff gets more scrutiny and isn’t as “magic blobby” as the arm world is.

Source: I have used over twenty different pi variants including knockoffs, wrote for microcontrollers before they were called sbcs, host a bunch of services on x86 which are monitored for their power usage using a power distribution controller by my lovely wife who keeps an eagle eye on the bills and I literally registered an account because people were telling you the wrong thing on the internet.

If you wanna verify that for yourself, get a cheap plug em in power meter and try both units running the package you choose under some artificial load like managing qos between a device streaming 4k and one torrenting 50 different Linux isos.