Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Алгоритми та структури даних, технології → Криптографія → Шлях на криптографічну вершину
Сторінки Попередня 1 2 3 4 5 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
Механічно, пошуком збігів.
Фігня цей ваш хеш. По-перше, він обробляє весь рядок визначену кількість ітерацій, тобто малоефективний на довгих рядках (якщо мені треба хешувати гігабайт, то він буде цей гігабайт 32 рази пробігати, навіть якщо переписати його, щоб не в пам'яті це крутив).
А по-друге, ефективна довжина хешу значно менша. Дивіться:
result = 0xBA5E0FDA7AB17C01 //довжина хешу - 8 байт
data = str(data)
for i in range(itr):
for char in data:
#розбираємо по частинах
o = ord(char)|(ord(char)<<16)
'''якщо ord(char)<256, то o - 256 значень до 3 байт; якщо char 2-байтовий, то до 4 байт.
Наприклад, для ASCII максимальне значення char дає 0x7f007f, що містить 23 біти'''
r = int(str(result)[::-1])
'''тут найцікавіше. Якщо число не ділиться на 10, то обернене має таку саму довжину в 10-й системі
(не факт, що у двійковій вона зберігається, іноді може навіть зростати, але в середньому без змін).
Але якщо ділиться - то число зменшується в 10 разів, тобто на 3 біти, раз на 10 операцій,
а іноді в 100 і в 1000.'''
result = r^o
'''ефективна довжина результату після досить довгого рядка - приблизно максимальна довжина
символа+16 біт'''
result = (int(str(result*salt)[::-1])<<i)%int(length*'F',16)
'''Таким чином, ефективна довжина хешу довгого тексту з 2-байтовими сиволами - 4 байти, 32 біти.
Підбирається на сучасному компі за пару годин, і те тільки тому, що код дуже неоптимальний.'''
return resultОсь вам колізія на 32 ітераціях:
https://ideone.com/ffOJpc
Чи можна використовувати клітинні автомати в хеш алгоритмах? Якщо ні - чому?
По моєму, це еффективно при правильному правилі.
Чи можна використовувати клітинні автомати в хеш алгоритмах? Якщо ні - чому?
По моєму, це еффективно при правильному правилі.
клітинні автомати - шо то є, і з чим тово їдять?
Вже доведено, що клітинні автомати повні за Тюриногм, тому питання лише в якій якості їх застосовувати - збирати з них тюрингову машину і кодувати її чи якось інакше.
зловмисник не має id сесії щоб розміщувати повідомлення. Це виключено. немає потреби в цьому хешуванні.
При перехваті данних зловмисник відправить хеш. тому систему треба вдосконалити таймером запитів по певному алгоритму. Щоб кожен раз були різні хеші. достатньо хешувати id сесії нікнейм дату без передачі. по алгоритму форми і таймер запитів. тоді зловмисник ніколи не зможе підібрати хеш без алгоритму кодування. Хеш краше обрізаний md5 щоб не розкодували.
все-таки бот, баньте його!
А іноді навіть весело
for({int s=0;int i=0};{s=s+n[i];i++};i<N);сорян не хаває...не допрацьований цикл в компіляторі.
но принцип понятний.
https://en.wikipedia.org/wiki/Non-inter … edge_proof
поясніть будь-ласка реалізацію анонімності в Zcash,
з блок-схемами і прикладом коду
іншими словами -- як працює zk-SNARKs на практиці
про рівень 0 -- тунель з дверимо -- знаю, цікавить більш практична штука, non-interactive
пробував читати https://habrahabr.ru/post/342262/ ,
там я не догнав як юзаються senderFunction та receiverFunction --
і обидві функції приймають x та w,
на яких етапах вони виконуються (якщо у нас є два різних компи з Алісою та Бобом) ?
і що відбувається в функції transfer?
і як повинна виглядати функція zksnarkverify?
в вищій математиці поки гірше ніж хотілось би,
про прувери знаю лише назву,
сішки не знаю
поясніть на пальцях, якійсь невеличкій задачі, з кусочками коду на js?
ще одне запитання --
актуальна задача надійно зашифрувати файли з біткоін-та-інший-збиткоін - адресами та ключами,
запитання -- яка різниця між --
1) OpenPGP -- GnuPG + GPA (GnuPG GUI)
2) VeraCrypt
власне, цікаво які є переваги у варіанту №2 ?
"невидимий" контейнер, що його ніхто на диску і не побачить?
у мене Ubuntu з lxde, перший варіант потицяв -- наче працює
дякую
OpenPGP (GnuPG) шифрує файли та пошту асиметричним шифруванням, також робе ЕЦП по такому принципу.
VeraCrypt робе на носії інфи (ссд, хард) прихований розділ (який можна зробити і вручну), і шифрує його симетричним алгоритмом шифрування (AES, Serpent, Twofish), хоч він і генерує пару ключів.
Що краще - не знаю. Думаю, що PGP, бо він ні разу не був скомпроментований, як TrueCrypt.
OpenPGP (GnuPG) шифрує файли та пошту асиметричним шифруванням, також робе ЕЦП по такому принципу.
VeraCrypt робе на носії інфи (ссд, хард) прихований розділ (який можна зробити і вручну), і шифрує його симетричним алгоритмом шифрування (AES, Serpent, Twofish), хоч він і генерує пару ключів.
Що краще - не знаю. Думаю, що PGP, бо він ні разу не був скомпроментований, як TrueCrypt.
отже, файні штуки, дайте дві! 
-----------
по темі вище (доповнення) --
мене цікавлять наступні штуковини --
zk-SNARKs
Oroboros PoS
напів-тонкий клієнт до мереж Bitcoin, Dash, можливо ще яких
( 1 -- відправлення транзакції
2 -- опціонально викачати блоки, далі - їх перевірити )
готовий заплатити людині, котра пояснить і покаже як написати власну реалізацію
( не чисто побалакати про переклад документації, а сидимо і пишемо разом --
js, erlang, haskell )
сума по домовленості, терміни не горять, пишіть в пп
дякую 
хто шарить і має настрій - поясніть мені популярно і коротко про сіль та хеш. Бачу, що в одному коді спочатку генериться сіль, а потім вона використовується, аби згенерити хеш пароля.
Нащо ця сіль треба, і як вона генериться?
Генериться навмання. За великим рахунком, можна навіть без надійного ГВЧ, а штатним ГПВЧ.
Сіль захищає від наперед згенерованих таблиць хешів. Тобто, наприклад, зловмисник кілька місців генерує таблицю хешів випадкових паролів
Пароль Хеш
SecrEt! 5382463
password 012345
unlock 543210
P@nfFm4d 93756323534а потім о 12 ночі витягає хеші з атакованого серверу і шукає збіги. Очевидно, що багато людей використовує прості чи поширені паролі, і така атака має високі шанси на успіх - доки адмін вранці помітить, що хтось з незрозумілого IP зайшов на сервер і витягнув хеші, можна встигнути витягнути всі дані кількох людей.
Але якщо паролі зберігаються із сіллю, то ця атака не має сенсу: з бази будуть витягнуті хеші і сіль, але відновити паролі можна тільки пошуком по конкретній солі. Таблицю
Пароль Сіль Хеш
SecrEt! fns,dsdh 853567247834
password fh732dpkp 38264023423
unlock fhss5!rff 3475350053
P@nfFm4d fl;oksoh0 39470349364неможливо згенерувати завчасно, бо зловмиснику невідома сіль кожного паролю і доведеться генерувати всі можливі комбінації "пароль-сіль". Навіть якщо сіль буде передбачуваною, зловмиснику буде потрібно знати, хто коли реєструвався в системі, щоб заготовити таку таблицю.
а генерацію всіх можливих пар сіль+пароль можна ж розпаралелити?