Kan vi bruke en annen DEM som AES for å oppnå det samme men mer effektivt? Mener å huske noen skrev om AES med deniable properties nylig. Blogpost om hvordan man kan få deniability med AES-GCM: https://keymaterial.net/2020/09/07/invisible-salamanders-in-aes-gcm-siv/ Basert på paperet "Fast Message Franking: From Invisible Salamanders to Encryptment": https://eprint.iacr.org/2019/016.pdf som igjen er basert på "Message franking via committing authenticated encryption": https://eprint.iacr.org/2017/664.pdf (se spesielt Sect. 5.4: Some Non-binding AEAD schemes) Fra bloggen: "... interesting property of AES-GCM, that allows an attacker to construct a ciphertext that will decrypt with a valid tag under two different keys, provided both keys are known to the attacker." "... choosing the plaintexts so that the ciphertexts agree (If you want two plaintext that make sense, this part is the hardest step, you first brute force the first few bytes in order to be valid in one format and a comment opening statement in the other, so that you can switch which parts of the ciphertext will appear as valid plaintext and which parts appear as commented out)." Hun laget kode i Java: https://github.com/sophieschmieg/fun-with-gcm/blob/master/FunWithGcm.java ... men jeg har ikke klart å få den til å kjøre. Maile henne og høre om hvor mye frihet man egentlig har i å velge meldingene? Fra "Faster Message Franking", sect. 3: "We will describe two variants of the attack. We will begin with the case where the second decryption of the colliding ciphertext is junk bytes with no particular structure. This variant is simple but easily detectable, since the junk bytes will not display correctly. Then we give a more advanced variant where the second decryption correctly displays an innocuous attachment, like a picture of a kitten." Se 3.2 for detaljer: Funksjonen Att-Merge tar inn to nøkler og to meldinger og spytter ut en NONCE og en ciphertext slik at den dekrypterer til M1 under K1 og M2 under K2 (med samme nonce). Så dette minner veldig om den første idéen jeg hadde, hvor vi kunne bruke den enklere RAR-notionen istedetfor en ROP notion. Trodde ikke det ville være nok frihetsgrader (mener Martijn ga et overbevisende kombinatorisk argument—hva var det igjen? A: se p.46, main-mih_010222. Long story short: får en implikasjon til perfect secrecy, og vi er derfor med én gang i Shannon-land.) men kanskje det er NONCEn som tillater dette + at det ikke er *helt* fritt valg over meldinger: "We chose JPEG and BMP files for our Att-Merge proof of concept because their formats can tolerate random bytes in different regions of the file (the beginning and the end, respectively)." - Altså får man ikke noe som dekrypterer *eksakt* til M1 og M2 for frie valg av M1 og M2. - De bruker spesifikt filspesifikasjonene til å komme rundt dette og gi basically frie valg av *bilder*. - Men det ville kanskje brutt RAR -> LOR-idéen? - På den annen side, viser ikke dette at det eksisterer en enkoding av arbitrære meldinger, slik at vi kan bare gjøre det til en del av spesifikasjonen til vår DDEM? Argh! Fra [[Deniable Encryption]]: It is possible (details omitted for lack of space) to transform any given shared key encryption to a deniable one, without any increase in the message length, and with a key of length 1 - 1/(number of alternate messages) times the length of the message. The shared-key deniable schemes can also be used to make public-key deniable schemes more efficient by way of first sending (using public-key deniable scheme) a deniable shared key and then switching to a private-key (deniable) scheme. We omit the details from this abstract. Okei så det de sier på slutten der er at Deniable KEM + Deniable DEM = Deniable PKE. Men hvordan ser denne generelle transformasjonen ut?? Må jeg gjenoppdage den selv, eller eksisterer den i litteraturen? Kanskje det står noe her (Weak and Strong Deniable Authenticated Encryption): https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8514181&tag=1 - Nei, dette er en annen definisjon av deniable ("deniable authentication" vs deniable encryption), nemlig at Bob kan autentisere meldinger slik at de ser ut som de kom fra Alice selv om hun aldri sendte de. - Interestingly, Colin har et paper fra 2005 om deniably authenticated key exchange: https://link.springer.com/chapter/10.1007/11542322_31 (Merk: key length = message length/2 for to meldinger, så vinner ikke SÅ mye, men det går kanskje greit.) Merk også at denne definisjonen av Deniable DEM *er* oppfylt av OTP: key1, key2, m1, og m2 kan ikke alle velges fritt (og, i motsetning til OTP som kan velge (m2, k2) at time of attack, må dette velges at time of encryption generelt). Se også definisjonen av Clawed DEM i f.eks. main-mih_040221 ---- Se også: [[Deniable Encryption]], [[Tanker om transformasjoner]]