crypt (enigma) z BSD

[Vladimir Dvorak]

Miroslav BENES wrote:

>
>> Zamita se. Pokud pres firewall projdete az do DMZ k serveru na port 21,
>> potom samozrejme muzete pred jednadvacitku posadit stunnel nebo ssh.
>> Otazkou je, aby tato uprava nemela negativni dopad na stavajici operace
>> s vaseim ftp serverem; potom byste skutecne musel pouzit u vaseho ftp
>> serveru napr. STARTTLS ficuru, ktera by umoznila volitelne data
>> sifrovat.
>>  
>>
> Zamítá se.
> Fiewall funguje jako aplikační proxy, která rozebírá i "vnitřek"
> spojení a jednotlivé použíté příkazy ..
> Pokud by se mělo použít ssh, musela by data protékat přes "obyčejnouL
> generickou TCP proxy, která nijak nekontroluje obsah -> byla by nutná
> změna konfigurace na fw.
>
Skrz aplikacni proxy lze "protunelovat" ledacos, resp. protokoly sedme
vrstvy ISO modelu <--pokud to ovsem umozni. Jinymi slovy - klidobrdo
protunelujete SSH skrze Squid ( napr. pouzijete dalsi vrstvu OpenVPN ).
Tim muzete obejit superduper firewall paar excellance. ;-)

>
>> Jde vam tedy o sifrovani nebo ne ? Pokud v ceste je nejaky transparentni
>> antivir, pak sifrovani ho odstreli a antivir bude tudiz k nicemu. Takze
>> tady je odpoved spise na organizacni urovni, nikoliv administracni.
>>  
>>
> Asi jsem se blbě vyjádřil .. Jde o to, že se budou ty data štosovat na
> některém z vnitřních serverů. A protože není "přímá viditelnost" mezi
> stroji na kterých data vznikají a stroji, kde se budou ukládat, musím
> využít mezistupeň - ftp sevrer v DMZ, dostupný z obou míst. A protože
> je nenulové riziko, že by mohl být kompromitován, je potřeba tento
> mezikrok (tedy dočasné uložení na ftp a následný přenos do vnitřní
> sítě) provádět tak, aby ta data byla pro případného útočníka nečitelná.

Idealni reseni je tedy takove, ze jiz pri odesilani dat na komunikacni
most (server v DMZ), budou tato data zasifrovana. Jinymi slovy - necht
uzivatel(aplikace) vse implicitne sifruje a mate to vyresene. Potom se
skutecne nemusime bavit o SSH a SSL, v tom pripade staci pouze ftp ( i
presto, ze man-in-the-middle odchyti autentizacni par, je mu zasifrovany
material k nicemu ) a digitalni podpis (skutecne realizovany
prostrednictvim treba vami navrhovaneho gpg ). Otazka, na kterou si
musite zodpovedet sam, ale je, kdo vuci komu bude prokazovat autenticitu ?

>
> Navíc je jako podmínka (pokud možno) neměnit nastavení fw.
> BTW antivirák ty data neodstřelil - asi mu to připadalo jako shluk
> náhodných čísel a nepoznal v tom zakryptovaný archiv :)
>
>
>>> (vycházím z předpokladu, že ze soukromého klíče se dá vypočítat
>>> veřejná část, takže to nemůže být postaveno naopak).
>>>   
>>
>>
>> Tak to opravdu nefunguje. Jak muzete z cisla vypocitat jine cislo ??
>>  
>>
> A jak je tedy možné, že si do nějakého programu (tuším puttygen)
> naimportuju soukromý klíč a můžu následně vyeportovat veřejný ? Aspoň
> se mi to takto jednou chovalo ..
>
Doporucuji naimportovat trosku vice znalosti z oblasti asymetricke
kryptografie - matematicke vyjadreni algoritmu RSA, ElGamal,
Diffie-Hellman vymeny .... to jsou ty prave kapitoly, kterymi bych zacal.

S pozdravem,

Vladimir Dvorak