Кэш и хэш в чем отличие

Хеш и кеш в чем раница?

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

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

Хэш-функция в повседневной жизни

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

Как же это работает? Хэш-функция берет определенную информацию, например, часть текста или пароль от вашего аккаунта, это может быть даже отдельный файл и преобразует эту информацию в строку определенной длины. Эта строка всегда будет иметь одинаковую длину вне зависимости от того, какого размера была входная информация. Существует достаточно много различных хеш- алгоритмов. Например, слово bitcoin, пропущенное через хэш алгоритм sha-256 будет выглядеть вот так.

Хэш-функции очень сильно отличаются от обычного шифрования.

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

Второе основное требование для хэш-функций — фиксированный размер получаемого хэша, вне зависимости от введенной информации. Сейчас перед вами таблица с несколькими исходными данными и хэшами.

Как видите исходная информация разной длины, однако хэш имеет одинаковую длину. В любом из случаев следующее требование к хэш-функции — уникальность получаемого кэша и практически полное отсутствие коллизии. Что это значит? Это значит, что два разных набора информации не могут выдать одинаковое значение хэша.

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

Компьютеры стали настолько мощные, что найти коллизию за приемлемое время не составит труда. Прямо сейчас в интернете можно найти генератор к коллизии для хэш-функции md5. Чуть позже мы объясним, как коллизии могут быть использованы злоумышленникам. Хэш-функция также должна быть быстрой и быстро хэшировать исходную информацию. Но, это так же является и уязвимостью для «брутфорса», так чем быстрее работает хэш-функция, тем больше она уязвима для полного перебора. Для хорошей криптографической хэш-функции также важно наличие лавинного эффекта. Что это значит? Это значит, что при изменении даже одного байта в исходной информации, полученный хеш поменяется кардинально.

Как же будет выглядеть идеальная криптографическая хэш-функция? Идеалом криптографической хэш-функции можно считать ту функцию, которой присущи следующие пять свойств:

1. Детерминированность — одинаковые входные данные всегда дают одинаковое значение хэша.
2. Высокая скорость вычисления хэш-функций из любого сообщения.
3. Однонаправленность — невозможно получить исходное сообщение, зная его хэш, за исключением попыток полного перебора.
4. Наличие лавинного эффекта – минимальное изменение в исходном сообщении приводит к кардинальному изменению хэша.
5. Невозможность найти одинаковое значение хэша для двух разных сообщений.

Давайте рассмотрим простой пример, как используются хэш-функции, когда вы

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

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

Тем не менее злоумышленник, получив хэши все-таки сможет узнать пароль некоторых пользователей. Для этого используется атака по «радужным» таблицам.

Злоумышленники используют заранее вычисленные хэши для простых и часто используемых паролей и сравнивают хэши в таблице с полученными хэшами из базы данных социальной сети. Но тут появляется одна такая проблема: если некоторые пользователи устанавливают одинаковый пароль, итоговый хэш паролей получается тоже одинаковый. Вы можете сказать, что маловероятно что кто-то будет использовать одинаковый пароль. Однако, вот таблицы самых популярных паролей за 2020 год которые используют пользователи в социальных сетях и других сервисах.

Чтобы не было проблем с одинаковым хешем, когда несколько пользователей используют одинаковый пароль, используется «соль».

Что такое «соль»? «Соль»- это строка данных которая пропускается через хэш-функции вместе с паролем.

Использование «соли» при хэшировании гарантирует то, что даже при одинаковых паролях значение хэша будет разное. Допустим, если Алиса и Боб используют одинаковый пароль qwerty. Хэш этих паролей будут кардинально отличаться из-за того, что была использована «соль».

В интернете есть огромное количество уже прочитанных заранее хэшей. Для самых популярных паролей, например, на сайте «crackstation» можно проверить, как это работает. Для начала давайте пропустим самый часто используемый пароль qwerty через хэш-функцию sha-256.

Получаем значение хэша. Это значение хэша вставляем на сайт «crackstation» и получаем результат qwerty. Это не значит, что хэш-функцию обратили и вычислили исходное значение. Это значит, что у этого сайта есть база данных с уже прочитанными хэшами для каждого простого и часто используемого пароля.

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

Так используются специально замедленные хэш-функции, на вычисление которых уходит больше времени, чем на вычисление стандартных функций. Это функции: decrypt, sckrypt или argon2. Их использование для хранения паролей полностью нейтрализует возможный «брутфорс» (Brute-force Attack). Такие функции используются для создания секретного ключа, который состоит из пароля пользователя, «соли», и дополнительного параметра cost. Параметр cost необходим для защиты от «радужных таблиц».

Параметр cost определяет количество циклов, через который будет пропущена исходная информация и это замедляет процесс хэширования. Таким образом, атака полного перебора становится невозможной, так как процесс хэширования сильно замедлен и за приемлемое время не получится перебрать достаточное количество паролей и всевозможных комбинаций «соли».

Со временем компьютеры станут мощнее и атаки полного перебора на этот алгоритм смогут быстрее достигать своей цели. Для защиты от этого необходимо просто увеличить параметр cost, который определяет количество циклов.

Чем больше циклов, тем больше времени потребуется для хеширования исходной информации.

Давайте рассмотрим метод защиты данных, который используют сервис dropbox. Изначально dropbox берёт пароль пользователя и пропускают его через определенную простую хэш-функцию без использования «соли». И затем полученный хэш пропускается через функцию BCrypt с использованием «соли» и параметр cost величиной в 10 циклов. Это защищает от брутфорса (Brute-force Attack). Так в конечном итоге вся эта информация шифруется алгоритмом шифрования aes. Злоумышленнику придется вскрывать все эти слои защиты, чтобы добраться до нужной ему информации.

Однако, стоит отметить что слабые пароли все равно уязвимы. Длинный и надежный

Пароль, пропущенный через простую хэш-функция md5 будет сложнее подобрать

чем пароль из 6 символов, но пропущенный через функцию BCrypt с параметром cost в 25 циклов.

Хранение и защита паролей не единственная сфера где применяются хэш-функции. Они также применяются для проверки целостности файлов, как было сказано ранее. При малейшем изменении исходного файла его хэш-сумма кардинально изменяется. Как это может быть использовано? Самый простой пример: проверка программного обеспечения, скаченного с сайта разработчика. Большинство разработчиков программного обеспечения рядом со ссылкой на скачивание программы размещают хэш-сумму каждого из файлов. После загрузки ПО на свой компьютер, пользователь может сравнить хэши и убедиться в том, что файлы подлинные и не подвергались изменению. Это может быть также использовано для передачи файлов между двумя людьми, когда необходимо убедиться в том, что в процессе передачи файлов он не был изменен. Но здесь при использовании надежных или устаревших хэш-функций имеет место быть коллизионная атака, когда два разных документа имеют одинаковый хеш.

Как происходит коллизионная атака. Приведём пример. Ева создает два разных документа «а» и «б» имеющих одинаковое значение хэш суммы. Предположим, что Ева хочет обмануть Боба, выдав свой документ за документ Алисы. Ева отсылает документ Алисе, которая доверяет содержанию данного документа, подписывает его хэш и отсылает подпись Еве. Ева прикрепляет подпись документа «а» к документу «б» затем отправляет подпись и документ Бобу утверждая, что Алиса подписала этот документ. Поскольку электронная подпись сверяет лишь значение хэша документа «б», Боб не узнает о подмене.

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

Хэш-функции также используются и в блокчейне, каждая транзакция в блокчейне биткоина содержит информацию о получателе и отправителе. О сумме транзакций, времени её отправки и так далее. Вся эта информация хэшируется и образуется «транзакшин ID». «Транзакшин ID» это хэш-сумма, которая используется для ее идентификации и проверки того, что эта транзакция произошла. Хэши также используются и в блоках в блокчейне. Каждый блок блокчейна, биткоина, содержит свой хэш и хэш предыдущего блока, что образует связанную цепочку.

Пример применения хэширования паролей в Python с помощью модуля BCrypt.

Модуль bcrypt в PyPi предлагает удобную реализацию BCrypt, которую мы можем установить через pip:

После того, как установили BCrypt с помощью pip, вы можете импортировать его в свой проект:

Возьмем «Passwordnew» в качестве примера пароля, чтобы показать его в использование BCrypt:

Хешируем зашифрованный пароль с помощью BCrypt:

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

Таким образом, для наглядности был проиллюстрирован процесс хеширования пароля на примере BCrypt.

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

Кэш, хэш и няш-меш

UPD0 (2016-07-19 23-31): судя по всему, первая половина моей статьи — успешно изобретённый велосипед. Спасибо хабравчанам за ссылку на спецификацию
Статья ценна не более, чем вольное описание уже придуманной технологии.

Предыстория

Июльский субботний вечер подходил к концу. Нарубив дров на шашлык, я повесил USB-модем на багету, скомандовал sudo wvdial , развернул браузер и обновил вкладку с открытым гитхабом. Вернее, попытался обновить. Скорость не радовала, и в итоге страница-то обновилась, но явно не хватало какого-то из стилевых файлов; и дело было не в блокировке, поскольку аналогичные проблемы я наблюдал и с другими сайтами, и зачастую они решались просто многократным обновлением страницы. Во всём был виноват перегруз 3G-сети.

Стоп! А как же кэш?

Недолгое гугление привело на официальный гугловский мануал. Целиком пересказывать его не буду; скорее всего, дело было в том, что браузер прилежно ждал, когда сервер передаст ETags, а ответ сервера затерялся в переполненных триджунглях.

Через пару дней, возвращаясь душным днём из кафе, я придумал рацпредложение, которое решает эту (и несколько других проблем), которое и излагаю в данной статье.

Суть предложения

Добавить ко всем тэгам для подключения подчинённой статики (стилей, скриптов, изображений) атрибут checksum , который бы хранил хэш (например, SHA-1, как в git) требуемого файла:

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

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

Какие проблемы это решает?

Пресловутая угадайка: актуален ли файл в кэше?

• Больше не нужно отправлять запрос и сличать полученные ETags.
• Даже если файл в кэше вроде как устарел, но хэш совпадает — его можно смело использовать.
• Чистка кэша как средство решения проблем частично теряет актуальность.

Дилемма: jQuery со своего домена или с CDN?

Владельцам малых сайтов часто приходится выбирать: либо подключать jQuery и/или подобные ей библиотеки с CDN (гугловского, например), или со своего домена.
В первом случае уменьшается время загрузки сайта (в том числе первичной, т.е. при первом заходе посетителя на сайт) за счёт того, что файл с серверов Гугла с большой долей вероятности уже есть в кэше браузера. Но, например, разработчики WordPress придерживаются второго варианта, ставя во главу угла автономность. И в условиях, когда CDN падают, блокируются и т.д., их можно понять.
Теперь от такой проблемы можно будет избавиться навсегда: не всё ли равно, откуда получен файл, если его содержимое — это ровно то, что нужно html-странице, и она это удостоверяет? Можно смело указывать свой домен, и если библиотека есть в кэше (неважно, загруженная с этого сайта, другого «малого» сайта или из какого-нибудь CDN) — она подхватится.

Смешанный HTTPS/HTTP-контент

Одна из причин запрета загрузки HTTP-ресурсов на HTTPS-страницах — возможность подмены HTTP-контента. Теперь это больше не преграда: браузер может получить требуемый контент и сверить его хэш с хэшем, переданным по HTTP. Отмена запрета на смешанный контент (при наличии и совпадении хэша) позволит ускорить распространение HTTPS.

Косвенное определение истории по времени загрузки статики

Известно, что владелец некоторого сайта evilsite.org может (с некоторой долей вероятности) определить, был ли посетитель на другом сайте goodsite.org , запросив, например, изображение goodsite.org/favicon.ico . Если время загрузки иконки ничтожно мало — то она в кэше, следовательно, посетитель был на сайте goodsite.org . Теперь эта атака усложнится: околонулевое время отклика будет лишь обозначать, что посетитель был на сайте с таким же фавиконом. Это, конечно, не решает проблему целиком, но всё же несколько усложняет жизнь определяющему.

На что это не влияет?

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

Идеология

Как обычно (математик я, что уж тут поделать) сформулируем аксиомы, которые вкладываются в предложение:

1. Все передаваемые файлы делятся на главные (в основном html-страницы) и подчинённые (скрипты, изображения, стили и т.д.).
   В идеологии, заложенной в стандарты HTTP-кэширования, все файлы равноправны. Это, конечно, толерантно, но не отвечает современным реалиям.
2. Неважно, откуда получен подчинённый файл. Важно, что его содержимое удовлетворяет нужды главного.
   В существующей идеологии даже сама аббревиатура URI — Uniform Resource Identifier — предполагает, что идентификатором ресурса является его адрес в сети. Но, увы, для подчинённых файлов это несколько не соответствует действительности.

Перспективы

Обещанный няш-меш

Зная хэш требуемого вспомогательно файла, можно почти смело запрашивать его у кого угодно; основная опасность: если опрашиваемый узел действительно имеет требуемый файл, то он знает его содержимое и, скорее всего, как минимум один URI-адрес, по которому требуемый файл может (или мог) быть получен. Имеем два варианта использования предлагаемой технологии с учётом этой угрозы с целью плавного подхода к няш-меш сети:

Доверенные устройства

Например, в офисе работают программисты, ЭВМ которых объединены в локальную сеть. Программист Вася приходит рано утром, открывает гитхаб и получает в кэш стили от нового дизайна, который выкатили ночью (у нас — ночь, там — день). Когда в офис приходит программист Петя и тоже загружает html-код гитхабовской странички, его ЭВМ спрашивает у всех ЭВМ в сети: «А нет ли у вас файла с таким-то хэшем?» «Лови!» — отвечает Васина ЭВМ, экономя тем самым трафик.
Потом наступает перерыв, Вася и Петя лезут смотреть котиков и пересылают фотографии друг другу. Но каждый котик скачивается через канал офиса только один раз.

Анонимный разделяемый кэш

Аня едет в трамвае с работы и читает новости… например, на Яндекс-Новостях. Встретив очередной тэг <img> , Анин телефон со случайного MAC-адреса спрашивает всех, кого видит: «Ребят, а ни у кого нет файла с таким-то хэшем?». Если ответ получен в разумное время — профит, Аня сэкономила недешёвый мобильный трафик. Важно почаще менять MAC-адрес на случайный да не «орать», когда в поле видимости слишком мало узлов и спрашивающего можно идентифицировать визуально.
Разумность времени ответа определяется исходя из стоимости трафика.

Дальнейший переход к няш-мешу

Фотография в соцсети может быть представлена как блоб, содержаший хэш и адрес собственно изображения (возможно, в нескольких различных размерах), а также список комментариев и лайков. Этот блоб тоже можно рассматривать как вспомогательный файл, кэшировать и передавать друг другу.
Более того, альбом фотографий тоже легко превращается в блоб: список хэшей изображений + список хэшей блобов-фотографий (первое нужно, чтобы при добавлении лайка/комментария показывать фотографии сразу, а метаинформацию — по мере её получения).
Останется только реализовать электронную подпись и поля вида «замещает блоб такой-то» — и готова няш-меш-социалочка.

Компактизация хэша

В идеале при записи хэша следует использовать не шестнадцатеричную систему счисления, а систему с бОльшим основанием (раз уж мы взялись экономить трафик). Ещё одна идея — атрибут magnet , содержащий magnet-ссылку. Дёшево, сердито, стандартизировано и позволяет указывать также несколько классических адресов источников, что бывает немаловажно в случае ковровых блокировок и в случаях, когда браузеру известно, что трафик к различным серверам тарифицируется по-разному.

Поведение при несовпадении

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

Файлы-альтернативы

В некоторых случаях можно использовать любой из нескольких файлов с разными хэшами. Например, на сайте используется минифицированная jQuery, но если в кэше браузера есть неминифицированная — что мешает использовать её?

Превентивное кэширование

Многие устройства работают в двух режимах: когда интернет условно-безлимитен (например, мобильный телефон в вай-фай сети) и когда интернет ограничен (лимит по трафику или узкий канал). Браузер или расширение к нему может, пользуясь безлимитным подключением, заранее скачивать популярные библиотеки (наподобие jQuery и плагинов к ней), также по мере необходимости их обновлять. Это ли не мечта многих, чтобы jQuery была включена в браузер?

Заключение

Выдвигаемое рацпредложение актуально, так как борьба за оптимизацию загрузки сайтов идёт полным ходом. Более всего выиграют малые и средние сайты за счёт разделяемых библиотек (и, может быть, некоторых часто используемых изображений) в кэше. Уменьшится потребление трафика мобильными устройствами, что важно с учётом ограниченной пропускной способности каналов сотового интернета. Крупные сайты также могут уменьшить нагрузку на свои серверы в случае, если будут внедрены mesh-технологии.
Таким образом, поддержка предлагаемой технологии выгодна и вебмастерам, чьи сайты будут грузиться быстрее, и производителям браузеров, которые тоже будут быстрее отображать страницы, и провайдерам, у которых уменьшится потребление полосы (пусть и не столь значительно, но от провайдеров активных действий и не требуется).

Как правильно: кэширование или хэширование?

Прошло время с тех пор как кофе стало трансвеститом, а йогурт — ударенным не в то место.

Г-да возмущавшиеся, как изменилась Ваша жизнь с тех времён?

Изменился ли вкус кофе? Можете ли Вы без тошноты пить напиток другого рода? Не получаете ли Вы внутренние травмы из-за неправильного ударения йогрутов?

Налетела ли Земля на небесную ось?

Вообще, сбылись ли ваши апокалиптические прогнозы?

• Просмотр профиля
• Личное сообщение

Чеееееее? А по-русски?

• Просмотр профиля
• Личное сообщение

Некоторое время назад антинародная власть провела реформу языка встретившую сопротивление всех кулюторных людей.

Вот я и хочу услышать от этих людей что же в итоге изменилось в результате тех реформ.

Ну вот типа до часа ИКС они пили "чёрный кофе", а на следующее утро проснулись, смотрят на ту же банку и понять не могут это "чёрный кофе" или "чёрное кофе"? И эта неоднозначность не позволяет им употреблять тот же самый напиток что они пили до этого?

Или вот сказали что договор надо говорить как договор, а не договор как раньше. И БАЦ у них сразу убытки пошли из-за этого.

• Просмотр профиля
• Личное сообщение

Теперь более-менее понятно.

Muxa написал :
смотрят на ту же банку и понять не могут это "чёрный кофе" или "чёрное кофе"

А на банке написано INSTANT COFFEE, так что пофигу.

Muxa написал :
сказали что договор надо говорить как договор, а не договор как раньше

Всегда только договОр. Те, кто говорит дОговор, шОфер и лОжить — неграмотная серость.
И ничего не изменилось.

• Просмотр профиля
• Личное сообщение

Юбер написал :
А на банке написано INSTANT COFFEE, так что пофигу

а что банке? не бывает растворимого кофе, под маркой кофе — кофеин + добавки + ароматизаторы с запахом кофе, отсюда. болезньпечени, панкреатит пр.
а мне нравится слово кранЫЫЫ

• Просмотр профиля
• Личное сообщение

Muxa написал :
Некоторое время назад антинародная власть провела реформу языка встретившую сопротивление всех кулюторных людей.

Нам, культурным людЯм, пофиг, как пишут и как говорят, лишь бы понятно было!

Юбер написал :
Всегда только договОр. Те, кто говорит дОговор, шОфер и лОжить — неграмотная серость.

Про шОфер соглашусь, мне вообще это слово не нравится, с любым ударением.

• Просмотр профиля
• Личное сообщение

Muxa написал :
антинародная власть провела реформу

• Просмотр профиля
• Личное сообщение

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

кэширование и хэширование — совершенно различные функции.

я не возмущался, если что. это нормальный процесс — оскотинивание приматов в условиях избыточности ресурсов.

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

в общем, примерно такое не оригинальное направление мысли..

• Просмотр профиля
• Личное сообщение

werefish написал :
кэширование и хэширование — совершенно различные функции.

А Иран или Ирак?
А котята или кутята?
А индейцы или индийцы?

• Просмотр профиля
• Личное сообщение

Muxa написал :
А индейцы или индийцы?

• Просмотр профиля
• Личное сообщение

А эксплуатация или эксплоатация?

• Просмотр профиля
• Личное сообщение

Muxa написал :
А эксплуатация или эксплоатация?

жлобство!
у франса в "острове пингвинов" что-то было по поводу трансформации лытыни в католичестве, синхронно с упадком нравов.
нашел,

Многочисленные воры, желая причаститься, но опасаясь, что их заставят для прощения грехов отдать похищенное в церковь, предпочтут исповедоваться у бродячих священников, которые, не зная ни итальянского, ни латинского языка и говоря только на своем деревенском наречии, будут ходить по городам и весям, отпуская грехи за ничтожную плату, а то и просто за бутылку вина. По всей вероятности, подобные отпущения не будут иметь к нам никакого касательства, как полученные без раскаяния и по этой причине недействительные; но крещения, весьма возможно, еще доставят нам немало забот. Священники станут до такой степени невежественны, что начнут крестить младенцев «во имя отцов, сынов и святых духов» ,

…«во имя отцов, сынов и святых духов»… – Искажение латинской богослужебной формулы: «Во имя отца и сына и святого духа», образец невежества средневекового духовенства.