ASP .NET Web Service
Автор темы: key, May 03 2007 14:39
10 ответов в этой теме
#1
Опубликовано 03 May 2007 - 14:39
Есть веб-служба. У нее есть конфигурационный файл. Файл не стандартный, а пользовательнский (мой то бишь). Этот файл должен быть зашифрован.
Сам процесс и методы шифрования проблем не вызывают. Проблема возникает при выборе на каком этапе проводить шифрование, так как я хочу иметь возможность изменять конфигурационный файл в любой момент.
Вопрос: на каком этапе работы службы запускать шифрование конфигурационного файла?
З.Ы: мне пока в голову приходит одно решение: сделать отдельный метод, смотрящий наружу, ему на вход подавать имя конфигурационного файла. Этот метод шифрует файл и созраняет публичный и приватный ключи в глобальном объекте. Этот объект используетс яв методе зеркальном вышеописанному, то есть он расшифровывает зашифрованный конфигурациооный файл. Первый метод вызывать в начале основного метода веб-службы, второй в конце основного метода. Минус этого подхода в том, что изменить конфигурационный файл я смогу только один раз, перед запуском службы, потом конфигурационный файл будет зашифрован и изменить его без обращения к коду веб-службы не получится. Так что ищу другое решение
всем заранее спасибо, если сможете помочь
Сам процесс и методы шифрования проблем не вызывают. Проблема возникает при выборе на каком этапе проводить шифрование, так как я хочу иметь возможность изменять конфигурационный файл в любой момент.
Вопрос: на каком этапе работы службы запускать шифрование конфигурационного файла?
З.Ы: мне пока в голову приходит одно решение: сделать отдельный метод, смотрящий наружу, ему на вход подавать имя конфигурационного файла. Этот метод шифрует файл и созраняет публичный и приватный ключи в глобальном объекте. Этот объект используетс яв методе зеркальном вышеописанному, то есть он расшифровывает зашифрованный конфигурациооный файл. Первый метод вызывать в начале основного метода веб-службы, второй в конце основного метода. Минус этого подхода в том, что изменить конфигурационный файл я смогу только один раз, перед запуском службы, потом конфигурационный файл будет зашифрован и изменить его без обращения к коду веб-службы не получится. Так что ищу другое решение
всем заранее спасибо, если сможете помочь
Mess with the best
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
#2
Опубликовано 06 May 2007 - 14:08
А чем web.config не устраивает?
И расшифровывать файл и читать настройки будешь при каждом вызове веб-метода? По-моему то не лучшее решение с точки зрения затраты ресурсов.
И расшифровывать файл и читать настройки будешь при каждом вызове веб-метода? По-моему то не лучшее решение с точки зрения затраты ресурсов.
#3
Опубликовано 07 May 2007 - 12:42
wweb.config есть, там прописана только тип аутентификации. Затрата ресурсов мало, так как файлик маленький, шифровка и расшифровка проходит очень и очень быстро. Читать настройки при каждом вызове, но можно и один раз сделать, но пока не надо.
На самом деле я уже решил проблему. Просто изначально не совсем правильно понял задание. Сейчас сделал отдельную утилитку, которая щифрует и расшифровывает файл. Все пашет Используется симметричное шифрование, его пока хватит.
Но возникла другая проблема. Есть два метода, выполняющих одно действие в обе стороны, то есть один метод делает + от одного бита, второй делает - от того же бита
Код метода на "+", метод "портит" ключ шифрования, чтобы не хранить его в открытом виде на серваке:
private byte[] ResolveKey(byte[] protectedKey)
Вопрос: в чем проблема в этих двух методах?
На самом деле я уже решил проблему. Просто изначально не совсем правильно понял задание. Сейчас сделал отдельную утилитку, которая щифрует и расшифровывает файл. Все пашет Используется симметричное шифрование, его пока хватит.
Но возникла другая проблема. Есть два метода, выполняющих одно действие в обе стороны, то есть один метод делает + от одного бита, второй делает - от того же бита
Код метода на "+", метод "портит" ключ шифрования, чтобы не хранить его в открытом виде на серваке:
private byte[] ProtectKey(byte[] originalKey) { byte[] protectedKey = new byte[originalKey.Length]; for ( int i = 0; i < originalKey.Length; i++ ) { if ( (i % 2) == 0 ) { byte val = (byte) (originalKey[i] >> 1); protectedKey[i] = val; } else { byte val = (byte) (originalKey[i] << 2); protectedKey[i] = val; } } return protectedKey; }Код метода "-", метод исправляет файл, производя обратное действие методу выше:
private byte[] ResolveKey(byte[] protectedKey)
{ byte[] originalKey = new byte[protectedKey.Length]; for ( int i = 0; i < protectedKey.Length; i++ ) { if ( (i % 2) == 0 ) { byte val = (byte) (protectedKey[i] << 1); originalKey[i] = val; } else { byte val = (byte) (protectedKey[i] >> 2); originalKey[i] = val; } } return originalKey; }По идее, после последовательного запуска методов первый-второй ключ изменится не должен... но он меняется или не меняется, но факт, что ключ пропущенный через эти два метода больше не позволяет расшифровать файл.
Вопрос: в чем проблема в этих двух методах?
Mess with the best
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
#4
Опубликовано 07 May 2007 - 16:01
Используй другую операцию для шифрования байта.
Побитовый сдвиг не подходит, т.к. при расшифровке теряются некоторые биты:
было:
11000111
после >> 1 стало:
01100011
после << 1:
11000110 - последний бит стал нулём!
Побитовый сдвиг не подходит, т.к. при расшифровке теряются некоторые биты:
было:
11000111
после >> 1 стало:
01100011
после << 1:
11000110 - последний бит стал нулём!
#5
Опубликовано 07 May 2007 - 16:08
дык это я понял у меня были подозрения, что именно в этом проблема. я даже специалньо распечатал на бумаге ключ до защиты и после прохода шифр-дешифр там реалньо теряется один бит... НО! даже если использовать другую операцию, например, "+" или "-", все равно не пашет.
я вот думаю... может изменять только те биты, изменение которых не приведет к переполнению типа?
я вот думаю... может изменять только те биты, изменение которых не приведет к переполнению типа?
Mess with the best
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
#6
Опубликовано 07 May 2007 - 16:28
Почему бы не использовать xor (оператор ^)?
Для простого шифрования вполне покатит.
Для простого шифрования вполне покатит.
#8
Опубликовано 07 May 2007 - 17:09
Применить ^ с тем же параметром.а обратное действие к этому оператору?
я что-то не соображу никак
Просто замени в своём коде >> и << на ^.
#9
Опубликовано 07 May 2007 - 17:19
не помогло... ну в общем-то ожидал этого...
потому что в таком случае шифрование в одну сторону только.
так как если применить XOR сначала в оригинальному ключу, а потом к получившемуся защищенному еще раз XOR, исходного оригинального ключа мы не получим никак в контексте моего кода.
или я может чего-то не понимаю?
апдейт: проблема решается, если применять XOR ко всем байтам в массиве. тогда все шифруется и дешифруется пока оставлю так...
ASD, большое спасибо за помощь
потому что в таком случае шифрование в одну сторону только.
так как если применить XOR сначала в оригинальному ключу, а потом к получившемуся защищенному еще раз XOR, исходного оригинального ключа мы не получим никак в контексте моего кода.
или я может чего-то не понимаю?
апдейт: проблема решается, если применять XOR ко всем байтам в массиве. тогда все шифруется и дешифруется пока оставлю так...
ASD, большое спасибо за помощь
Mess with the best
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
#10
Опубликовано 07 May 2007 - 17:29
У меня всё работает:
http://ru.wikipedia.org/wiki/XOR
class Program { static void Main(string[] args) { byte value = 199; Console.WriteLine(string.Format("before crypt {0}:", value)); Console.WriteLine(string.Format("after crypt {0}:", value ^ 34)); Console.WriteLine(string.Format("after decrypt {0}:", value ^ 34 ^ 34)); Console.ReadLine(); } }
http://ru.wikipedia.org/wiki/XOR
#11
Опубликовано 07 May 2007 - 17:33
ну правильно, если ко всем байтам применять XOR:)
а если сделать как у меня, то с проверкой номера байта на четность, то все нечетные станут нулями после метода обратного защите. так как во время защиты к ним не была применена операция XOR:)
а если сделать как у меня, то с проверкой номера байта на четность, то все нечетные станут нулями после метода обратного защите. так как во время защиты к ним не была применена операция XOR:)
Mess with the best
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
Die like the rest
Пуля производит удивительные изменеия в голове, даже если она попала в задницу.
(С) Лукьяненко "Черновик"
Conseal nohing.
And watch the fools searching forever.
Посетителей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных пользователей