sha1 или sha256

https://stackoverflow.com/questions/1867191/probability-of-sha1-collisions

Я все эти цифры видел. но я кроме умножения в столбик, математику не знаю. Мне нужно не на уровне цифр, а на уровне ощущений. :)

если не нравится слишком длинный sha256 — то лучше сделай так:

использай sha256, но результат этой функции обрезай: бери первые N байт от результата.

такой подход — лучше чем небезопасная sha1

такая мысля тоже была... но...

это будет устойчивее, чем sha1? учитывая, что брать-то я буду уже base64_энкодированную строку.

sha256 имеет более большое внутрее состояние (при расчёте) чем sha1.. поетому думаю — ответ «да».

а если размер N вообще взять одинаковый для sha256 и sha1 — то однозначно — ответ «да»

спасибо!

лишь бы карма не подвела

математику не знаю. Мне нужно не на уровне цифр, а на уровне ощущений.

Это многое объясняет.

кстате — на мой взгляд — в очень многих случаях не стоит использовать «голую» функцию sha1\sha256 .

лучше делать расчёт через hmac (тем более hmac есть в модулях Python).

ну и также брать от результата hmac — первые N байт.

кстате команда OpenBSD полюбила какую-то свою функцию вместо hmac, (кажется poly1305?) но её нет в стандартных «батарейках» Python.

Прилепи туда дату, с точностью до миллисекунды: date +%Y%m%d%H%M%N. Вероятность коллизии сообщений отправленных одновременно ниже потому что одновременно отправленных сообщений меньше чем всего сообщений.

sha512

у меня там много разных полей, в том числе дата

100*10^9 100000000000

2^256 115792089237316195423570985008687907853269984665640564039457584007913129639936

слишком смешные шансы ведь. Просто человек с трудом представляет большие числа. Да, даже для 2^128 шансы слишком иллюзорные. А 2^64 да, действительно, выглядит маловатым.

Например простые числа, которые юзаются для rsa, считаются составными с вероятностью меньшей чем 2^-80 (в openssl так) https://github.com/openssl/openssl/blob/master/crypto/bn/bn.h#L366

кстате — на мой взгляд — в очень многих случаях не стоит использовать «голую» функцию sha1\sha256 .

лучше делать расчёт через hmac (тем более hmac есть в модулях Python).

почему? и где там сказано, что hmac использует sha256 (исходники пока не смотрел)?

return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-',").replace('_',")[:20]

мощно я задвинул? внушает? :)

EfatjsUqKYSrqv18O1FlA3hcIHI=

fat

я чёт не понял.

ты разговариваешь с хэш-суммой? о, времена, о нравы.

по какой причине символы '_','-' заслуживают удаления?

они мне не нравятся. :)

и, когда лежит куча файлов, и первый - -*, и хочешь сделать какое-нибудь действие с *, то очень интересный эффект получается. :) с ЧТОНИБУДЬ ./* - не получается :)

почему?

чтобы тот кто пытается найти коллизию — не использовал бы готовую нагенерированную базу данных.

и где там сказано, что hmac использует sha256

hmac может использовать любую hash-функцию..

нy или быть может лучше сказать: hmac может улучшить любую hash-функцию.

по умолчанию используется MD5 (что вообще весьма спорно с точки зрения безопасности).

пример использования SHA256 (вместо MD5):

import hashlib
import hmac

key = b'this_is_key'
msg = b'x'
N = 10

print(hmac.new(key, msg=msg, digestmod=hashlib.sha256).digest()[:N])

return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-',").replace('_',")[:20]

насчёт: replace('-',").replace('_',"): интересная идея.. но еcли тебе не нравятся - и _ --- то лучше наверно использовать Base58 а не Base64 :-)

чтобы тот кто пытается найти коллизию — не использовал бы готовую нагенерированную базу данных.

ээээ... если кто-то специально найдёт коллизию - то ничего страшного особо не произойдёт, будет сам виноват :) главное, чтобы валидное сообщение прошло

тем более, сейчас это json-файл, там разные скобочки, закорючечки, ему нужно оставаться валидным

короче - допишу документацию и тогда выложу весь фидотвитер, чтобы было понятнее. в общем, пока остановился на подобной функции, а там - как кривая вывезет.

спасибо за подсказки

насчёт: replace('-',").replace('_',"): интересная идея.. но еcли тебе не нравятся - и _ --- то лучше наверно использовать Base58 а не Base64 :-)

мне желательно, чтобы реализации фиды и фич для неё были и на баше, и на брейнфаке :) на стандартных инструментах.

пока меня только zlib смущает - вроде бы gzip без заголовка данные не распаковывает?

вроде бы gzip без заголовка данные не распаковывает?

что-то забыл:).. но там же малюсенький заголовок..

а зачем работать с ними вручную?

а зачем работать с ними вручную?

чтобы посмотреть с помощью gzip *, сколько места экономится gzip-ом, и есть ли смысл хранить эти файлы в сжатом виде.

там просто текст или что?

есть же более эффективные сжатия, чем gzip

не получается :)

пожалуй это будет уместно, если я приведу здесь показательный пример:

cp -vf --target-directory="$target_dir" -- "$file_path"

эта команда копирует файл «$file_path» внутрь каталога «$target_dir».

и вот похожая команда (но НЕ эквивалентная):

cp -vf -t "$target_dir" "$file_path"

разница между этими двумя командами в том что последний вариант работает с определённой вероятностью, в зависимости от того начинаются ли переменные на символ "-" :-)

то есть почти все команды имеют внутри своего синтаксиса-командной-строки такую сущность как двойной минус. (см двойной минус перед «$file_path»)

если в python-программах использовать модуль [argparse], то python-программы тоже будут корректно распознавать двойной минус.

не придётся ли мне рвать на себе волосы и проклинать свою тягу к изящному, из-за которой я 7 марта 2014 года заменил sha256 на sha1?

У тебя одномерное пространство ключей? Соболезную.

мне нужна максимальная портируемость. конкретные бекенды на конкретных стадиях могут быть какими угодно. :)

Если каждый атом в наблюдаемой части Вселенной напишет по сообщению, то всего получится не меньше 2^266 уникальных сообщений. И sha-160, и sha-256 дадут многочисленные коллизии. Ндо сразу брать длину хэша не меньше 300 бит, чтобы исключить даже теоретические шансы.

что есть портируемость? архиватор - это же просто алгоритмы, никаких ОС специфичных вызовов поидее в них нету, портируемость максимальная.

речь о том, что есть например архиваторы, с приличной степенью сжатия и попутно с высокой скоростью расжатия. Если сжатие разовое, то можно пренебречь затратами на него; а расжатие частое, то есть смысл использовать их.

в общем, вот:

вживую (без авторизаций, можно пушить и прочее) - http://ii.51t.ru/

код

https://bitbucket.org/51t/ii

в комплекте тоссеры и прочее. для работы web_fetch.py нужно создать каталоги echo и msg там, где он запускается (если он не из корня запускается)

постилка из текстовых файлов - там тоже, вроде понятно.

всякие сервисы по обмену тоже должны быть понятны по исходнику: типа вот: http://ii.51t.ru/m/lL3P4OOcxzB8852u07AF

или вот http://ii.51t.ru/z/m/lL3P4OOcxzB8852u07AF

/z/get - получить весь бандл (и сообщения, и идентификаторы всем флаконом, есть опции, веб-фетч получает идентификаторы и сообщения раздельно)

/z/in - кормить бандлами, в работе будет только для доверяемых нодов, чтобы впихивали сообщения

/z/push - пушилка для пойнтов, jpush.py работает через неё

ну и остальное по мелочи

в общем, жду советов и предложений, пока буду это оформлять :)

import lzma появился только в python 3.3

то есть, уже обойтись стандартной библиотекой python не получится.

poly1305 - это ж улучшенные эллиптические кривые от djb. Они быстрые, но достаточно устойчивые(?) к взлому.

лучше делать расчёт через hmac

ну и также брать от результата hmac — первые N байт.

omg. Диванный криптограф на марше.

длинные номера и урлы меня пугают

Обратись к психологу.

в общем, жду советов и предложений, пока буду это оформлять :)

вряд ли я смогу что-то особо дельное написать..

кроме как по поводу [api/__init__.py]:

def new_msg(obj,rh=None):
    s = jout(obj).encode('utf-8')
    h = rh or hsh(s)
    open('msg/%s' % h,'wb').write(s)
    return h

что будет когда закончатся файлы внутри каталога? ведь каталог может файлов хранить не бесконечно? или бесконечно?.. зависит от файловой системы.. но лично мне было бы страшно если файлов может стать больше чем 2^16 :-)

если бы вместо файла «msg/QkgqgPamrldQCffyVhT0» использовался бы файл «msg/Q/Qk/Qkg/QkgqgPamrldQCffyVhT0», то наверное это отчасти решило бы проблему..

но так как используется модификация-Base64 (без "-" и «_») а не Base58 — то значит код-сообщения может иметь переменную длинну, а не постоянную — это могло-бы создать дополнительную трудность, наверное..

а что если вместо

def hsh(s):
    return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-','').replace('_','')[:20]

написать

def hsh(s):
    return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-','A').replace('_','A')[:20]

в этом случае модификация-Base64 всегда будет выдавать одну и туже длинну :) .. и это позволило бы проще разбивать этот файл на под-каталоги:
«msg/QkgqgPamrldQCffyVhT0» => «msg/Q/Qk/Qkg/QkgqgPamrldQCffyVhT0»

Short SHA.

Что-то я не понял. В base64 кодировке нет и не было никаких - и _ .
Там только A-Z, a-z, 0-9, /, +
Можно ещё base32 / base58 посмотреть. Либо тупо sha256 хэш юзать, в нём буквы до F включительно - вполне тру.

http://en.wikipedia.org/wiki/Base64#URL_applications

omg. Диванный криптограф на марше.

сначало прочитал по ошибке как «дивный», и даже слегка удивился :) .. но потом всё-таки перепрочитал и понял :)

(я тоже ненастоящий сварщик)

Да, спасибо, я про zfill думал, а как-то про подобное не догадался, исправлено.

Что касается хранилилища:

у меня до сих пор основная цель - это африканские дети с компьютерами 1-2 гб hdd, с openbsd или haiku, где дорог каждый килобайт и каждый inode.

Поэтому для клиентов планируется просто сделать один большой файл, в который просто дописывать сжатое содержимое сообщения. И отдельно - индекс, где указаны начальное и конечное смещение в файле.

А для больших и крупных клиентов - всякие разные крутейшие распределённые базы данных. А сейчас мне хочется как можно более простую реализацию сделать.

вот, вундерклиент, аж самому страшно

https://bitbucket.org/51t/ii-txt

использует текстовые файлы и каталоги.

посмотри (сначала получи хэш-строку на http://ii.51t.ru чтобы стать полноценным пойнтом, и запиши её в первую строку config.cfg).... и попробуй пройти этот квест до конца, не только что-нибудь скачать (get.sh), но и что-нибудь написать :)

fatjs