Linux за българи: Форуми

Здравейте,
   Искам да направя един cluster който да използвам за изчисления. Знам че има няколко вида софтуери за тази цел. Проблема е че софтуера който искам да ползвам е многонишков, самият той няма опция за използването му с много компютри едновременно.
   Мисля чи ми трябва софтуер за cluster който да разпределя нишките между много машини.
Какви са вариантите?

Поздрави

Не съм сигурна дали разбирам въпроса ти, но наскоро на Опенфест имаше лекция за изграждането на суперкомпютър (в частност клъстър) - тук ($2) са качили слайдовете, видео още няма.

Няма такъв вариант.

Ами реално има ама трябва да се дадат доста пари.
IBM сървърите могат да се свържат айде условно казано директно дънна платка с дънна платка и става така че два сървъра с по 2 процесора и да кажем 8 GB RAM става 4 процесора с 16 GB RAM - това се вижда от OS. Предпалагам е реализирано на ниво BIOS. Както и да е.

Ето какво искам конкретно да постигна.
Имам един rar файл на който съм му забравил паролата а пък вътре ми е важна иформацията. По принцип си слагам парола на архивите със source code. Пробвах със софтуер на една машина да го пусна с brute force. Става но е много бавно, едва 600 комбинации пробва в секунда а аз слагам по принцип големи и сложни пароли.
Трябва ми някакво решение което да пусна на 5 сървъра едновременно да работи.

Тогава не говориш ли за grid, а не за cluster?

Да можеби по-правилно е така да се каже.

Да не ти открадне някой безценния код. И сега падна в собствения си капан (забрави паролата). Лошо.

Да видим сега, 10 символна парола, големи и малки букви и цифри:

N = (26+26+10)^10 = 144,555,105,949,057,024 възможни комбинации.

Със скорост 600 в секунда:

144,555,105,949,057,024 / 600 = 240925176581761 секунди, еквивалентно на 7,745,794 години.

Като си направиш клъстера от 5 машини, няма да го обходиш keyspace-а за 7 милиона години, а само за 1-2 милиона. Значителен напредък.

А иначе:

http://golubev.com/rargpu.htm

С една пъргава видеокарта като HD5970, ще докараш теоретичната пикова скорост на клъстер от 32 машини като твоите, на цена от около 1600-1700 лева (картата+захранването+дъно+някакъв евтин процесор и малко рам). Тогава....ами вместо за 7 милиона години, ще разбиеш хипотетичната 10-символна парола за около 240 хиляди години :)

Брутфорс атаките често не са особено практични.

Друг начин има ли?

Друг начин има ли?

да си спомните паролата

С rule-базирани атаки, особено ако си спомняш част от паролата, би имал някакъв успех. Но ако не помниш или ако е достатъчно дълга и сложна - надали. Проблемът е че igrargpu няма кой знае колко advanced rule engine, а е вероятно единствената програма, която може да троши RAR формата (включително RARv3)  толкова бързо. Вероятно от Elcomsoft имат някакво подобно решение, ама знам ли.

А виждал ли си directory attack  в действие?
Тоест вземаш криптирания стринг. Имаш предварително създадена база данни със генерирани криптирани стрингове и почваш да сравняваш.

Това не е възможно и обяснението е просто.

Да предположим, че имаш "криптиран низ". Колко голяма ще ти стане въпросната таблица примерно за всички пароли от 10 символа съставени от малки/големи букви и цифри? Ще ти издам тайната за ZIP и RAR - и двете хващат паролата и я трансформират в 128-битов (обикновено) ключ за AES декриптиране на компресирания файл. Това става чрез някаква форма на key stretching, чиято цел е да е изчислително-сложна операция, за да отблъсква bruteforce атаките. Най-често това е итеративно викане на някаква хеш функция, примерно няколко хиляди пъти.

Сега да предположим, че искаш да пазиш такава таблица с всички пароли с дължина 10 символа, малки и големи букви (горния пример). Таблицата ще излезе няколко хиляди петабайта, това са милиони харддискове. Като изключим това, дори да ги имаше (и да можеше да си позволиш да им плащаш тока), времето за което ще ги изчетеш, за да сравниш паролата, твърде вероятно е по-голямо от времето, за което дори един от тях ще откаже, което ще ти съсипе акуратността на сметките. Обаче нещата всъщност са по-лоши от това, защото RAR ползва 32-битова псевдо-случайна salt стойност, която е различна за всеки архив. Това означава, че ще ти трябват 4 милиарда по толкова диска, за да покриеш всички salt стойности.

Обаче криптиран низ няма. С горепосоченият ключ, генериран от паролата ти, декриптираш компресираният файл и после го декомпресираш. Ако ключът е грешен, има известна вероятност да го декриптираш до безсмислици, които ще дадат грешка при декомпресията, но ако файлът е достатъчно малък е възможно и да не даде грешка. Затова има една крайна CRC32 стойност, която се смята от декомпресирания файл и се сравнява, така че шансът грешна парола да декомпресира файла до безсмислици без да даде грешка е в най-лошият случай 1 на 4 милиарда.

Тъй като обаче можеш да имаш компресиран един мнооооого голям файл, с цел при проверката за грешна парола да не отнеме декриптирането и декомпресирането на големия файл, авторите на формата са въвели и една стойност, наречена verifier, която е CRC16 сума от ключа или нещо от сорта. При това положение, само в 1/65535 от случаите, грешната парола ще доведе до декриптиране с грешен ключ, декомпресиране и в краен случай сравнение на крайната CRC32 сума.

Като последствие от това (и поради начина по който са написани почти всички архиватори) е много лесно да генерираш грешна парола, която минава проверката с verifier-а и програмата ти връща обикновено грешка че архивът е corrupt-нат, а той си е напълно здрав. Не че последното има някаква практическа употреба, но е забавно :)


Както и да е, къде в цялата схема виждаш "криптиран стринг", който да пазиш в таблица? Можеш да пазиш 16-битовия verifier примерно, но това по никакъв начин не е индикативно, че паролата е същата, освен че ти дава по-голяма вероятност за това. Освен което, въпреки че така се намалява големината на таблицата няколко пъти, това не я прави много по-практична - където са няколко хиляди петабайта, почти толкова недостижими са няколкостотин петабайта. Също така не съм много сигурен, че в RAR е реализирано по този начин, в ZIP е реализирано така и това дава известни предимства. Може да са са изхитрили и да са го направили зависимо от съдържанието, примерно вместо CRC16 от ключа, да вземат CRC16 от първите няколко блока, декриптирани с този ключ - последното обезсмисля цялото упражнение.