#rfc4880 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #rfc4880, aggregated by home.social.
-
No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.
Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.
Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.
Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.
-
No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.
Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.
Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.
Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.
-
No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.
Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.
Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.
Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.
-
No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.
Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.
Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.
Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.
-
No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.
Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.
Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.
Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.
-
Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
-
Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
-
Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
-
Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
-
Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
-
#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGPJohannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison -
#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGPJohannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison -
#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGPJohannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison -
#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGPJohannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison -
#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGPJohannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison -
Using Pushdown Automata to verify Packet Sequences
As a software developer, most of my work day is spent working practically by coding and hacking away. Recently though I stumbled across an interesting problem which required another, more theoretical approach…
https://blog.jabberhead.tk/2022/09/14/using-pushdown-automata-to-verify-packet-sequences/
#automaton #encryption #java #openpgp #pda #pgpainless #pushdown #rfc4880
-
Why Signature Verification in OpenPGP is hard
Signature Verification in OpenPGP is hard. Here is why.
https://blog.jabberhead.tk/2021/04/03/why-signature-verification-in-openpgp-is-hard/
#cryptography #encryption #openpgp #pgpainless #rfc4880 #signatures