lol, i just accepted the title tag from the page which the create post form auto-filled 🤡

Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve

I somehow first read "Redhat" as "Reddit" in this sentence, and so was briefly thinking that perhaps this bad idea originated there 😂

Otoh, the Washington Post and their "experts" didn't think any of those civil rights movement direct actions they're celebrating now were reasonable at the time either 🤡

rare meta w

python -c 'print((61966753*385408813*916167677<<2).to_bytes(11).decode())'

(probably the most downvoted post i've made yet on lemmy 😂)

and logs timestamps/IP addresses

what makes you say that?

I have read it at https://www.securemessagingapps.com

That website has a lot of things wrong, and provides no citations for most of its claims: it just says "Yes" or "No" about most things.

SimpleX says they don't log IP addresses, and their claim is at least as credible as anyone else's. I suspect the securemessagingapps web page gave them a "No" in that column because SimpleX is refreshingly honest in their threat model and privacy policy, and thus mentions that even though they don't log IPs their hosting provider (or the hosting provider of other SimpleX servers - you don't have to use one of theirs) could be. They currently recommend using Tor to mitigate this problem.

Oxen people argument: “under typical circumstances, the only way long term keys can be compromised is through full physical device access — in which case an attacker could simply pull the already-decrypted messages from the local database.

Most chat apps allow you to delete old messages, both on an individual message basis and automatically after some period of time. Does Session not?

As is often said in the infosec community, physical access is total access”

Who would say that, except someone trying to excuse their protocol's lack of forward secrecy?

There is no reason why physical access to a device should mean total access to messages that were deleted previously; all serious secure messaging protocols today use forward secrecy to limit the impact of device compromise.

Furthermore, most modern (eg, designed in the last decade or so) protocols also provide post-compromise security (aka "backward secrecy", "future secrecy", or "self-healing") to introduce new entropy into their ratchets such that when a device is temporarily compromised (as is actually very often the case in real-world attacks on mobile operating systems) the key material which an attacker can exfiltrate doesn't allow them to decrypt future messages which are sent later after the device is uncompromised (eg, rebooted).

If you're ready to break free of Android, I would recommend https://postmarketos.org/ though it only works well on a small (but growing!) number of devices.

imho if you want to (or must) run Android and have (or don't mind getting) a Pixel, Graphene is an OK choice, but CalyxOS is good too and runs on a few more devices.

Thank you. I have read that the Session is not yet using quantum-resistant cryptographic algorithm. It is using X25519 which is an elliptic curve algorithm widely used for key agreement in TLS today. As a layman, I do not expect this to be a problem for a regular user (who is no target of the US three letter agencies) in the near future.

The lack of forward secrecy and lack of post-quantum encryption are orthogonal deficiencies. The development of a cryptanalytically-relevant quantum computer is only one of the ways that a long-term key could be compromised in the future, and forward secrecy without some PQ crypto does not actually even protect against that.

The reason to have forward secrecy (even if you don't have PQ) is that long-term keys can be compromised in the future by malware or device seizure. See the forward secrecy wikipedia article i linked in my previous comment for more information.

According to https://www.securemessagingapps.com/ Session uses: X25519 / XSalsa20 256 / Poly1305

These are good cryptographic choices, albeit not PQ. The problem is that they aren't being combined in a forward secret manner. It is very possible to build a forward secret protocol from these primitives (as many other projects have done) but Session opted not to. They actually were originally using Signal's forward secret ratchet, but if i understand correctly it was too difficult for them so they just gave up on forward secrecy at some point and replaced it with this thing they have now.

While Simplex uses: Curve25519 / XSalsa20 256 / Poly1305

SimpleX actually added Streamlined NTRU Prime recently for quantum resistance. (And it was forward secret from the beginning, as one would expect of any protocol designed in the last 15 years or so...)

and Simplex does not provide transparency report

Actually they do, here: https://simplex.chat/transparency/index.html

and logs timestamps/IP addresses

Huh? I don't think so... what makes you say that?

i guess maybe if you're using a device with a tiny screen and a lemmy client that doesn't let you zoom in on images

Hi, I'm an admin on lemmy.ml. The account of the one existing mod of the session community here has apparently been deleted.

I've heard there are some bugs with moderation of remote communities, but, I just made you a mod there anyway. I don't know the state of those bugs; it might work better if you made an account on this instance.

Btw, I recommend against using Session for a variety of reasons including the one I posted in your thread here.

I just skimmed that audit (from 2021) and hit ctrl-f for "forward secret" (no results) and then "ratchet"... which found this:

Even though there is no ratchet mechanism as in Signal, no correlation exists between ciphering keys over time. This observation is made on the basis that crypto_box_seal creates a new key pair for each message, and attaches the public key to the ciphertext. crypto_box_seal creates an ephemeral keypair and uses the secret part with the recipient public key to craft a symmetric key in charge of ciphering messages. The recipient will extract the ephemeral public key from the ciphered message and will use their private key to regenerate the ephemeral symmetric key for this message.

Having an ephemeral DH public key included with each message does not make the symmetric key ephemeral and thus does not make the protocol forward secret, because the other side of the DH is the recipient's long-term key. So, an adversary who records some ciphertexts and then compromises the recipient's long-term private key years later can easily decrypt all of the old ciphertexts they collected.

There are several other reasons I wouldn't recommend Session, but the lack of forward secrecy is a big one.

I haven't read the rest of the audit but the fact that they gloss over the lack of forward secrecy and strongly imply that crypto_box_seal with one ephemeral key and one long-term key makes the symmetric key somehow "ephemeral" casts doubt on the credibility of the auditors.

I would recommend https://simplex.chat/ instead. There is a lemmy community for it at /c/[email protected]

It’s literally a covert project funded by google to both sell pixels and harvest data of “privooocy” minded users. It seems to be working well.

Is it actually funded by Google? Citation needed.

I would assume Graphene users make up a statistically insignificant number of Pixel buyers, and most of the users of it I've met opt to use it without any Google services.

17 × 59 = 10003

you've got an extra zero in there, and you forgot the 1, but the rest of your divisors match my crude brute-force approach:

>>> n=31521281
>>> d = [ x for x in range(1,n//2+1) if not n%x ]
>>> d
[1, 11, 17, 59, 187, 649, 1003, 2857, 11033, 31427, 48569, 168563, 534259, 1854193, 2865571]
>>> yours=list(map(int,"11+17+59+2857+11033+534259+1854193+2865571+168563+48569+10003+31427+649+187".split("+")))
>>> set(yours) - set(d)
{10003}
>>> set(d) - set(yours)
{1, 1003}
>>> sum(d)
5518399

same conclusion though: 5518399 also ≠ 31521281

>>> isperfect = lambda n: n == sum(x for x in range(1,n//2+1) if not n%x)
>>> [n for n in range(1, 10000) if isperfect(n)]
[6, 28, 496, 8128]

>>> divisors_if_perfect = lambda n: n == sum(d:=[x for x in range(1,n//2+1) if not n%x]) and d
>>> print("\n".join(f"{n:>5} == sum{tuple(d)}" for n in range(10000) if (d:=divisors_if_perfect(n))))
    6 == sum(1, 2, 3)
   28 == sum(1, 2, 4, 7, 14)
  496 == sum(1, 2, 4, 8, 16, 31, 62, 124, 248)
 8128 == sum(1, 2, 4, 8, 16, 32, 64, 127, 254, 508, 1016, 2032, 4064)

shoutout to the person who reported this post with "Reason: Bot meme, you can't even read it. whoever replies is a bot too" 😂

https://en.wikipedia.org/wiki/Chad_Bianco

it’s the same joke as “caesar salad was invented by julius caesar”

Except it's a bit different because the Caesar in Caesar salad (named after chef Caesar Cardini) is actually spelled the same way as Julius Caesar, whereas Neapolitan (meaning of Naples) is not related to the name Napoleon at all.

It hadn't occurred to me that Neapolitan ice cream might have something to do with the name Napoleon before I saw this meme; the similarity of the words and incorrect implication that they are related is what makes it funny.

I think OP has no idea that it’s called Neapolitan ice cream

(i think you're mistaken, and also that OP's meme is good)