In my opinion, the author understates how good AES-GCM-SIV is:
> The solution they designed is described in that linked paper: AES-GCM-SIV, which is able to tolerate some number of nonce collisions, but under a weaker notion of security that is only really applicable to that use-case (where the data being encrypted is itself random).
AES-GCM breaks catastrophically if you reuse a nonce; but the only thing that happens if you reuse a nonce with AES-GCM-SIV for two messages is that an attacker can see if the messages are equal (since AES-GCM-SIV is a deterministic algorithm, this is pretty much unavoidable). So yes, "weaker notion of security", but still applicable to a lot more than just that use-case. I wonder why AES-GCM-SIV is not used more, since it's so developer-friendly and misuse resistant.
Being able to see if two messages are equal means that it doesn’t even achieve IND-CPA security (when nonces repeat). Although this may seem like a small loss of security, it can have significant consequences. For example, when you are performing encryption of long messages, you generally want to split them into smallish chunks -- otherwise you’ll likely have to release unverified plaintext during decryption unless you buffer the entire message in memory. But now if your AEAD reveals message equality, like AES-GCM-SIV does under nonce reuse, then an attacker can see when chunks are equal if you are not careful. So you can end up vulnerable to the kind of chosen plaintext attacks that are devastating against ECB encryption.
Phillip Rogaway, co-inventor of the original SIV mode and the MRAE security model, discusses BEAST-style chosen plaintext attacks against online encryption modes using MRAE schemes in https://eprint.iacr.org/2015/189.pdf. As he says in that paper: "The paper defining MRAE never suggested that nonce-reuse was OK.” It leads to security weaknesses, and AES-GCM-SIV has increasing likelihood of nonce reuse after 2^32 messages.
So, yes, AES-GCM-SIV is a lovely piece of work, but if you want to encrypt large numbers of messages with a single key, then you need to be very aware of the security definitions. I wouldn’t recommend it for general use.
> AES-GCM-SIV has increasing likelihood of nonce reuse after 2^32 messages.
While I agree on your cautions, this is still an exceptionally large number. Also AFAIK the actual bound depends on the message size, e.g. you can "safely" encrypt 2^64 messages of ~128 KiB each with the identical key but random nonce. So as long as one keep using as random nonce as possible but allowing for a few exceptional reuses, casual developers indeed have a very low chance to actually reach that threshold.
Talking about Rogaway: I implemented OCB3 a long time ago as an exercise (after failing for many weeks to get GCM working. I am neither a programmer nor mathematician). Iirc it could have any nonce length up to 120ish bits. I don't remember much from it.
Could it be extended in a similar way to be more like xchacha with 192 bit nonces where using random nonces are easier?
I don’t remember much about the specifics of OCB. But the xchacha/xsalsa20 approach is completely generic, so can be applied to any cipher: effectively just run a large nonce through a PRF to derive a fresh key for each message.
Mainly by looking at what addresses the original bootloader loads them into. The addresses don't matter too much, as long as you load them into valid memory, since for most you pass a reference to them anyway in later steps.
I'm a hobbyist that's been tinkering with uboot now and again for years and can never figure out the right addresses for stuff, or where / how to learn this.
I assume this memory is subsequently released for the OS? Or does the OS just work around it?
Are you hobbling your runtime experience in some way if you load to the wrong address?
This is raw memory, so the concept of malloc/free does not really exist: the OS will just overwrite the data.
I think (not entirely sure) that the kernel gets relocated to a more or less fixed address in memory anyway, this won't affect your runtime experience.
(author here) We use the device instead of a Raspberry Pi, not for anything too serious: we attached it to a screen and have a small server running with an API where you can write single pixels into the framebuffer (a bit like /r/place)
It is, because Broadcom had a surplus of them and couldn't get anyone to adopt it for a streaming device. So an enterprising Broadcom FAE decided to turn it into an "educational" Linux desktop device.
The "wildly popular" part came when people realized BRCM was dumping these boards cheaper than any existing Linux SBC at the time. The educational angle is long gone.
(author here) this is indeed a Salea clone (one of the first results when searching for 'logic analyzer' on Aliexpress), with pulseview/sigrok as software. I try to use cheap tools if possible, so it's more accessible for other people to reproduce.
I’m about to attempt to do something similar on Deco routers, using [this](https://blog.keane.space/tp-link-deco-m5-hardware-hacking.ht...) as a base, but have never wired serial to usb manually before. My main question is how do you use a multimeter to tell which pad is which?
You first need to find ground. You can do this by visual inspection (a bit less risky), or by using your multimeter in continuity mode across external metal parts (for example the outside of the USB port)/negative pin of the power supply. Then, you can use a logic analyzer to find the serial TX pin. The RX pin is usually pretty close, and might be pulled up through a resistor to VCC.
