> Выше предлагали использовать для замеса HMAC (вместо сложения) — я бы этого делать не стал, просто потому что я не знаю ни одного человека, который смог бы посчитать вероятности и даже просто риски такого «тройного хэширования» оценить.
Кроме того конкатенация (хоть битовая, хоть байтовая) это дополнительный фактор, улучшающий алгоритм по бруту — ее (на брутах) очень не любят виртексы и иже с ними.
Вот из-за таких грамотеев, которые собственные спотолочные соображения («это дополнительный фактор») и неграмотность («потому что я не знаю ни одного человека, который смог бы посчитать вероятности») ставят выше официальных рекомендаций организаций вроде IETF — и возникают дырявые парольные системы, описанные в топике.
Господи, какой бред. И в лучших традициях «оригинальных исследователей», в списке литературы — одна ссылка на популярную книжку и 100500 ссылок на самого же аффтара.
Вопрос: начиная с какого количества объектов надо задумываться о кластеризации на сервере? В Вашем примере использовано 10 000 точек, отрисовка занимает секунду. Соответственно, 100 000 точек уже будут неюзабельными. Я правильно понимаю?
Вау! Это прекрасное решение. Удивительно, что в основной доке про это ни слова, и надо лезть в RFC.
Мне кажется (это уже к yTko), этот паттерн — освобождение ресурсов и памяти строго в finally — должен обязательно упоминаться в любой статье про генераторы. Потому что генераторы в foraech — обычное дело, а про то, что юзер в любой момент может сказать break, легко забыть.
У меня вопрос тем, кто уже хорошо разобрался в генераторах. Пусть у нас есть первый генератор из этой статьи — getLines, который выдаёт строки из файла. Мы вставили его в цикл foreach, и внутри цикла при каком-то условии делаем break. Ну, предположим, нам надо дочитать только до определённой строки, а что дальше в файле, нам не интересно.
Вопрос: я правильно понимаю, что файл после этого останется незакрытым (fclose никогда не вызовется)? Если да, то как с этим бороться?
Это сравнение скоростей кода asm.js (запущенного в Mobile Firefox Nightly), нативного кода и dalvik-кода под андроид. Смотрите сами, кто кого рвёт как тузик грелку.
Не оскорбляйте, пожалуйста, читателей такими ответами.
Естественно, имелось в виду шифрование на клиенте с хранением _зашифрованных_ файлов на серверах Я.Диска. С _невозможностью_ их расшифровать на стороне Яндекса. Конечно, только для личных файлов, не для расшаренных.
И, кстати, это был вопрос. Рассматривалась ли вообще такая возможность и почему решили не делать?
Скажите, а почему вообще в Я.Диск не заложено с самого начала шифрование всего и вся? Ради выигранных нескольких процентов места от дедупликации? Вы же выходите на рынок далеко не первыми, можно учесть ошибки и недостатки предшественников. Спрос на приватность данных сейчас очень велик, и она могла бы быть конкурентным преимуществом.
Кроме того конкатенация (хоть битовая, хоть байтовая) это дополнительный фактор, улучшающий алгоритм по бруту — ее (на брутах) очень не любят виртексы и иже с ними.
Вот из-за таких грамотеев, которые собственные спотолочные соображения («это дополнительный фактор») и неграмотность («потому что я не знаю ни одного человека, который смог бы посчитать вероятности») ставят выше официальных рекомендаций организаций вроде IETF — и возникают дырявые парольные системы, описанные в топике.
А проект — явный кандидат на краудфандинг. Объявите публичный сбор средств, уверен, что будет много желающих помочь — вкусно описывать вы умеете:)
Блиииннн… Люди, ну откройте для себя HMAC, наконец. Хватит склеивать.
Ваша статья не исключение:)
Вы не знаете, зачем нужен PBKDF2 и прочие «тяжёлые» хэши?
Хранить PBKDF2(md5(password))
Мне кажется (это уже к yTko), этот паттерн — освобождение ресурсов и памяти строго в finally — должен обязательно упоминаться в любой статье про генераторы. Потому что генераторы в foraech — обычное дело, а про то, что юзер в любой момент может сказать break, легко забыть.
Вопрос: я правильно понимаю, что файл после этого останется незакрытым (fclose никогда не вызовется)? Если да, то как с этим бороться?
Это сравнение скоростей кода asm.js (запущенного в Mobile Firefox Nightly), нативного кода и dalvik-кода под андроид. Смотрите сами, кто кого рвёт как тузик грелку.
Естественно, имелось в виду шифрование на клиенте с хранением _зашифрованных_ файлов на серверах Я.Диска. С _невозможностью_ их расшифровать на стороне Яндекса. Конечно, только для личных файлов, не для расшаренных.
И, кстати, это был вопрос. Рассматривалась ли вообще такая возможность и почему решили не делать?