satask: Ещё раз - список благотворительный целей строго лимитирован законом. "Развитие сайта" к благотворительности не относится. Как частное лицо Вы вправе получать подарки и пожертвования, но если их общая сумма будет больше 4000 р. в год (кроме подарков от родственников) - обязаны в конце налогового года подать декларацию и выплатить НДФЛ 13% от суммы подарка. Предприятие может получать пожертвования, но они облагаются налогом на прибыль за исключением оговоренных в законе случаев.
Василий Пупкин: Это известные факты. Собственно поэтому сейчас и идёт переход на эллиптическое шифрование, там при меньшей длине ключа и большей скорости шифрования криптостойкость выше. Шифр Вернама - действительно самый надёжный, но требует обязательной неповторяемости и, соответственно, непригоден в большинстве случаев.
Ну а "не понимаю, что использую" - это вся идей нынешней цивилизации. Мало кто понимает до конца как работают те или иные устройства, но при этом вполне успешно их использует. Например если Вы купили автомобиль, то вряд ли Вы будете лично перепроверять всю его конструкцию. А вдруг из-за конструктивного дефекта у него при левом повороте с одновременным торможением откручивается колесо?
Василий Пупкин: Сотовая связь - как раз пример закрытых алгоритмов. Как только их отреверсили так сразу и обнаружилась их слабость. В результате использования специальных алгоритмов их вскрывают A5/2 вскрывается за секунды, A5/1 требует двухминутного разговора.
Открытый же RSA до сих пор не могут вскрыть за приемлемое время, при длине ключа в 1024 бита его взлом требует 1011 MIPS-лет. 224-битный ГОСТ требует порядка 1020 MIPS-лет. На современных суперкомпьютерах с производительностью 106 получим, соответственно, 105 и 1014 лет.
Василий Пупкин: Сами алгоритмы ничего не содержат. Именно их открытость позволяет любому желающему проверить криптографическую устойчивость. Конкретная реализация алгоритма может содержать бэкдор, но тогда никто не мешает встроить такой бэкдор и в мессенджер и отсылать уже расшифрованное сообщение. Опять же в Open Sorce продуктах и код программы открыт, проверяйте, ищите ошибки, уязвимости, бэкдоры.
Василий Пупкин: А представьте, что Вы захотели написать что-нибудь абоненту в Австралии, а ключ, как на грех, закончился. Сами поедете за файлом или респондента к себе пригласите?
А так, в общем случае, достаточно Диффи-Хеллмана + RSA. Да, уязвимо к MiTTM, но в большинстве случаев вполне достаточно. Для более строгих вещей есть ГОСТ (эллиптика) и предварительный обмен удостоверяющими сертификатами.
Василий Пупкин: Делать такое шифрования для переписки только двух людей смысла нету. А если Вы переписываетесь с парой десятков человек? 200 гиг тоже не жалко?
Юридических проблем никаких. Берите любой подходящий мессенджер, пишите свой плагин и шифруйте сколько угодно.
Можно отключить DKIM, отправить письмо из клиента, посмотреть содержимое полей, посмотреть это же письмо у получателя, сравнить поля и содержимое в исходном виде письма (Ctrl+U в Thunderbird, например).
Urukhayy: Надо сравнивать письмо до до подписания, после подписания, но до отправки и пришедшее на сервер получателя. За самим OpenDKIM'ом вроде глюков не замечал.
Deq56: Если эти две строки в одном канале, то и обычная переменная будет работать, а если в разных, то значение CHANNEL разное, и это две разные переменные.
Сергей Мурко: По уму, денормализация выполняется в последнюю очередь, уже по результатам анализа работы реальной базы. На этапе проектирования и разработки базы стараются сделать нормализованными.
Что касается строго последовательных id, то здесь проблема с транзакционностью. В MySQL по умолчанию каждый вызов оператора SQL - отдельная транзакция. Поскольку счётчик автоинкремента один на таблицу, то перед попыткой добавления строки значение счётчика увеличивается, а если строка не добавилась, то уменьшать это значение нельзя - другая транзакция могла, в свою очередь, также использовать этот счётчик, увеличив его значение. С точки зрения СУБД это выглядит примерно так:
транзакция 1 - начать
транзакция 1 - увеличить счётчик, получить новое значение (99)
транзакция 2 - начать
транзакция 2 - увеличить счётчик, получить новое значение (100)
транзакция 1 - захватить таблицу, попытка добавления строки
транзакция 1 - ошибка добавления строки, отпустить таблицу
транзакция 2 - захватить таблицу, попытка добавления строки
транзакция 1 - завершить
транзакция 2 - строка добавлена, отпустить таблицу
транзакция 2 - завершить
Нет упорядочивания строк сверху вниз (другими словами, порядок строк не несет в себе никакой информации).
Вообще, если есть возможность использовать естественный ключ, то лучше его и использовать. Автоинкрементный целочисленный id используют когда естественный ключ оказывается слишком длинным. Но и в этом лучше использовать id для связи таблиц и идентификации строки, но не для сортировки строк.
Сергей Мурко: Привязка к последовательности id - косяк в базе. При правильной структуре их можно генерировать хоть случайным образом, лишь бы они были уникальными. AUTO_INCREMENT - это всего-навсего самый простой способ обеспечить уникальность.
Для колонки id никто не мешает задать тип и BIGINT(20), ну и при правильной организации FOREIGN KEY никто не мешает перенумеровать все записи и сдвинуть счётчик инкремента.
