There's probably some enterprise level deals going on there (as with every service provider), but they will still be paying them A Lot of Money every year.
Not much, but they'll benefit much more in the short term in reduced taxes by writing down those assets to zero.
Edit: this was downvoted, and I don't understand why. Am I wrong in thinking this action was made in pursuit of a write down? FWIW, this wasn't a thoughtless comment by a random Internet passerby; I hold 41,905 shares of PARA.
Only if you're not encrypting many billions of small messages with the same key, which is a possibility. It's just barely large enough for many uses, and "just barely" makes cryptographers nervous.
No. Extended-nonce constructions solve that problem by using the "large" nonce along with the original key to derive a new key. You then have the "small" nonce space plus the key space worth of random bits.
>What happens if you repeat the nonce? You’re going to mess up authenticity for all future messages, and you’re going to mess up privacy for the messages that use the repeated nonce.
The loss of privacy on OCB nonce reuse is not as severe. It would be more or less the same as with ECB mode.
> It is the user’s obligation to ensure that nonces don’t repeat within a session. In settings where this is infeasible, OCB should not be used.
But earlier in that section we have:
> […] The nonce doesn’t have to be random or secret or unpredictable. It does have to be something new with each message you encrypt. A counter value will work for a nonce, and that is what is recommended. […]
So given that GCM uses a counter ("C"), and a counter is recommended for OCB, wouldn't it be simple enough to get the equivalent (?) security more efficiently?
The notion of a nonce here is the same as that in GCM. GCM nonces aren't secret and don't need to be unpredictable; in fact, because the nonce space is so small, a common engineering recommendation is to use a durable counter.
Given that OCB (appears to be?) is more computationally efficient than GCM, is there any reason why OCB shouldn't be favoured nowadays given there are no IP issues?
I like OCB and dislike GCM, but GCM is very, very fast and is the de facto standard AEAD, and the runner-up is Chapoly. OCB would be a quirky choice, and maybe trickier to get in every ecosystem you develop in (I ended up writing my own back in the early days of Golang).
OCB is superior to AES-GCM-SIV in every way other than nonce reuse. OCB is faster than generic GCM for any combination of hardware acceleration. OCB is also significantly better than generic GCM for nonce reuse.
GCM-SIV is not perfect for nonce reuse anyway. It reveals to the attacker that two messages are identical.
My proposal was that parts of incomplete uploads would stick around for only 24 hours after the most recent activity on the upload, and you wouldn't be charged for storage during that time. ahenry@ vetoed that.
No, zinccat, you are wrong. Your model is vastly inferior to GPT4.
I tried multiple prompts. In all cases, your model performed far worse. Here is one:
> My bank says they'll pay 5.5% APY. How much will I have after 6 months if I deposit $100?
< If your bank is offering a 5.5% APY (Annual Percentage Yield), this means that the interest is calculated annually. However, you want to know how much you'll have after 6 months, which is half a year.
...
100ata5.5102.75 after 6 months.
woman + intelligence = man (77%)
Oof.