View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008597 | GNUnet | core service | public | 2024-03-07 21:26 | 2026-09-02 12:22 |
| Reporter | schanzen | Assigned To | ch3 | Due Date | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Target Version | 1.0.0 | ||||
| Summary | 0008597: Use Elligator KEM in Core KX | ||||
| Description | Since CORE cannot assume that TNG provides encryption, it does its own KX and we may want to protect the public key of the respective KX. Needs investigation into the Core KX if this makes sense at all. | ||||
| Tags | No tags attached. | ||||
| This probably also will affect PILS since it will have to do the encaps and key generation. The latter is the only special thing wrt elligator. | |
| Not sure if this makes too much sense for the following reasons: 1. Each messages is currently defined to have a plain text message header that can easily distinguished from random and 2. The InitiatorHello contains the following fields: 1. r_I: A random value 2. p_e: An ephemeral public key (curve point) 3. c_R: The KEM ciphertext that could be elligatorified with this big 4. H(pk_R): Could be understood to look random, but allows a simple confirmation attack 5. Encrypted data We could also apply elligator to (2.). But for (4.) even if Elligator is applied, it allows a trivial confirmation attack to distinguish this from random data. | |
| Using elligator for CORE does not make sense wrt its security requirements. OKEM makes sense for communicators to hide in adversarial networks, CORE runs on top. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-07 21:26 | schanzen | New Issue | |
| 2024-03-07 21:26 | schanzen | Status | new => assigned |
| 2024-03-07 21:26 | schanzen | Assigned To | => ch3 |
| 2024-03-07 21:26 | schanzen | Issue generated from: 0008596 | |
| 2024-03-07 21:26 | schanzen | Relationship added | child of 0008596 |
| 2024-03-12 11:44 | schanzen | Issue cloned: 0008630 | |
| 2025-03-27 08:32 | schanzen | Target Version | => 0.25.0 |
| 2025-03-27 08:32 | schanzen | Relationship added | related to 0009666 |
| 2025-07-28 17:41 | schanzen | Note Added: 0025577 | |
| 2025-09-16 10:06 | schanzen | Relationship deleted | related to 0009666 |
| 2025-09-16 10:09 | schanzen | Target Version | 0.25.0 => 0.26.0 |
| 2025-09-22 07:10 | schanzen | Note Added: 0025965 | |
| 2025-11-13 19:53 | schanzen | Target Version | 0.26.0 => 0.27.0 |
| 2026-03-19 07:15 | schanzen | Target Version | 0.27.0 => 1.0.0 |
| 2026-08-19 05:50 | schanzen | Status | assigned => resolved |
| 2026-08-19 05:50 | schanzen | Resolution | open => no change required |
| 2026-08-19 05:50 | schanzen | Note Added: 0029510 | |
| 2026-09-02 12:22 | schanzen | Status | resolved => closed |