Шифрация файла.

← →
Xmen (2005-09-08 15:28) [0]

Привет мастера.
У меня такое дело. Есть фирма и есть у него филиали. С каждого филиала приходить текстовые файлы (связаны с денгами), которую моя программа создаёт. Этих файлов принимает прога в фирме и обрабатвает его. Чтобы этого файла "умелыми ручками" не поправили на свой лад, нужно этого файла шифравать. И когда принимает этого файла прога в фирме чтобы провериял его целостьность и дешифравал бы его. Как мне нужно этого сделать и организовать? Я знаю что из меня все равно хорошого шифравалчика не выдеть, но хотелось бы как небуд зашитить данные в файле. У вас в практике такое было, поделитесь знаниями. Помогите начать уму шифрования.

← →
ANB © (2005-09-08 15:30) [1]

> Xmen (08.09.05 15:28)
- можно и не шифровать, достаточно сгенерить сертификат. Лучше купи книжку по криптографии.

← →
Reindeer Moss Eater © (2005-09-08 15:40) [2]

Помогите начать уму шифрования.

Думаешь, типа здесь все ужа начинали уму шифрования?

← →
Xmen (2005-09-08 15:45) [3]

Да уменя уже 3 лежать, правда не хвастуюсь я их тольком не прочитал (но обязательно прочту) но мне нужна это испытать в практике. В книгах есть примеры по формулам
E(P)=C
D(C)=M
D(E(P))=P
итп.
Мне интересно это в коде как реализовать можно и какими методами?
И что означаеть
достаточно сгенерить сертификат.

← →
GLFox © (2005-09-08 15:47) [4]

Читайте, батенька, несимметричные алгоритмы шифрования. Тип RSA и все такое прочее... Не кисло будет глянуть еще по темам: хеш-функции и цифровая подпись. Можно и несимметричные, но как-то не солидно это. ;)

← →
Reindeer Moss Eater © (2005-09-08 15:56) [5]

Чтобы этого файла "умелыми ручками" не поправили на свой лад, нужно этого файла шифравать.

Шифрование не решает задачи контроля целостности документа. У него другая задача.
Здесь необходимо применять ЭЦП.

← →
Xmen (2005-09-08 16:04) [6]

2>>Reindeer Moss Eater © (08.09.05 15:56) [5]

Чтобы этого файла "умелыми ручками" не поправили на свой лад, нужно этого файла шифравать.

Шифрование не решает задачи контроля целостности документа. У него другая задача.
Здесь необходимо применять ЭЦП.

Вот и думую как это реализовать (как я понял ЭЦП-электронно цифравой подпись). Я до этого исползовал простой метод шифравания замены букв или цифр на определенные цифры. Но это очень примитивно, этого даже может расшифравать продвинуты юзер. По другим методом шифравания у меня нету опыта только прочитал немножко инфы из книжки про всякий des, Rsa , гост.

← →
Alexander Panov © (2005-09-08 16:07) [7]

http://www.crypto-central.com/

← →
Alexander Panov © (2005-09-08 16:08) [8]

Либо PGP for DOS.

← →
Anatoly Podgoretsky © (2005-09-08 16:15) [9]

Цифровая подпись и писать программу не требуется, достаточно существующих.

← →
Xmen (2005-09-08 16:34) [10]

2>>Anatoly Podgoretsky © (08.09.05 16:15) [9]

Цифровая подпись и писать программу не требуется, достаточно существующих.

Мне бы простую программу (может функцию) написать, немножко сложнее чем простое замена букв. Типа найти код буквы и добавить какую нибуд цифру и по этому коду найти букву выдить абракадабра, но при этом нужно имеет ввиду что коды недольжны привисить 255. когда это происходить то нужно на оставшися сумму начать с нуля.
Пример.
Если а то 45 добавим цифру 20 и получем букву с кодом 65 п а если я то у него может быть код 240 если добавим 20 то получиться 260 токого в принципе недолжно быт потомчто коды должны быть до 255 и поэтому оставшися 5 начнем с нуля и получаем букву с кодом 5 г. Потамучто буквы с кодом до 21 свободны. Мне нужно в этом роде но посложнее.

← →
ANB © (2005-09-08 17:05) [11]

> Xmen (08.09.05 16:34) [10]
xor с плавающим ключом. Писать не тяжело, но ломать тоже. Хотя обычный юзер уже не взломает. Алгоритм лучше придумать самому, авось дольше продержится. Но если файлы с деньгами, то это - не лучший вариант.

← →
Игорь Шевченко © (2005-09-08 17:39) [12]

А эта...MD5 уже отменили ?

← →
palva © (2005-09-08 19:54) [13]

> Алгоритм лучше придумать самому, авось дольше продержится. Но если файлы с деньгами, то это - не лучший вариант.

Это точно. Если деньги пропадут, кого будут сажать? Того, кто придумал алгоритм. До конца жизни будешь сидеть.

В свое время я написал для забавы консольную программу шифрования по ГОСТ с очень простым интерфейсом.
http://pa123.nm.ru/gost_pa.html
Она написана на паскале с ассемблером и имеет исходные тексты доступные для анализа. Можешь попробовать. Это именно шифрование, а не контроль целостности. Вообще, в алгоритме ГОСТ предусмотрена возможность так называемой имитовставки - криптографического хэша. То есть, человек, которому известен ключ шифрования, имеет возможность проверить, был ли искажен файл при передаче. Но у меня это не реализовано.

Но вообще таких программ написано очень много. Только мало кто прикладывает исходные тексты. А если прикладывает, то они такого объема, что очень трудоемко их проанализировать.

← →
AlexWlad © (2005-09-08 20:21) [14]

А не проще заархивировать?
uses Zlib и т.д. (ну то есть насколько умелы те самые ручки)

← →
Xmen (2005-09-09 08:49) [15]

2>>AlexWlad © (08.09.05 20:21) [14]

А не проще заархивировать?
uses Zlib и т.д. (ну то есть насколько умелы те самые ручки)

Программа и так архивируется но пароль легко может сломан с помощю программ.

← →
Alexander Panov © (2005-09-09 10:00) [16]

Вот эти 2 постинга не согласуются между собой.

Xmen (08.09.05 16:34) [10]
Мне бы простую программу (может функцию) написать, немножко сложнее чем простое замена букв

Xmen (09.09.05 8:49) [15]
Программа и так архивируется но пароль легко может сломан с помощю программ.

Между тем в [7] есть ссылка, где можно взять примеры генерации подписи, подписывания документов, шифрования и обратных операций.

На анализ написание своего кода понадобится около часа.

← →
Brother (2005-09-12 07:32) [17]

Что шифруй, что не шифруй, все ровно получишь ...
:)

← →
iXT (2005-09-12 20:24) [18]

Остановись на PGP for Dos. Пятая версия позволяет делать ключи до 1024 (RSA). Если не нравится Dos то приется читать SDK - PGP Corp дает использовать свои dll, правда исходники на C++ (Сам с ними мучаюся). Зайди па RSDN.ru, там неплохая статья. Еще вариант - CriptAPI, там про него тоде есть!

Вообще весь вопрос звучит очень странно. Филиалы направляют в центральный офис документы связанные с деньгами, а по дороге эти файлы могут быть злонамеренно подправлены. Теперь представим, что из филиала пришел файл с предписанием выплатить деньги некоему лицу за поставленный филиалу товар, а сумма оказалась завышена в два раза. Тот кто отправлял депешу уверяет, что он указал правильную сумму, и сумма была исправлена взломщиком слабого шифра. Получатель денег испарился. С кого взыскивать деньги?
А если к тому же депеша была получена не через EMail, а путем непосредственной модемной связи без участия почтового провайдера.

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

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

Таким образом, пока на уровне руководства организации не решены все эти вопросы, думать об алгоритме преждевременно.

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

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

HashLib! - это быстрая и гибкая библиотека для Delphi и C++ Builder, работающая с хэш-алгоритмами MD2, MD4, MD5, SHA-1, SHA (256, 384, 512), Haval (128, 160, 192, 224, 256), GOST R 34.11-94, Ripe-MD (128, 160), Tiger (128, 160, 192), CRC32, CRC32b, Adler32. Простой общий интерфейс (собственный API для каждого алгоритма), функции низкого и высокого уровня (буферы, строки, файлы). Шаблоны для самопроверки. Малый размер (SysUtils и другие системные модули не используются). Некоторые функции переписаны на Ассемблере. Включены примеры на C++ и Delphi.

http://bib.com.ua/info1647.html

>>Ihor Osov"yak © (12.09.05 22:13) [21]
>>да, насколько я знаю, в некоторый странах есть уголовная ответсвенность за разработку соотв. систем в случае отсутсвия лицензии.

Это элементарно обходится. Просто назвать систему, например как "система защиты информации от НСД" и делай там все что хочешь. Хотя законодательно алгоритм и результаты работы программы признаны не будут.

> Xmen (08.09.05 15:28)

Как вариант, может, подойдет.

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

API для работы с ключами - достаточно простой, сам процесс кодирования/декодирования они берут на себя.

А документы между головным офисом и филиалами пересылаются уже по HTTP, в теле запроса идет шифрованный документ.

> Это элементарно обходится.

Думаю, это зависит от особенностей национального законодательства. Хотя могу ошибаться - соотв. вопросом интересовался лет 6-8 назад...

← →
SergP. (2005-09-13 10:26) [26]

> Программа и так архивируется но пароль легко может сломан
> с помощю программ.

Смотря какой пароль....
Что-то я не находил методов быстрого подбора пароля к архивам, даже таким как zip, если пароль представляет собой строку с довольно большим кол-вом символов

Шифрация файла. Найти похожие ветки