Portál AbcLinuxu, 5. května 2025 03:01
libpng
na to prostě nemá API, takže PNG se stejně zapisuje do paměti, během čehož se v podstatě znovuvytvoří... (viz Codec::finalize())
No ale budu tím pádem muset IV přidat do dat (nejspíš na začátek), což zvýší overhead. Jak dlouhý by měl IV být? Na wiki píšou, že obvykle má stejnou velikost jako blok šifry, stačilo by?Ano, IV se prostě přidá někam na začátek dat (není tajný, jenom musí být unikátní). Nemyslím, že by třeba 16 bytů zásadně ovlivnilo poměr režie/data (spíš je to jenom drobný oser to tam přidat). Ano, délka IV je typicky délka bloku u blokových šifer.
Ad LogisticMap: určitě nedává náhodná čísla, ale já ani nemůžu dost dobře ty pozice generovat náhodně, že (kam bych to ukládal). Zajímalo by mě, jak na tom je Logistic Map v porovnání s nějakým polynomem nad GF(p) (případně něčím na způsob ECC) co do nepředvídatelnosti výsledných hodnot.Možná nerozumím proč by nešlo použít "prověřený" PRNG. Seed bude něco vygenerované z master key (plus případně dalšího IV), hodnoty jsou pak deterministické. Akorát se to musí namapovat na substrát, aby ta funkce byla "na".
Ad frequency domain: Hm, nejsem si jist, jakože by např. Xz určovala, které frekvence mírně modifikovat?Tohle spíš je otázka API (než crypto). Do frequency domain prostě nelze "embedovat streamově", tj. seekem vpřed nebo vzad. Ale stačí se dívat na ten soubor jako "block device", které nikam neuteče (holt nebude to fungovat pro pajpu
Ano, IV se prostě přidá někam na začátek dat (není tajný, jenom musí být unikátní). Nemyslím, že by třeba 16 bytů zásadně ovlivnilo poměr režie/data (spíš je to jenom drobný oser to tam přidat).No... bude změna pár řádek... jen až se k tomu zase dostanu, což teď se začínajícím zkouškovým asi nebude hned...
Možná nerozumím proč by nešlo použít "prověřený" PRNG. Seed bude něco vygenerované z master key (plus případně dalšího IV), hodnoty jsou pak deterministické.Ok, jestliže jsou hodnoty deterministické, asi by se to dalo použít. Mrknu na to též...
Tohle spíš je otázka API (než crypto). Do frequency domain prostě nelze "embedovat streamově", tj. seekem vpřed nebo vzad. Ale stačí se dívat na ten soubor jako "block device", které nikam neuteče (holt nebude to fungovat pro pajpuJasný, už od pohledu na tu funkci jes vidět, že jestliže to je integrál nebo suma, nepůjde to "streamově". Ale to nevadí, s API můžu zatím určitě dělat psí kusy... Spíš mi mě zajímalo co si od toho slibovat, myslíš, že ve frequency domain bude více místa a/nebo to bude hůř zjistitelné? A jaká je ztrátovost informací při převodu do freq. domain a zase zpátky?)
Jen telegraficky: důvod psát vlastní knihovnu ? Nevyhovovala stávající řešení jako Steghide ? A v čem ?
Ideální steganografická metoda by mi měla dát možnost říct "tohle je jenom fotka/písnička/video/cokoliv, nemůžete mi nijak dokázat opak". Tedy umožnit mi věrohodně popřít, že tam jsou schovaná nějaká jiná data.Jasný, s tím určitě souhlasím, já jsem spíš jen podotýkal, že by vůbec u nikoho ani nemělo vzniknout podezření, že tam nějaká data jsou, a že by se tě ani vůbec nikdo neměl ptát...
Vím že je to složité, proto jsem taky odkazoval ty steganalytické nástroje, co spoustu současných metod odhalují (zajímalo by mě zda i tu metodu co používáš ty?). Ale teoreticky by to snad nemělo být nemožné, ne?Nemožné to snad není... ale těch problémů je dost. Jak říkám, je to work in progress... Outguess/Stegdetect afaik podporuje pouze jpeg. StegSecret už jsem viděl, ale nezkoušel jsem, byl tam nějakej problém, už nevim... Ještě se na to případně podívám...
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.