TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Dobrý den,
napadlo mne projet šifrovaný text cyklem a na základě náhody buď appendovat, anebo insertovat do nulté pozice.
Grafoman
for(int index = 0; index < inputLength; index++)
if(numberGenerator.Next(10) <= 5)
output.Append(input[index]);
else
output.Insert(0, input[index]);
Může mi pomoci mapa příznaků k rozšifrování? (V if ukládat 1, v else 0 - výsledné binární číslo pak uložit jako skupinu znaků.) Nenapadá mne jak ji použít...
Děkuji.
Proto je tam kód... Když bych vytvořil pole 0 a 1 -> 1 pro if, pro else 0; šlo by nějak z toho dešifrovat?
ja vubec nechapu co vlastne delas.
pises "projet šifrovaný text cyklem" jakoze jeste jednou zasifrovat uz zasifrovany text ? nebo chces plaintext zasifrovat "svoji sifrou" ?
pokud chces sifrovat svuj text na zaklade nahody timto zpusobem jedna se o druh transpozicni sifry. pokud se jedna o nejaky skolni priklad budiz. realne uplne bez sance sifrovat cimkoliv co neni "moderni" blokova/proudova sifra.
pro praci s touto sifrou bych doporucoval tridu BitArray (http://msdn.microsoft.com/….110%29.aspx). samozrejmne ze jak si to zasifroval tak stejne to i rozsifrujes.
Nahlásit jako SPAM
IP: 78.136.173.–
for(int index = 0; index < inputLength; index++)
if(numberGenerator.Next(10) <= 5)
output.Append(input[index]);
else
output.Insert(0, input[index]);
Pomůže mi mapa booleanů, která vyjde když pro každé písmeno uložím jeho cestu? (zda šlo appendem, anebo insertem) 1 - appendem, 0 - insertem; Vtip je v tom, jak pak dohledat, kde je první písmeno atp. - dalo by se to najít? Co je na tom nejasné? 111000100110111011000 -> pomůže mi to rozšifrovat onen text? (ukládal bych to do znaků - tak by bylo vpodstatě nemožné na takovou šifru přijít...)
Děkuji.
Jestli to spravne chapu, tak mas text
Welcome world
a ten kod jej sifruje tak, ze nahodne dava pismenka na zacatek nebo na konec. Cili treba
W - konec
e - zacatak
l - konec
c - konec
o - konec
emeorldw oclW + 1011100/1/1000
Coz je velmi zajimave. K tomu pridas pomocny binarni kod, ktery asi pomoci base64 premenis na pismena. Jedine, co potrebujes vedet je pak delku toho textu nebo klice, ktery jsi pridal nebo ho nejak oddelit. Cislo se da take zapsat pomoci base64. A nebo by slo postupovat automaticky od konce, dokud jsou nejake znaky bez delky klice/textu
Lustitel bude vychazet prave z informaci navic, jako je klic nebo jeho delka, pokud bude v lusitelne podobe vyrazne odlisna od ostatniho. Take, pokud vzniknou useky srozumitelnych slov dopredu nebo pozpatku. Z toho urci, ze je tam algoritmus, ktery slova nejak rozhazuje ve smeru vpred a vzad a pokusi se hledat v klici prave 0 a 1, ktere urcuje, kam bylo pismenko premisteno. Tez muze proste pouzit algoritmus vsech moznosti, ktery mu bude brat pismenka zepredu, ze zadu s tim, ze bude uvazovat, ze je tam nejaky klic, a ze nezacne uplne na zacatku. bude zahazovat moznosti, ktere neobsahuji slova ze slovniku. Pro soucasne pc asi 1-2 dny lusteni, myslim. :)
Sifrovany text zasifrovat timto muze byt ovsem zajimave :)
Uvažoval jsem spíše o separátoru - použil bych netisknutelný znak... Neřeším jak dostat klíč, řeším jak ho použít... Problém je na snadě - nevím kde je začátek! To řeším - neznám současné pořadí čísel - to pořadí dávám spolu s appendováním/insertováním - tudíž to neodpovídá... Leda ho dávat jinak - jak?
Děkuji.
Pochybuji, že by 2 dny stačily na rozšifrování věty zapsané argotem...
Pokud potřebuješ opravdu šifrování, použij raději to co už je hotové. Součástí .NET je podpora šifrování, najdeš to v namespace System.Security.Cryptography.
http://www.aspnet.cz/Articles/147-symetricke-sifrovani-aes-rijndael-v-net.aspx
Pokud jde o neprolomitelnost, běžný člověk (amatér bez hlubokých znalostí matematiky) rozhodně spolehlivější šifry nevymyslí. Pokud jde pouze o nečitelnost (a neprolomitelnost není nutná), pak můžeš použít obyčejné XORování. Ale proč, když už tam ten šifrovací namespace stejně je a stačí zavolat jednu funkci...
Vlastní šifrování nevymýšlej. Amatérsky vymyšlené šifrování (obvykle spočívající v náhradě nebo přesouvání nějakých písmenek) nechrání text silou šifry, ale pouze předpokládá, že útočník nezná algoritmus dešifrování. A algoritmus dovedou experti najít, jsou na to šikovné metody (např. frekvenční analýza). Skutečná síla spočívá v tom, když je znám algoritmus a přesto bez znalosti klíče není možné text dešifrovat.
#7 Matěj Andrle
no mas pravdu taky pochybuju ze by to trvalo 2 dny to rozlustit. pokud by neznali ten algoritmus tak to maji asi za +- 6h. pokud by ziskali tvuj program (exe soubor, ktery to sifruje) tak by jim rozlusteni (bez klice) trvalo asi tak 2s.
jinak znova rikam ze pokud se jedna o skolni priklad tak ok. ANO pokud si ulozis posloupnost 1 a 0 tak ANO de to rozsifrovat. k implementaci doporuciji pouzit tridu BitArray.
Jo, no, tudle jsem tvrdil, ze obejit hash md5 je taky brnkacka a popsal jsem i zpusob. O par let pozdeji se toho chopil nejaky student, aby to dokazal a zpusob pouzil uplne ten samy.
Jak uz jsem rikal, kdyby slo o normalni text, tak je pravdepodobne, ze vice znaku po sobe vytvori casti slo. A tudiz z toho by sa dalo usoudit, ze je algoritmus jednoduchy. A kdyz ta slova budou smerem doprava nebo doleva, z toho se da usoudit, ze to to pise smerem dopredu a po zpatku. A prvni, co mne napadne, ze dela prave to, co jsem uvedl nahore s tim Welcome. Pak uz by to byla brnkacka.
Kdyby to delal program, tak by na to take prisel brzy.
Kdyby pouzival hrubou silu, kdy projde asi 10 kombinaci dopredu a dozadu, tak pocitam, ze soucasne bezne pc to do 1-2 dni zvladne.
Pokud by ale puvodni kod nebyl text, ale sifra, tak nevim, zda by si s tim poradil :)
Pokud bys chtel neco podobneho na michani pismenek, kde je treba take klic, pak se da pouzi gzipove BWT transformace fungujici na principu serazovani. Vysledny text bude vicemene serazen podle abecedy.
http://peter-mlich.wz.cz/…cryptbwt.htm
Nebo muzes pouzit zrovna zip algoritmus, ten zadne klice nepotrebuje, vytvari si ho primo z kodu.
Pr. BWT, posledni odstavec od Romana Z by vypadal takto:
téíeizoasmež,váaá.í.yéoau,iusA.sáke,ee,utí)híoěvíeíéy.íí akmtáyt)říj .vn lzn nnn jrvml eoeýí koe áeadtnčbřjtvrmp vdnžřzltnnmřnlllni iiiilllccáštrštršršsšš aěae SeiíoeayskaaíaaakaikššV táo ttsyAyže zzčače(v áz čá e á áe átrmltgtptktsddgrgtpplsbp(rr saxd sfofeofofhhféfoeu juu íe raax ssi ue íriiúx asmkoommoooo íkooou íbo eoeeeddrvmvkv e ýeunvnvndlrvnvvnnntnlčsnjnnnpncjčnnn lkmíoenoondppppe e yý oy
klic = 72
jeste mne napadlo, ze by slo pouzit treba prvocislo nejake vysoke v binarnim kodu jako klic. Zapsat jeho poradi v prvocislech. Treba
1 2 3 5 7 11 13 17 19
19, 9. v poradi.
Ale, zas, kdyby se to pravidelne opakovalo, i s velkym cislem, tak by to mohlo byt napadne.
Jeste by slo ten binarni kod ulozit nekde doprostred kodu na pozici X, ktera by byla random cislo a toto cislo ulozit na konec nebo na nejakou presnuo pozici, treba 1/5 kodu, takze by to byl takovy dvojklic. Protoze vetsina koderu klic da prave na zacatek nebo konec textu. Base64 by se v tomto pripade asi dobre uplatnilo.
#11 peter
Jakmile se mluví o tom, že by něco mohlo být "nápadné", znamená to, že se spoléháte na to, že útočník nezná postup, jak text dešifrovat. To je špatné, protože:
1. na postup lze přijít matematickými metodami - to že tvůrce šifry nevystudoval matfyz a tudíž nemá ponětí, že to jde, ještě neznamená, že to nejde. Nemyslím to jako urážku, někdo si prostě sám nespraví auto, někdo si sám nezaplombuje zub, no a někdo si sám nespočítá hash - na tom není nic špatného, jen je třeba si to uvědomit.
2. na postup lze přijít snadno reverzním inženýrstvím - pokud získám program, který umí data dešifrovat, tak ho prostě disasembluju (nemusím být matfyzák, u .NET aplikací je to brnkačka i pro nezletilé).
A proto: každé šifrování, které si někdo navrhne sám doma, bude zákonitě horší než to, které máte vestavěné v .NETu. Já vím, že ty nápady s posouváním a přehazováním písmenek (Cézarova šifra, šifrovací tabulka apod) fungovaly na letních táborech. Mějte na paměti, že tam byli vašimi protivníky stejně staré děti a ne týmy profíků s akademickým vzděláním. Jestli si to vymýšlíte pro zábavu, OK, to je v pořádku. Jen byste měli mít představu, že takové podomácku vymyšlené šifry ve skutečnosti nejsou bezpečné ani pro Vaše soukromé účely, natož pak pro nějakou firemní zakázku, neřku-li banku nebo státní instituci.
Chcete-li mne soudit, luštěte:
2xnkK5r6 -> (ras)Uio(sad)Ghh(fas)m5xiOk
Je v tom 16 vět... Algoritmus jsem vymyslel už docela dávno - jedná se o sadu běžných vzorců k výpočtu pí. Výsledkem je vzorec k rozluštění...
#13 Matěj Andrle
1. jake souzeni omg ? kazdy ti rika ze mas pouzit normalni sifru budto neco symetrickeho (aes,des,tripleDes, ...) nebo hybridni sifru.
2. do ted si nerekl jestli to chces jako skolni priklad nebo nasazeni v realne aplikaci.
3. taky si nerekl jestli chces sifrovat plaintext nebo sifrovat jiz zasifrovany text.
4. gratuluju ze se ti podarilo dostat 16 vet do 39 znaku.
OT
p3can - 4. gratuluju ze se ti podarilo dostat 16 vet do 39 znaku.
:)))
Tusim jsem nekde cetl, ze kompresni pomer pro plain text teoreticky je kolem 6%, realne mezi 10-20.
Pokud pocitam 5 pismen na slovo, veta 6 slov, pak 16x6x5 = 480 znaku na 39, to je zhruba 1/12, tech 8%, coz odpovida aritmetickemu kodovani. Dobry vysledek.
Pokud jsi pouzil PI, jak rikas, pak nejspis jsi skupiny cisel nahradil pozici v PI retezci, vicemene jako aritmeticke kodovani.
Zkus ted neco jineho. Vem tento soubor a zkus ho zabalit znovu s upravou nejakeho spesl algoritmu tak, aby to dalo aspon 96%. Coz je neco, co se mi podarilo uz pred lety za pouziti xoru s predchozim bitem (a ted presne nevim, zda bit vysledku nebo ze zdroje nebo mozna jiny). Pak muzes komprimovat do nekonecna, jen musis vedet, kolikrat si algoritmus na to pouzil.
Asi jsi to alespoň ty pochopil... :D V čísle pí jsou všechny věty světa... (všechny lokace, písma,...) Ovšem aby to nebylo tak výpočetně náročné, můj algoritmus vyhledává nejbližší sekvence obasžené v šifrovaném textu - o velikosti alespoň 10% znaků... Tudíž onen vzorec obsahuje informace o těchto útržcích a spojí je v určitém diagramu - kterým se pak dají zpětně vyhledat v čísle pí. Samozřejmě bližší způsob neprozradím, ovšem není to zase tak jednoduché, jak píši.
A o něco méně bezpečný, zato hodně výpočetně náročný způsob je, že ukládám pouze počet opakování algoritmu k prohledávání čísla pí. Tím jsem dosáhl redukce na 1 jediný znak... (Unicode)
No, pochopil, ja tuhle moznost zvazoval uz davno. Jen se mi nechtelo optimalizovat vyhledavaci tabulku (Ze si udelam indexy jako v mysql pro tabulku [id, 3 znaky, pozice v pi]. Vyhledam pak vsechny trojice, ktere odpovidaji a z nich pak vyberu nejvetsi shodu. Nebo, jak rikas ty, najdes prvni, aspon 10% shody.).
Vtip je v tom, že nezáleží na délce. Zkrátka kilometrový text můžeš najít v pí během chvilky, ale kratičký během hodin... Tudíž neskládám do 100% - určité části se překrývají. Pročež když to následně rozšifruji, výsledný text může být 8x (800%) větší... K tomu dát to dokupy slouží ty závorky... (Určují jak moc se dané části překrývají.) A k současnému nápadu - postupuji nakonec tak, že binární pole zamíchám právě tak, jako šifrovaný text - tím si text i pole odpovídají... (for binarniPole if(value = 1)append(value) else insert(value))
#16 peter
ok tak gratuluji ze si vyresil problem se zapornou kompresi. doporucuji si zalozit sw firmu a muzes primo konkurovat sw gigantum jako IBM a oracle.
Zkus ted neco jineho. Vem tento soubor a zkus ho zabalit znovu s upravou nejakeho spesl algoritmu tak, aby to dalo aspon 96%. Coz je neco, co se mi podarilo uz pred lety za pouziti xoru s predchozim bitem (a ted presne nevim, zda bit vysledku nebo ze zdroje nebo mozna jiny). Pak muzes komprimovat do nekonecna, jen musis vedet, kolikrat si algoritmus na to pouzil.
hej pls ne 
Zjistit počet nových příspěvků
Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku
© 2003–2024 Programujte.com