Re: чем плоха "подпись" с помощью хэш-функции?
В сообщении от 22 Июнь 2007 10:49 Ed написал(a): > схема: > отправитель - небезопасный канал (интернет) - получатель > > я контролирую и отправителя и получателя. > > данные несекретные, шифровать их особого смысла нет. но получатель > должен убедиться, что данные отправил действительно отправитель. > > чем плохо поступить так - заранее сгенерировать ключ (просто > последовательность байт), далее приписываем этот ключ к сообщению и > генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение > + хэш - зная ключ мы легко можем проверить подлинность сообщения. Ну и правильно. Получается, что ключ у тебя в открытом виде передается, враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует по такому же алгоритму хэш. А теперь пойми где подделка. > плюсы - легко в реализации, низкая вычислительная сложность, минимальное > увеличение размера передаваемой информации. > > из минусов пока вижу только необходимость безопасно доставить ключ на > обе стороны - но в данном случае это проблемы не представляет. Главный минус - это то, что ключ знают и тот, кто передает, и тот, кто получает, и тот, кто подделывает. Количество информации такого ключа по Шеннону равно нулю, а значит он просто отнимает байты от пропускной способности - это его второй минус. > а с точки зрения криптостойкости - хуже этот вариант обычной подписи > (afaik формируем хэш и шифруем его)? Фишка в ЭЦП - ключи ассиметричные. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and gimble: MD> Ну и правильно. Получается, что ключ у тебя в открытом виде передается, MD> враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует MD> по такому же алгоритму хэш. А теперь пойми где подделка. Как я понял, передаётся оригинальное сообщение плюс подпись "оригинал+ключ". -- JID: [EMAIL PROTECTED]
Re: посмотреть настройки роутера
В сообщении от 22 Июнь 2007 03:31 Nicholas написал(a): > > Разве что самому зайти на него и посмотреть там :-) > > В описании IMQ шейпинга, например, говорится что иногда роутер может > сказать на какой скорости он готов принимать трафик. Может иногда он и говорит, но только по каком-нибудь протоколу а-ля RSVP. > Возможно есть и другие варианты - как от имени нижестоящего сервера > узнать у роутера настройки сети. Вообще-то такие вещи запрещают, потому что это может сгодится злоумышлинику за очень полезную информацию. Так что это можно лишь наблюдать по внешним проявлениям. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bacports update
В сообщении от 21 Июнь 2007 20:54 andrey i. mavlyanov написал(a): > Всем привет! > > Есть некоторые пакеты (openoffice.org, gajim) установленные из etch-backports. > > Вопрос -- как получать обновления. если указать -t etch-backports > aptitude'у, то эта зараза собирается обновлять все доступные новые пакеты. :( > А если использовать связку pin/priority в /etc/apt/preferences? man 5 apt_preferences. Правда я не знаю катит ли это для aptitude. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pppd и cd
В сообщении от 21 Июнь 2007 20:46 Ed написал(a): > меня глючит или это нормально (цитата из man pppd): > modem Use the modem control lines. This option is the default. > With this option, pppd will wait for the CD (Carrier Detect) signal from > the modem to be asserted when opening the serial device (unless a > connect script is specified), and it will drop the DTR (Data Terminal > Ready) signal briefly when the connection is terminated and before > executing the connect script. > > проверил - действительно работает как написано - состояние cd > анализируется только при установлении соединения. > если при поднятом ppp-соединении модем ложит cd, то pppd это игнорирует. > как же так? ;) Есть мнение, что при этом должен закрыться дескриптор того tty-устройства, через которое работает pppd. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Поведение libc
В сообщении от 21 Июнь 2007 21:23 Yuri Kozlov написал(a): > Я, конечно, не силён в этом, но судя по > > http://www.opengroup.org/pubs/online/7908799/xsh/timer_create.html > > CLOCK_REALTIME должен быть реализован везде, а остальное никто > не обещал. :) > Что и говорит ошибка > [EINVAL] > The specified clock ID is not defined. На мой взгляд CLOCK_MONOTONIC должен быть либо реализован во всех функциях, либо нигде. А получается что clock_getres работает всегда, а timer_create только когда прилинковано динамически. Кроме того, CLOCK_MONOTONIC очевидно есть в 2.6 ядре. А в 2.4 POSIX Real Time не поддержан вообще. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпис ь" с помощью хэш-функ ции?
Max Dmitrichenko wrote: чем плохо поступить так - заранее сгенерировать ключ (просто последовательность байт), далее приписываем этот ключ к сообщению и генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение + хэш - зная ключ мы легко можем проверить подлинность сообщения. Ну и правильно. Получается, что ключ у тебя в открытом виде передается, враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует по такому же алгоритму хэш. А теперь пойми где подделка. я конечно идиот, но не настолько. передается сообщение + хэш(сообщение+ключ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pppd и cd
Max Dmitrichenko wrote: если при поднятом ppp-соединении модем ложит cd, то pppd это игнорирует. как же так? ;) Есть мнение, что при этом должен закрыться дескриптор того tty-устройства, через которое работает pppd. не закрывается. в какую сторону копать? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
В сообщении от 22 Июнь 2007 11:15 Mikhail Gusarov написал(a): > > Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and > gimble: > > MD> Ну и правильно. Получается, что ключ у тебя в открытом виде передается, > MD> враг берет вставляет свое сообщение, приделывает этот же ключ и > генерирует > MD> по такому же алгоритму хэш. А теперь пойми где подделка. > > Как я понял, передаётся оригинальное сообщение плюс подпись "оригинал+ключ". Даже если так, то получается, что реципиент может создавать сообщения от имени автора. Что в общем не универсально, поскольку необходимость уверено получать сообщения от всех абонентов возникает чаще, чем уверено получать сообщения от абонента, который безусловно доверяет тебе (свой ключ). Кроме того, схема с несимметричным ключом _тоже_ _требует_ доставки публичного ключа другим защищенным каналом. (Или хотя бы отпечатка ключа). В общем случае используется система распространения ключей, используя центр распространения ключей. В этом случае все абоненты получают публичные ключи других абонентов по требованию по обычному каналу, но сам публичный ключ подписан ключом центра распространения ключей, который (предполагается) есть у всех абонентов ЦРК. И ещё: если у тебя паранойя - это вовсе не значит, что за тобой не следят :) -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
В сообщении от 22 Июнь 2007 11:29 Ed написал(a): > Max Dmitrichenko wrote: > > Ну и правильно. Получается, что ключ у тебя в открытом виде передается, > > враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует > > по такому же алгоритму хэш. А теперь пойми где подделка. > > > > я конечно идиот, но не настолько. > передается сообщение + хэш(сообщение+ключ) Сорри, но вот эта фраза сбила меня с толку: > далее приписываем этот ключ к сообщению Но все равно схема не секьюрна - читай соседний тред. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
On 6/22/07, Mikhail Gusarov <[EMAIL PROTECTED]> wrote: Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and gimble: MD> Ну и правильно. Получается, что ключ у тебя в открытом виде передается, MD> враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует MD> по такому же алгоритму хэш. А теперь пойми где подделка. Как я понял, передаётся оригинальное сообщение плюс подпись "оригинал+ключ". По-моему, метод нестоек в отношении коллизий используемой хэш-функции. -- С уважением, Константин Матюхин
Re: чем плоха "подпис ь" с помощью хэш-функ ции?
Konstantin Matyukhin wrote: Как я понял, передаётся оригинальное сообщение плюс подпись "оригинал+ключ". По-моему, метод нестоек в отношении коллизий используемой хэш-функции. ровно столько же, сколько и обычная ЭЦП: сообщение + шифрованный хэш сообщения -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pppd и cd
В сообщении от 22 Июнь 2007 11:31 Ed написал(a): > Max Dmitrichenko wrote: > >> если при поднятом ppp-соединении модем ложит cd, то pppd это игнорирует. > >> как же так? ;) > >> > > > > Есть мнение, что при этом должен закрыться дескриптор того tty-устройства, > > через которое работает pppd. > > не закрывается. в какую сторону копать? В сторону ядра. Файл ppp_async.c - для PPP, файл serial_core.c и 8250.c для того, чтобы смотреть, как влияет состояние линий. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
Max Dmitrichenko wrote: Даже если так, то получается, что реципиент может создавать сообщения от имени автора. Что в общем не универсально, поскольку необходимость уверено получать сообщения от всех абонентов возникает чаще, чем уверено получать сообщения от абонента, который безусловно доверяет тебе (свой ключ). мне и не нужна универсальная схема. у меня есть сервер (мой) и куча железок (опять же моих), которые обмениваются информацией. залить ключ при прошивке железки проблемы не представляет. в принципе на железке будет обычный linux, можно воспользоваться и openssl и стандартными алгоритмами - но если можно сделать проще - почему бы и нет? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bacports update
На Thu, 21 Jun 2007 21:37:59 +0400 Mikhail A Antonov <[EMAIL PROTECTED]> записано: > On Thursday 21 June 2007 21:26, Alexander GQ Gerasiov wrote: > > На Thu, 21 Jun 2007 20:54:09 +0400 > > "andrey i. mavlyanov" <[EMAIL PROTECTED]> записано: > > > aptitude'у, то эта зараза собирается обновлять все доступные > > > новые пакеты. :( ^^^ > На сколько я понял, все-то и не надо > > > > просто upgrade или dist-upgrade > > если там будут обновления - они установятся. > А как только те, какие были ручками поставленны с бекпортов? > Т.е. не трогая остальные, которые из stable. А он так и поступит. он обновит пакеты, поставленные из stable из репозитория stable, а из бэкпортов, соответственно из пакетом поставленных из бэкпортов. > > Кажется вопрос был в этом. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bacports update
На Thu, 21 Jun 2007 21:38:16 +0400 Ed <[EMAIL PROTECTED]> записано: > Alexander GQ Gerasiov wrote: > >> Есть некоторые пакеты (openoffice.org, gajim) установленные из > >> etch-backports. > >> > >> Вопрос -- как получать обновления. если указать -t etch-backports > >> aptitude'у, то эта зараза собирается обновлять все доступные новые > >> пакеты. :( > >> > > просто upgrade или dist-upgrade > > если там будут обновления - они установятся. > > в продолжение темы - а как посмотреть, откуда пакет у меня > установлен? aptitude показывает номер версии, а какая это - из etch, > testing или ещё какая - непонятно. apt-cache policy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: управление пользо вателями
На Thu, 21 Jun 2007 23:25:55 +0400 Pavel Ammosov <[EMAIL PROTECTED]> записано: > On Wed, Jun 20, 2007 at 10:46:52AM +0400, Sergey V. Osipov wrote: > > Существует ли какая-ть система управления пользователями на базе > > ldap? примерный функционал: > >упр. уч. записями в ldap > >интеграция с samba. > >гибкая настройка - настройка под свои схемы ldap, возможность > > запуска скриптов и т.п. > > нашел GoSA, но тама используются свои схемы, поэтому не подходит > > пакет cpu. Похоже, должен подойти. cpu - отстой. по крайней мере в версии около саржа. А в етче версия не изменилась. > > В начале 200х я разработал свой набор утилит. На perl это было вовсе > несложно, но настройка, естественно, была прямо в коде и никакой > интеграции с samba там не было, всё и так работало. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
В сообщении от 22 Июнь 2007 13:13 Alexey Mikhailov написал(a): > существует внутрений веб-сервер (с локальным айпишником, имя inserv), > который стоит за сервером с внешним айпишником (например, с имененм > deb.com) > > задача состоит в том чтобы при вводе из вне адреса http://deb.com: > > клиенту выводилось содержимое внутреннего сервера http://inserv:80 > > как это можно реализовать? А компьютер-то один или разные? Хотя в общем и так и так можно пробросить порт через ssh :) -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
тунель для Apache
существует внутрений веб-сервер (с локальным айпишником, имя inserv), который стоит за сервером с внешним айпишником (например, с имененм deb.com) задача состоит в том чтобы при вводе из вне адреса http://deb.com: клиенту выводилось содержимое внутреннего сервера http://inserv:80 как это можно реализовать?
Re: управление пользов ателями
On Fri, Jun 22, 2007 at 12:41:29PM +0400, Alexander GQ Gerasiov wrote: > На Thu, 21 Jun 2007 23:25:55 +0400 > Pavel Ammosov <[EMAIL PROTECTED]> записано: > > пакет cpu. Похоже, должен подойти. > cpu - отстой. по крайней мере в версии около саржа. А в етче версия не > изменилась. Жалко. А выглядело хорошо... Почему отстой-то? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
В сообщении от 22 Июнь 2007 13:31 Alexey Mikhailov написал(a): > компы разные > > а как это сдлать? (через ssh) > > типа как ssh тунель? > > ssh -R :localhost:22 [EMAIL PROTECTED] > > т.е. ssh -R :localhost:80 [EMAIL PROTECTED] > > так? Ну да :) -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
запуск скрипта туннеля можно прописать в inittab c опцией respawn чтоб подымался я прилепил рисунок к письму с схемой, которую нужно реализовать В Птн, 22.06.2007, в 12:58, Aleksey Luzin пишет: > Лучше все-таки через iptables. ssh может по разным причинам упасть, а > iptablesу все пофигу > > Alexey Mikhailov wrote: > > компы разные > > > > а как это сдлать? (через ssh) > > > > типа как ssh тунель? > > > > ssh -R :localhost:22 [EMAIL PROTECTED] > > > > т.е. ssh -R :localhost:80 [EMAIL PROTECTED] > > > > так? > > > > > > > > В Птн, 22.06.2007, в 12:22, Max Dmitrichenko пишет: > > > >> В сообщении от 22 Июнь 2007 13:13 Alexey Mikhailov написал(a): > >> > >>> существует внутрений веб-сервер (с локальным айпишником, имя inserv), > >>> который стоит за сервером с внешним айпишником (например, с имененм > >>> deb.com) > >>> > >>> задача состоит в том чтобы при вводе из вне адреса http://deb.com: > >>> > >>> клиенту выводилось содержимое внутреннего сервера http://inserv:80 > >>> > >>> как это можно реализовать? > >>> > >> А компьютер-то один или разные? Хотя в общем и так и так можно пробросить > >> порт через ssh :) > >> > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] <>
Re: управление пользо вателями
На Fri, 22 Jun 2007 13:04:24 +0400 Pavel Ammosov <[EMAIL PROTECTED]> записано: > On Fri, Jun 22, 2007 at 12:41:29PM +0400, Alexander GQ Gerasiov wrote: > > На Thu, 21 Jun 2007 23:25:55 +0400 > > Pavel Ammosov <[EMAIL PROTECTED]> записано: > > > пакет cpu. Похоже, должен подойти. > > cpu - отстой. по крайней мере в версии около саржа. А в етче версия > > не изменилась. > > Жалко. А выглядело хорошо... Почему отстой-то? смутно помню, что во-первых не поддерживал новый протокол лдап, во-вторых был сильно убог и не позволял вменяемо управлять интересующей меня схемой (обычная схема + еще несколько классов вроде ftpAccount, mailAccount etc), да и то, что позволял было как-то убого (подробностей не помню). Из консольного наиболее адекватным выглядело то, что идет в комплекте с самбой. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bacports update
На Thu, 21 Jun 2007 22:40:58 +0400 "andrey i. mavlyanov" <[EMAIL PROTECTED]> записано: > Artem Chuprina wrote: > > >> нет. не установятся. потому что у etch-backports приоритет ниже > >> чем "etch". > > > > Если этот пакет _уже_ стоит из бэкпортов (т.е. у стоящего пакета не > > етчевская версия), то обновление приедет. > > не приходит :( > > а если указать -t etch-backports то aptitude показывает что таковые > есть скажи apt-cache policy пакет при апгрейде пакет обновится на ближайшую версию сверху, которая есть в каком-нить репозитории. если надо другую версию, то aptitude install -t etch-backports пакет -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
да , и с deb.com нельзя прямо попасть в локальную сеть, в которой находится inserv например для доступа из deb.com на inserv по ssh используется поднятый на inserv ssh-туннель: ssh -R :localhost:22 [EMAIL PROTECTED] -N В Птн, 22.06.2007, в 12:28, Oleg Rybnikov пишет: > Alexey Mikhailov пишет: > > существует внутрений веб-сервер (с локальным айпишником, имя inserv), > > который стоит за сервером с внешним айпишником (например, с имененм > > deb.com) > > > > задача состоит в том чтобы при вводе из вне адреса http://deb.com: > > > > клиенту выводилось содержимое внутреннего сервера http://inserv:80 > > > > как это можно реализовать? > > > iptables -t nat -I PREROUTING -p tcp -d --dport -j > DNAT --to-destination :80 > возможно еще понадобится > iptables -t nat -I POSTROUTING -p tcp -d --dport 80 -j SNAT > --to-source > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
Alexey Mikhailov пишет: > существует внутрений веб-сервер (с локальным айпишником, имя inserv), > который стоит за сервером с внешним айпишником (например, с имененм > deb.com) > > задача состоит в том чтобы при вводе из вне адреса http://deb.com: > > клиенту выводилось содержимое внутреннего сервера http://inserv:80 > > как это можно реализовать? > iptables -t nat -I PREROUTING -p tcp -d --dport -j DNAT --to-destination :80 возможно еще понадобится iptables -t nat -I POSTROUTING -p tcp -d --dport 80 -j SNAT --to-source -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
компы разные а как это сдлать? (через ssh) типа как ssh тунель? ssh -R :localhost:22 [EMAIL PROTECTED] т.е. ssh -R :localhost:80 [EMAIL PROTECTED] так? В Птн, 22.06.2007, в 12:22, Max Dmitrichenko пишет: > В сообщении от 22 Июнь 2007 13:13 Alexey Mikhailov написал(a): > > существует внутрений веб-сервер (с локальным айпишником, имя inserv), > > который стоит за сервером с внешним айпишником (например, с имененм > > deb.com) > > > > задача состоит в том чтобы при вводе из вне адреса http://deb.com: > > > > клиенту выводилось содержимое внутреннего сервера http://inserv:80 > > > > как это можно реализовать? > > А компьютер-то один или разные? Хотя в общем и так и так можно пробросить > порт через ssh :) > > -- > Макс > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Etch + GNOME + menu
Уважаемые, подскажите относительно простой способ добавления программ в главное меню GNOME работающего на etch. Настройки должны быть привязаны к конкретному пользователю. ~/.gnome2/vfolders похоже игнорируются. Права на выполнение у /etc/menu-methods/gnome-vfolder-user есть. В sarge проблем с этим не испытывал, а в etch даже ручки в GUI для изменения меню убрали. -- С уважением, Константин Матюхин
Re: тунель для Apache
Лучше все-таки через iptables. ssh может по разным причинам упасть, а iptablesу все пофигу Alexey Mikhailov wrote: > компы разные > > а как это сдлать? (через ssh) > > типа как ssh тунель? > > ssh -R :localhost:22 [EMAIL PROTECTED] > > т.е. ssh -R :localhost:80 [EMAIL PROTECTED] > > так? > > > > В Птн, 22.06.2007, в 12:22, Max Dmitrichenko пишет: > >> В сообщении от 22 Июнь 2007 13:13 Alexey Mikhailov написал(a): >> >>> существует внутрений веб-сервер (с локальным айпишником, имя inserv), >>> который стоит за сервером с внешним айпишником (например, с имененм >>> deb.com) >>> >>> задача состоит в том чтобы при вводе из вне адреса http://deb.com: >>> >>> клиенту выводилось содержимое внутреннего сервера http://inserv:80 >>> >>> как это можно реализовать? >>> >> А компьютер-то один или разные? Хотя в общем и так и так можно пробросить >> порт через ssh :) >> > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись " с помощью хэш-функции?
On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote: > из минусов пока вижу только > необходимость безопасно доставить ключ > на обе стороны - но в данном случае это > проблемы не представляет. > > а с точки зрения криптостойкости - хуже > этот вариант обычной подписи (afaik > формируем хэш и шифруем его)? Для одноразового ключа и большого количества сообщений IMHO хуже. С каждым перехваченным сообщением ключ становится все более уязвим. Если сообщения открыты -- особенно. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
В сообщении от 22 Июнь 2007 14:28 Иван Лох написал(a): > On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote: > > > из минусов пока вижу только > > необходимость безопасно доставить ключ > > на обе стороны - но в данном случае это > > проблемы не представляет. > > > > а с точки зрения криптостойкости - хуже > > этот вариант обычной подписи (afaik > > формируем хэш и шифруем его)? > > Для одноразового ключа и большого количества > сообщений IMHO хуже. С каждым перехваченным > сообщением ключ становится все более уязвим. > Если сообщения открыты -- особенно. Ну тут можно генерировать новый ключ на основе старого. Скажем, через каждые n сообщений. Алгоритм, естественно, должен быть известен обеим сторонам. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
Alexey Mikhailov пишет: существует внутрений веб-сервер (с локальным айпишником, имя inserv), который стоит за сервером с внешним айпишником (например, с имененм deb.com) задача состоит в том чтобы при вводе из вне адреса http://deb.com: клиенту выводилось содержимое внутреннего сервера http://inserv:80 как это можно реализовать? openvpn (если действительно нужен туннель) squid (если нужно на 1 реальный IP посадить несколько "спрятанных" серверов. правда, потребуется махинация с DNS-сервером) -- Игорь Чумак, системный администратор Generali-Garant tel (044) 206-88-20 icq 24049904 jabber: [EMAIL PROTECTED] e-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
Игорь Чумак wrote: Alexey Mikhailov пишет: существует внутрений веб-сервер (с локальным айпишником, имя inserv), который стоит за сервером с внешним айпишником (например, с имененм deb.com) задача состоит в том чтобы при вводе из вне адреса http://deb.com: клиенту выводилось содержимое внутреннего сервера http://inserv:80 как это можно реализовать? openvpn (если действительно нужен туннель) squid (если нужно на 1 реальный IP посадить несколько "спрятанных" серверов. правда, потребуется махинация с DNS-сервером) Зачем городить огород из openvpn и squid.. человек спршивает об элементарном пробросе портов средствами того же iptables. Всё. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись " с помощью хэш-функции?
On Fri, Jun 22, 2007 at 03:20:42PM +0400, Max Dmitrichenko wrote: > В сообщении от 22 Июнь 2007 14:28 Иван Лох написал(a): > > On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote: > > Для одноразового ключа и большого количества > > сообщений IMHO хуже. С каждым перехваченным > > сообщением ключ становится все более уязвим. > > Если сообщения открыты -- особенно. > > Ну тут можно генерировать новый ключ на основе старого. > Скажем, через каждые n сообщений. Алгоритм, естественно, > должен быть известен обеим сторонам. Генерировать можно, конечно. Только алгоритм, по-хорошему, должен сводиться к генератору случайных чисел. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
Фигурный subject. Это интересно у меня evo чудит или kmail и так кодировать не положено? -- Alexander Vlasov ZULU-UANIC JID: zulu jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Поведение libc
В сообщении от 21 Июнь 2007 18:50 Max Dmitrichenko написал(a): > > Если её скомпилировать и слиноковать динамически с libc и librt, то все > работает. > Если же это делать статически, то timer_create возвращает EINVAL, при этом, > если > заменить CLOCK_MONOTONIC на CLOCK_REALTIME, то все опять работает. То есть > статическая > версия libc почему-то не хочет создавать таймер, привязанный к > CLOCK_MONOTONIC, > однако clock_getres работает для обоих типов линковки и с CLOCK_MONOTONIC, и > с CLOCK_REALTIME. > > Проверено и в sarge, и в ethc. Кто-нибудь скажет, чем обусловлено такое > поведение? Пытаюсь уже сам понять, ковыряясь в исходниках glibc. Только там как минимум две реализации функции timer_create: 1) nptl/sysdeps/pthread/timer_create.c 2) nptl/sysdeps/unix/sysv/linux/timer_create.c Как понять которая из них используется? Тут есть вообще кто-нибудь, кто эти таймеры использовал? -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
Fri, 22 Jun 2007 10:49:58 +0400, Ed <[EMAIL PROTECTED]>:
> схема:
> отправитель - небезопасный канал (интернет) - получатель
>
> я контролирую и отправителя и получателя.
>
> данные несекретные, шифровать их особого смысла нет. но получатель
> должен убедиться, что данные отправил действительно отправитель.
> чем плохо поступить так - заранее сгенерировать ключ (просто
> последовательность байт), далее приписываем этот ключ к сообщению и
> генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение
> + хэш - зная ключ мы легко можем проверить подлинность сообщения.
Как я понимаю, у Вас есть надёжный способ передать секретный ключ
получателю и обеспечить его секретность.
В этом случае вообще можно наладить полностью секретный
канал между отправителем и получателем средствами симметричного
шифрования, и считать всё, полученное по этому каналу, «надёжным».
Необходимость в "подписях" в этом случае отпадает.
Как и в Вашем предложении, использовать такую систему для подтверждения
авторства ("цифровой подписи") -- невозможно, так как ключ подписи
известен как минимум двум сторонам, и подписывать могут обе.
Отвечу на вопрос, почему плохо поступить так, как предлагаете Вы:
1) функции цифровой подписи такая система не выполняет, см. выше;
2) созданный Вами лично алгоритм защиты не пройдёт должного анализа и
не будет открыто обсуждаться; уязвимости и особенности широко
использованных алгоритмов широко обсуждаются и обычно известны;
практика применения «самодельных» криптосистем показывает их
ненадёжность; опять же, особенности работу разных хэш-функций, могут
сильно влиять на результат.
3) «самодельные» реализации даже известных и проверенных алгоритмов
более подвержены ошибкам и уязвимостям, так как никто не будет
проверять, насколько правильно и осмотрительно вы реализовали алгоритм.
4) зачем изобретать велосипед? выберите любую уже проверенную систему
цифровой подписи, широко используемую библиотеку с её реализацией и
пользуйтесь на здоровье.
Re: чем плоха "подпись " с помощью хэш-функции?
On 2007.06.22 at 10:49:58 +0400, Ed wrote: > > я контролирую и отправителя и получателя. > > данные несекретные, шифровать их особого смысла нет. но получатель > должен убедиться, что данные отправил действительно отправитель. > > чем плохо поступить так - заранее сгенерировать ключ (просто > последовательность байт), далее приписываем этот ключ к сообщению и > генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение > + хэш - зная ключ мы легко можем проверить подлинность сообщения. Это частный случай MAC - message authentication code. Реально используемые MAC-и практически всегда базируются именно на хэшах. Называется HMAC. Рекомендую ознакомиться с описанием алгоритма HMAC, там сделано чуточку похитрее, чем просто дописывание ключа к сообщению. И в rfc2104 слегка объясняется почему делается именно так. Причем HMAC настолько распространен, что многие разработчики криптографического софта вообще не в курсе, что бывают MAC-алгоритмы, базирующиеся не на хэш-функции, например ГОСТ 28147-89 в режиме имитовставки. > из минусов пока вижу только необходимость безопасно доставить ключ на > обе стороны - но в данном случае это проблемы не представляет. Это во многих случаях проблем не представляет. Например, в протоколе TLS(SSL) где каждая запись защищается MAC-ом всё равно вырабатывается общий секрет для шифрования. Поэтому ничто не мешает нагенерить секрета побольше, и использовать его часть для MAC. Еще MAC-ом очень часто защищаются шифрованные сообщения. Потому что нужен какой-то способ убедиться в корректности расшифрования. Соответственно, считаем MAC на симметричном ключе шифрования и дописываем к сообщению. Если при расшифрвании использован правильный ключ, MAC посчитанный на нем после расшифрования совпадет. > а с точки зрения криптостойкости - хуже этот вариант обычной подписи Тем что секрет знают двое. Поэтому не обладает свойством неотрекаемости. Т.е. получатель сообщения не может предъявить третьему лицу (судье) это сообщение и утверждать, что подписал его именно отправитель. Ведь у него самого была полная возможность это сообщение сгенерировать. > (afaik формируем хэш и шифруем его)? Это - не совсем верно. Шифруют хэш только в алгоритме RSA. В алгоритмах на базе схемы Эль-Гамаля (DSA, ECDSA, ГОСТ Р 34.10) происходит не (обратимое) шифрование. Там делается необратимое преобразование исходного сообщения (т.е. хэша), да ешё и с подмешиванием случайного числа. Просто существует такая последовательность арифметических операций, которая позволяет убедиться что данный хэш соответствует данной подписи. А вот имея только подпись и открытый ключ, узнать хэш исходного сообщения нельзя. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпис ь" с помощью хэш-функ ции?
Victor Wagner wrote: чем плохо поступить так - заранее сгенерировать ключ (просто последовательность байт), далее приписываем этот ключ к сообщению и генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение + хэш - зная ключ мы легко можем проверить подлинность сообщения. Это частный случай MAC - message authentication code. Реально используемые MAC-и практически всегда базируются именно на хэшах. Называется HMAC. Рекомендую ознакомиться с описанием алгоритма HMAC, там сделано чуточку похитрее, чем просто дописывание ключа к сообщению. И в rfc2104 слегка объясняется почему делается именно так. хорошо, ничего против HMAC не имею - по сложности реализации оно не отличается. а с точки зрения криптостойкости - хуже этот вариант обычной подписи Тем что секрет знают двое. Поэтому не обладает свойством неотрекаемости. Т.е. получатель сообщения не может предъявить третьему лицу (судье) это сообщение и утверждать, что подписал его именно отправитель. Ведь у него самого была полная возможность это сообщение сгенерировать. меня вполне устраивает то, что никто кроме этих двух не мог сгенерировать это сообщение подводя итог - HMAC хороший выбор? или смотреть на что-то другое? на что тогда? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: тунель для Apache
Если действительно с deb.com не видно inserv, который непонятно в какой локалной сети, то лучше всего из inserv (клиент) установить именно openvpn соединение с deb.com и получить локальный ip адрес из сети сервера (192...). На deb.com сделать туннель в iptables deb.com:-192.168.xx.xx Стоит не забыть дать статический внутренний ip адрес (192..) клиенту используя ccd (push) директиву openvpn. авторизацию для openvpn удобнее всего сделать на x509 Как это сделать очень популярно объясненно на opennet.ru -- Best regards, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха "подпись" с помощью хэш-функции?
jetxee wrote: В этом случае вообще можно наладить полностью секретный канал между отправителем и получателем средствами симметричного шифрования, и считать всё, полученное по этому каналу, «надёжным». Необходимость в "подписях" в этом случае отпадает. по размышлению мне этот вариант нравится всё больше. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pppd и cd
Max Dmitrichenko wrote:
В сообщении от 22 Июнь 2007 11:31 Ed написал(a):
Max Dmitrichenko wrote:
если при поднятом ppp-соединении модем ложит cd, то pppd это игнорирует.
как же так? ;)
Есть мнение, что при этом должен закрыться дескриптор того tty-устройства,
через которое работает pppd.
не закрывается. в какую сторону копать?
В сторону ядра. Файл ppp_async.c - для PPP, файл serial_core.c и 8250.c для
того, чтобы смотреть, как влияет состояние линий.
спасибо за подсказку.
с первого взгляда причина нашлась.
в serial_core.h есть:
static inline void
uart_handle_dcd_change(struct uart_port *port, unsigned int status)
{
struct uart_info *info = port->info;
port->icount.dcd++;
#ifdef CONFIG_HARD_PPS
if ((port->flags & UPF_HARDPPS_CD) && status)
hardpps();
#endif
if (info->flags & UIF_CHECK_CD) {
if (status)
wake_up_interruptible(&info->open_wait);
else if (info->tty)
tty_hangup(info->tty);
}
}
8250.c дергает эту функцию.
у меня же используется ftdi_sio, там ничего похожего нет.
на http://ftdi-usb-sio.sourceforge.net/ в todo висит:
Implement hangup (requires a check of the status bytes to see if CD is
dropped and if the line is currently not in CLOCAL send a hangup)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
freeradius как заставить работать hints?
Не получается заставить работать hints. Пользователь прописан в users, ".test" прописан в hints. user - работает,user.test - нет. В логах ничего вразумительного, кроме записи о том что пользователь user провалил аутентификацию. Врубил auth_log - запись выглядит вполне нормально, имя пользователя без суффикса, HINT указан, но - болт. /etc/freeradius/users user Auth-Type := MS-CHAP, User-Password == "testuser" Service-Type = Framed-User, Framed-Protocol = PPP, Fall-Through = Yes DEFAULT Auth-Type = System Fall-Through = Yes DEFAULT Hint == "TEST" Framed-IP-Address = 192.168.91.2+ DEFAULT Service-Type == Framed-User Framed-IP-Address = 255.255.255.254, Framed-MTU = 576, Service-Type = Framed-User, Acct-Interim-Interval = 60, Fall-Through = Yes DEFAULT Framed-Protocol == PPP Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP /etc/freeradius/hints DEFAULT Suffix == ".test", Strip-User-Name = Yes Hint = "TEST" Соответствено при заходе под user: radius.log: Tue Jun 12 03:22:27 2007 : Auth: Login OK: [user/] (from client localhost port 0 cli .291) auth-detail-...: Packet-Type = Access-Request Tue Jun 12 03:32:27 2007 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "user" MS-CHAP-Challenge = 0xb1eec7594d6e6ec6abfcf6f6c3a4bf28 MS-CHAP2-Response = 0xe600dca67e041daecb171bc908e5aa4cb55a2b37b4717ad8ad5b729de49d709b910c7762ab9bcb130149 Calling-Station-Id = ".291" NAS-IP-Address = 192.168.0.1 NAS-Port = 0 Client-IP-Address = 127.0.0.1 reply-detail-...: Packet-Type = Access-Accept Tue Jun 12 03:32:27 2007 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Acct-Interim-Interval = 60 Framed-Compression = Van-Jacobson-TCP-IP MS-CHAP2-Success = 0xe6533d43443231344533363137413743353143323338434232343143374430313936463634434143364434 MS-MPPE-Recv-Key = 0xb6a7a42b4ae4207035fe1cde9295dc83 MS-MPPE-Send-Key = 0x0282cb29ec4a7456afe2a7acb97ff81d MS-MPPE-Encryption-Policy = 0x0002 MS-MPPE-Encryption-Types = 0x0004 Соединение нормально устанавливается. При заходе под user.test: Tue Jun 12 03:49:15 2007 : Auth: Login incorrect: [user/] (from client localhost port 0 cli .291) auth-detail-...: Packet-Type = Access-Request Tue Jun 12 03:49:15 2007 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "user" MS-CHAP-Challenge = 0x67844f7ba63a59f2d2b539e21def95b9 MS-CHAP2-Response = 0xb700b9aff6f09b4a134dc0757200c16c378a3cddaaffb838fde5a3aa4ce1b3eb764c78414f02fc2f3f2c Calling-Station-Id = ".291" NAS-IP-Address = 192.168.0.1 NAS-Port = 0 Client-IP-Address = 127.0.0.1 Hint = "TEST" reply-detail-: Пусто Если завести пользователя как: user Auth-Type := MS-CHAP, User-Password == "testuser" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 192.168.91.2+, Fall-Through = Yes То IP при заходе под user соединение устанавливается и IP нормально отдаётся из требуемого диапазона Что делать? -- С наилучшими, Кирилл Шаталаев. begin:vcard fn;quoted-printable:=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =D0=A8=D0=B0=D1=82=D0=B0=D0=BB=D0=B0= =D0=B5=D0=B2 n;quoted-printable;quoted-printable:=D0=A8=D0=B0=D1=82=D0=B0=D0=BB=D0=B0=D0=B5=D0=B2;=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard
freeradius как заставить работать hints?
Не получается заставить работать hints. Пользователь прописан в users, ".test" прописан в hints. user - работает,user.test - нет. В логах ничего вразумительного, кроме записи о том что пользователь user провалил аутентификацию. Врубил auth_log - запись выглядит вполне нормально, имя пользователя без суффикса, HINT указан, но - болт. /etc/freeradius/users user Auth-Type := MS-CHAP, User-Password == "testuser" Service-Type = Framed-User, Framed-Protocol = PPP, Fall-Through = Yes DEFAULT Auth-Type = System Fall-Through = Yes DEFAULT Hint == "TEST" Framed-IP-Address = 192.168.91.2+ DEFAULT Service-Type == Framed-User Framed-IP-Address = 255.255.255.254, Framed-MTU = 576, Service-Type = Framed-User, Acct-Interim-Interval = 60, Fall-Through = Yes DEFAULT Framed-Protocol == PPP Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP /etc/freeradius/hints DEFAULT Suffix == ".test", Strip-User-Name = Yes Hint = "TEST" Соответствено при заходе под user: radius.log: Tue Jun 12 03:22:27 2007 : Auth: Login OK: [user/] (from client localhost port 0 cli .291) auth-detail-...: Packet-Type = Access-Request Tue Jun 12 03:32:27 2007 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "user" MS-CHAP-Challenge = 0xb1eec7594d6e6ec6abfcf6f6c3a4bf28 MS-CHAP2-Response = 0xe600dca67e041daecb171bc908e5aa4cb55a2b37b4717ad8ad5b729de49d709b910c7762ab9bcb130149 Calling-Station-Id = ".291" NAS-IP-Address = 192.168.0.1 NAS-Port = 0 Client-IP-Address = 127.0.0.1 reply-detail-...: Packet-Type = Access-Accept Tue Jun 12 03:32:27 2007 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Acct-Interim-Interval = 60 Framed-Compression = Van-Jacobson-TCP-IP MS-CHAP2-Success = 0xe6533d43443231344533363137413743353143323338434232343143374430313936463634434143364434 MS-MPPE-Recv-Key = 0xb6a7a42b4ae4207035fe1cde9295dc83 MS-MPPE-Send-Key = 0x0282cb29ec4a7456afe2a7acb97ff81d MS-MPPE-Encryption-Policy = 0x0002 MS-MPPE-Encryption-Types = 0x0004 Соединение нормально устанавливается. При заходе под user.test: Tue Jun 12 03:49:15 2007 : Auth: Login incorrect: [user/] (from client localhost port 0 cli .291) auth-detail-...: Packet-Type = Access-Request Tue Jun 12 03:49:15 2007 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "user" MS-CHAP-Challenge = 0x67844f7ba63a59f2d2b539e21def95b9 MS-CHAP2-Response = 0xb700b9aff6f09b4a134dc0757200c16c378a3cddaaffb838fde5a3aa4ce1b3eb764c78414f02fc2f3f2c Calling-Station-Id = ".291" NAS-IP-Address = 192.168.0.1 NAS-Port = 0 Client-IP-Address = 127.0.0.1 Hint = "TEST" reply-detail-: Пусто Если завести пользователя как: user Auth-Type := MS-CHAP, User-Password == "testuser" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 192.168.91.2+, Fall-Through = Yes То IP при заходе под user соединение устанавливается и IP нормально отдаётся из требуемого диапазона Что делать? -- С наилучшими, Кирилл Шаталаев. begin:vcard fn;quoted-printable:=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =D0=A8=D0=B0=D1=82=D0=B0=D0=BB=D0=B0= =D0=B5=D0=B2 n;quoted-printable;quoted-printable:=D0=A8=D0=B0=D1=82=D0=B0=D0=BB=D0=B0=D0=B5=D0=B2;=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard
Re: посмотреть настро йки роутера
Max Dmitrichenko wrote: Может иногда он и говорит, но только по каком-нибудь протоколу а-ля RSVP. Посмотрел протокол RSVP - он вроде для мультимедии - непонятно как может помочь в данном случае. Вопрос остался: как посмотреть у вышестоящего роутера свои настройки - какой канал дали. -- Best regards, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Простенький редактор для mpeg2
Kadirov Murat Damirovich wrote: Nicholas wrote: http://www.linux.unn.ru/debian/node/62 MPGTX: Редактирование MPEG видео без потери качества Не Вы ли являетесь автором статьи? Если вы меня спрашиваете - то нет. Автора на сайте можно посмотреть, вообще сайт не самый плохой - каждую неделю оригинальная статья про одну програму из дистрибьютива Дебиан: http://www.linux.unn.ru/debian/taxonomy/term/4/0 -- Best regards, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Простенький редактор для mpeg2
Nicholas wrote: Oleg Sheremetinsky wrote: Посоветуйте, пожалуйста, простенький редактор для mpeg2 http://www.linux.unn.ru/debian/node/62 MPGTX: Редактирование MPEG видео без потери качества Не Вы ли являетесь автором статьи? Если так, то хотелось бы узнать откуда была взята следующая информация: "Утилита позволяет разрезать и склеивать MPEG видео без операций повторного сжатия. Качество видео и битрейт (а значит и коэффициент сжатия) остаются теми-же что и в исходных данных все время пока вы отрезаете последние 30 секунд от вашего домашнего видео или стыкуете два ролика один за другим" ..что-то я не нашол упоминаний о подобном (сохранении без пережатия/потерь) на сайте утилиты. Не известна ли вам подобная утилита для работы с *mp3 файлами? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
