Копипастить в статью текст из Википедии без указания источника есть не очень хорошо. Называть вашу программу безопасной — некорректно. Ставить на все это пометку tutorial — безответственно. Подумайте о тех людях, которые разбираются в предмете ещё меньше вас. Вы большой молодец в том, что пытаетесь разобраться в предмете, но гораздо лучше было бы описать собственный опыт и причины по которым вы принимали те или иные решения, чем весьма скромный результат. И напоследок, алгоритм разработки приложения вы точно не разрабатывали, разрабатывали вы собственно само приложение. Учитесь формулировать свои мысли так, чтобы они были понятны не только вам. Печатное слово требует очень строгого к себе отношения. И удачи вам с новыми статьями.
Вы очень удивитесь когда узнаете, что «топовый», как вы выразились, рубанок стоит дороже многих рейсмусов. Погуглите цены на Veritas и Lie Nielsen. Это если говорить про топ.
А если говорить про бюджет, то тут есть проблема, что рубанки после покупки надо доводить. Например, править подошву. Это сложно.
Кроме того, рубанки надо ещё уметь точить и это тоже не самое простое занятие.
Ну и до кучи, работать фуганком и рейсмусом тупо на порядок проще в плане навыков, которые для этого нужны.
Криптографию Вы поправите легко и просто. Советую PBKDF2+SHA256 c большим числом итераций для key derivation function (KDF), еще можно bcrypt / scrypt. Последние две — более стойкие против атак на GPU, но на практике, любая из этих KDF достаточно хороша. AES советую использовать либо в режиме ECB если надо попроще, либо в режиме CTR или CGM, если надо побыстрее (в counter режимах можно шифровать блоки параллельно). IV — криптографически безопасное случайное число (самый простой источник в питоне — random.SystemRandom().getrandbits), передавайте вместе с шифротекстом. Обратите внимание, в counter режимах нельзя использовать одну и ту же пару ключ-вектор инициализации для двух разных сообщений. Всей вашей безопасности придет кирдык. В GCM кроме всего прочего встроен собственный MAC. Его можно использовать для проверки правильно ли расшифровалось.
Что касается стеганографии, просто «поправить» тут мне кажется не выйдет.
Не поленился и посмотрел исходник. С точки зрения и криптографии, и стеганографии то, что Вы сделали — это дно. Простите, ничего личного. Теперь что именно делает Ваше решение дном:
Генерация AES ключа тупым дополнением его до нужной длинны нулями. Ключ Вы используете из командной строки, на практике это значит буквы+цифры+спецсимволы, то есть такой типичный пароль. Энтропия 26-30 бит приблизительно (ожидаемая, можно конечно упороться и ввести все битики, но я говорю об обычных людях, словарных паролях и прочих вещах из мира реальных пользователей). Кроме того, Вы любезно положили MD5 хэш от ключа в передаваемые данные, что сильно упрощает перебор (не надо много расшифровывать, достаточно сравнить хэши). То, что Вы сделали перебирается существенно более быстро, чем позволяет используемое шифрование. Читайте про key derivation functions;
Повторюсь про MD5 хэш. Никогда не давайте атакующему путь быстро проверить правильность ключа. Всегда надо строить шифрование так, чтобы надо было выполнить как можно больше действий и только потом узнать все ли правильно получилось. В вашем случае, надо было посчитать хэш от plaintext, добавить этот хэш к plaintext и потом все зашифровать. На проверке — расшифровываем и смотрим совпадают ли хэши. MD5 в качестве хэша тут внезапно ок, поскольку коллизии нас тут не интересуют. HMAC, который советовали выше тут вообще ни при чем;
AES ECB использовать нельзя. Проблема с ним заключается в том, что его выход сохраняет все статистические свойства входа. Кстати, поэтому он у вас немного сжимается; CBC, CTR или GCM на выходе дают практически белый шум;
Никогда не стройте безопасность на том, что атакующий не знает алгоритм. Это одна из основных аксиом криптографии;
Что касается «не трудно понять, что это шифр», то вообще говоря, стеганография — это о том, чтобы скрыть сам факт передачи сообщения. Если по картинке не трудно понять, то, извините, стеганографии не получилось.
Полегче, это всего лишь гипотеза. И никаких экспериментальных подтверждений этой гипотезы до сих пор нет. Более того, если даже пространство и дискретно, то его зерно как минимум на 13 порядков меньше планковской длины.
Тогда поздравляю и, одновременно… сочувствую. Поздравляю с тем, что особых проблем с комнатой вы не нашли, а сочувствую потому, что те проблемы, которые вы нашли решаются довольно сложно из-за того, что частоты довольно низкие…
А как и чем вы померяли, если не секрет? И какой у вас размер комнаты(длина, ширина, высота)?
Тру-сабвуфер должен стоять в тру-комнате в первую очередь, как и любая другая тру-аккустика. И это влияет на восприятие звука существенно больше, чем шипы, крутость колонок, крутость усилителя и прочие радости. Хорошие студийные мониторы плюс типичная комната в квартире и у вас будет ТАКАЯ неравномерность АЧХ начиная с баса и до нижней середины(300Гц), что по сравнению с этим, неравномерность АЧХ усилителей и колонок будет просто шумом. Если конкретнее, то из-за резонансов между стенами, потолком и полом неравномерность АЧХ может легко составить что-нибудь порядка 30дБ… o_O
А еще и время реверберации на разных частотах будет разным. Так что, сколько не делай лучшие в мире колонки с сабвуферами, все равно, в типичной квартире звучать они будут как говно…
Вот видео, которое очень хорошо и наглядно объясняет насколько сильную роль играет звуковая отделка помещения, слушать надо в наушниках, чтобы исключить влияние своей комнаты(те, кому лень смотреть все видео могут промотать до середины, там как раз начинаются сравнения помещений до и после отделки):
Видимо, Вы таки не знаете о чем речь и ничего не поняли. Дело в том, что ни Элис, ни Боб не вычисляют никаких дискретных логарифмов, а вовсе даже возводят производящий элемент некоторого кольца вычетов в некоторую степень. А вот Ив, не обладая информацией о том, в какую именно степень осуществляли возведение Боб и Элис, как раз и вынуждена посчитать логарифм. В этом, собственно, и «фишка».
Строго говоря, YubiKey генерирует не просто OTP, а комбинацию из некоторого константного ID, прошитого в ключ, плюс counter-based OTP. Наличие ID позволяет использовать YubiKey в качестве самостоятельного(самодостаточного) фактора аутентификации. А вообще, в настоящее время, YubiKey поддерживает еще и Challenge-Response и цифровую подпись.
Если кому нравится идея иметь устройство запоминающее и вводящее пароль, то есть очень похожая железка — YubiKey, которая в одном из своих режимов работы умеет делать это. Правда, она совершенно точно не умеет менять пароли по нажатию CapsLock и, насколько я помню, не умеет генерить случайные пароли вообще.
Потому что для того чтобы пакету некоторой длины n быть кратным некоторой частоте дискретизации f, должно быть справедливым выражение: n = x*f, где x принадлежит множеству натуральных чисел. Легко видно, что n не может быть меньше f. То есть, термин «кратность» вами употреблен неверно.
Однако частота дискретизации в свою очередь может быть кратной размеру пакета. Только это совсем совсем ни для чего не нужно. До тех пор пока аудиоустройству есть что воспроизводить, а именно его внутреннее FIFO для сэмплов не пустое, данные можно передавать хоть побайтно. А если случилось так, что устройству играть уже нечего, то речь идет уже не о джиттере и рассматривать эту ситуацию с точки зрения оценки искажений бессмысленно. Такой ситуации просто не должно возникать.
У USB как известно имеется 4 класса оконечных устройств...
Все же, словосочетание «оконечное устройство» является не вполне корректным переводом термина «endpoint» из стандарта USB потому, что с точки зрения протокола это никакое не устройство, а всего лишь логический адрес источника или приемника данных в интерфейсе USB устройства. В зависимости от реализации USB контроллера в конкретном устройстве, endpoint'ы могут быть, а могут и не быть реализованы аппаратно. Более корректный перевод предложить не могу. Для себя вообще избегаю перевода подобных терминов.
Кроме того, вы смешали в кучу стандарт USB и спецификацию USB Device Class Definition for Audio Devices.
Стандарт USB определяет четыре типа endpoint: Control, Interrupt, Bulk и Isochronous. При этом в аудиоустройствах для передачи данных используются isochronous endpoint'ы. Заметим, что такие endpoint'ы гарантируют пропускную способность и задержку, но не гарантируют доставку данных.
Как правило для аудиоустройств используется поточный режим с гарантированной доставкой пакетов, но без гарантии своевременности.
Наверное, здесь вы все таки имели в виду bulk-режим. Называть его поточным некорректно.
Я допускаю, что такие устройства есть исходя из теоретической возможности их создания, но мне они не попадались. Если говорить об устройствах не требующих для своей работы отдельных драйверов, то есть об устройствах совместимых с USB Device Class Definition for Audio Devices, то они обязаны использовать isochronous endpoint'ы. Таким образом, ваше утверждение ложно.
Спецификация USB Device Class Definition for Audio Devices определяет три режима синхроницации АЦП и ЦАП с хостом: synchronous(синхронный), adaptive(адаптиный) и asynchronous(асинхронный). Именно выбор режима синхронизации влияет на джиттер. Как именно — я покажу после того как мы дадим определение джиттеру в данном контексте.
Когда мы говорим о джиттере в контексте цифрового аудио, речь идет об отклонении фактического времени произведения аналого-цифрового или цифро-аналогового преобразования от сетки квантования. То есть преобразование каждого сэмпла происходит не строго в момент времени определенный частотой дискретизации, а в окрестностях этого момента времени.
Вообще, такой джиттер имеет место быть в каждом АЦП или ЦАП, а основной причиной его возникновения является нестабильность тактовых генераторов используемых для тактирования преобразователей. Однако, построить хороший задающий генератор и тем самым свести джиттер к минимуму не так сложно. Проблема заключается в том, что в дешевых аудиоинтерфейсах АЦП и ЦАПы синхронизируются не от встроенного тактового генератора, а либо непосредственно от шины USB, через умножитель частоты на PLL(если конкретнее, то от 1kHz кадрового строба USB) в режиме synchronous, либо содержат дополнительный генератор который подстраевается под частоту 1kHz от USB в режиме adaptive. Нетрудно догадаться, этот однокилогерцовый сигнал в общем случае может быть очень нестабильным. И часто таким и является. Устройства второго типа подвержены влиянию этой нестабильности несколько менее, так как подстройка частоты задающего генератора осуществляется более плавно.
Устройства, работающие в режиме asynchronous, имеют свой собственный задающий генератор и при правильной реализации неподвержены никакому влиянию со стороны USB. В создании таких устройств нет ровным счетом ничего нетривиального. Другое дело что среди дешевых микросхем для низкобюджетных аудиоинтерфейсов их просто нет.
Сухой остаток такой: USB как протокол — хороший, ничего нетривиального в уменьшении джиттера нет, не нужно это просто никому в дешевых микросхемах для низкобюджетных решений.
Еще одна проблема — фиксированный размер пакета передачи, который может быть не кратен частоте дискретизации, что опять же приведет к увеличению джиттера.
Это уже выдумки. Размер пакета передачи USB вообще никогда не кратен частоте дискретизации, если что. Скорее всего, вы хотели сказать что из однокилогерцового фреймового сигнала сложно получить стабильные 44.1kHz? Тогда — да. Но что за формулировка…
На вашей схеме перепутана полярность конденсаторов C12 и C13. Оба эти конденсатора должны быть подключены плюсовым выводом к микросхеме, а не к нагрузке (см. даташит). Кроме того, кажется немного странным выбор значений емкостей конденсаторов в обвязке линейного стабилизатора DA1: C9 слишком мал, а C10 наоборот, слишком велик.
Копипастить в статью текст из Википедии без указания источника есть не очень хорошо. Называть вашу программу безопасной — некорректно. Ставить на все это пометку tutorial — безответственно. Подумайте о тех людях, которые разбираются в предмете ещё меньше вас. Вы большой молодец в том, что пытаетесь разобраться в предмете, но гораздо лучше было бы описать собственный опыт и причины по которым вы принимали те или иные решения, чем весьма скромный результат. И напоследок, алгоритм разработки приложения вы точно не разрабатывали, разрабатывали вы собственно само приложение. Учитесь формулировать свои мысли так, чтобы они были понятны не только вам. Печатное слово требует очень строгого к себе отношения. И удачи вам с новыми статьями.
Вы очень удивитесь когда узнаете, что «топовый», как вы выразились, рубанок стоит дороже многих рейсмусов. Погуглите цены на Veritas и Lie Nielsen. Это если говорить про топ.
А если говорить про бюджет, то тут есть проблема, что рубанки после покупки надо доводить. Например, править подошву. Это сложно.
Кроме того, рубанки надо ещё уметь точить и это тоже не самое простое занятие.
Ну и до кучи, работать фуганком и рейсмусом тупо на порядок проще в плане навыков, которые для этого нужны.
Что касается стеганографии, просто «поправить» тут мне кажется не выйдет.
Не поленился и посмотрел исходник. С точки зрения и криптографии, и стеганографии то, что Вы сделали — это дно. Простите, ничего личного. Теперь что именно делает Ваше решение дном:
Полегче, это всего лишь гипотеза. И никаких экспериментальных подтверждений этой гипотезы до сих пор нет. Более того, если даже пространство и дискретно, то его зерно как минимум на 13 порядков меньше планковской длины.
А как и чем вы померяли, если не секрет? И какой у вас размер комнаты(длина, ширина, высота)?
Тру-сабвуфер должен стоять в тру-комнате в первую очередь, как и любая другая тру-аккустика. И это влияет на восприятие звука существенно больше, чем шипы, крутость колонок, крутость усилителя и прочие радости. Хорошие студийные мониторы плюс типичная комната в квартире и у вас будет ТАКАЯ неравномерность АЧХ начиная с баса и до нижней середины(300Гц), что по сравнению с этим, неравномерность АЧХ усилителей и колонок будет просто шумом. Если конкретнее, то из-за резонансов между стенами, потолком и полом неравномерность АЧХ может легко составить что-нибудь порядка 30дБ… o_O
А еще и время реверберации на разных частотах будет разным. Так что, сколько не делай лучшие в мире колонки с сабвуферами, все равно, в типичной квартире звучать они будут как говно…
Вот видео, которое очень хорошо и наглядно объясняет насколько сильную роль играет звуковая отделка помещения, слушать надо в наушниках, чтобы исключить влияние своей комнаты(те, кому лень смотреть все видео могут промотать до середины, там как раз начинаются сравнения помещений до и после отделки):
http://youtu.be/dB8H0HFMylo
Однако частота дискретизации в свою очередь может быть кратной размеру пакета. Только это совсем совсем ни для чего не нужно. До тех пор пока аудиоустройству есть что воспроизводить, а именно его внутреннее FIFO для сэмплов не пустое, данные можно передавать хоть побайтно. А если случилось так, что устройству играть уже нечего, то речь идет уже не о джиттере и рассматривать эту ситуацию с точки зрения оценки искажений бессмысленно. Такой ситуации просто не должно возникать.
Все же, словосочетание «оконечное устройство» является не вполне корректным переводом термина «endpoint» из стандарта USB потому, что с точки зрения протокола это никакое не устройство, а всего лишь логический адрес источника или приемника данных в интерфейсе USB устройства. В зависимости от реализации USB контроллера в конкретном устройстве, endpoint'ы могут быть, а могут и не быть реализованы аппаратно. Более корректный перевод предложить не могу. Для себя вообще избегаю перевода подобных терминов.
Кроме того, вы смешали в кучу стандарт USB и спецификацию USB Device Class Definition for Audio Devices.
Стандарт USB определяет четыре типа endpoint: Control, Interrupt, Bulk и Isochronous. При этом в аудиоустройствах для передачи данных используются isochronous endpoint'ы. Заметим, что такие endpoint'ы гарантируют пропускную способность и задержку, но не гарантируют доставку данных.
Как правило для аудиоустройств используется поточный режим с гарантированной доставкой пакетов, но без гарантии своевременности.
Наверное, здесь вы все таки имели в виду bulk-режим. Называть его поточным некорректно.
Я допускаю, что такие устройства есть исходя из теоретической возможности их создания, но мне они не попадались. Если говорить об устройствах не требующих для своей работы отдельных драйверов, то есть об устройствах совместимых с USB Device Class Definition for Audio Devices, то они обязаны использовать isochronous endpoint'ы. Таким образом, ваше утверждение ложно.
Спецификация USB Device Class Definition for Audio Devices определяет три режима синхроницации АЦП и ЦАП с хостом: synchronous(синхронный), adaptive(адаптиный) и asynchronous(асинхронный). Именно выбор режима синхронизации влияет на джиттер. Как именно — я покажу после того как мы дадим определение джиттеру в данном контексте.
Когда мы говорим о джиттере в контексте цифрового аудио, речь идет об отклонении фактического времени произведения аналого-цифрового или цифро-аналогового преобразования от сетки квантования. То есть преобразование каждого сэмпла происходит не строго в момент времени определенный частотой дискретизации, а в окрестностях этого момента времени.
Вообще, такой джиттер имеет место быть в каждом АЦП или ЦАП, а основной причиной его возникновения является нестабильность тактовых генераторов используемых для тактирования преобразователей. Однако, построить хороший задающий генератор и тем самым свести джиттер к минимуму не так сложно. Проблема заключается в том, что в дешевых аудиоинтерфейсах АЦП и ЦАПы синхронизируются не от встроенного тактового генератора, а либо непосредственно от шины USB, через умножитель частоты на PLL(если конкретнее, то от 1kHz кадрового строба USB) в режиме synchronous, либо содержат дополнительный генератор который подстраевается под частоту 1kHz от USB в режиме adaptive. Нетрудно догадаться, этот однокилогерцовый сигнал в общем случае может быть очень нестабильным. И часто таким и является. Устройства второго типа подвержены влиянию этой нестабильности несколько менее, так как подстройка частоты задающего генератора осуществляется более плавно.
Устройства, работающие в режиме asynchronous, имеют свой собственный задающий генератор и при правильной реализации неподвержены никакому влиянию со стороны USB. В создании таких устройств нет ровным счетом ничего нетривиального. Другое дело что среди дешевых микросхем для низкобюджетных аудиоинтерфейсов их просто нет.
Сухой остаток такой: USB как протокол — хороший, ничего нетривиального в уменьшении джиттера нет, не нужно это просто никому в дешевых микросхемах для низкобюджетных решений.
Еще одна проблема — фиксированный размер пакета передачи, который может быть не кратен частоте дискретизации, что опять же приведет к увеличению джиттера.
Это уже выдумки. Размер пакета передачи USB вообще никогда не кратен частоте дискретизации, если что. Скорее всего, вы хотели сказать что из однокилогерцового фреймового сигнала сложно получить стабильные 44.1kHz? Тогда — да. Но что за формулировка…