id: Гость   вход   регистрация
текущее время 22:42 28/03/2024
Автор темы: Гость, тема открыта 21/02/2011 21:43 Печать
Категории: софт, truecrypt, bestcrypt, drivecrypt, tor, операционные системы, diskcryptor
http://www.pgpru.com/Форум/ПрактическаяБезопасность/НевидимаяШифрованиеУровняPGPНаФлешке
создать
просмотр
ссылки

Невидимая шифрование уровня PGP на флешке


Здравствуйте!


Подскажите, пожалуйста, PGP-продукт или нечто схожее из криптопрограмм, отвечающее таким характеристикам:


1. Чтобы уже установленная программа не была видна (для органов). То есть они не должны знать сам факт
использования шифрования.
2. Чтобы программа могла работать на флешке автономно (я на ней планирую хранить информацию).
3. Создавала бы на флешке невидимый, замаскированный криптодиск, который нельзя было бы найти.
4. (мб бред) программа находилась бы внутри самого криптоконтейнера.


Спасибо.


 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии
— unknown (16/06/2011 12:01, исправлен 16/06/2011 12:03)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

При смене пароля перешифровывается мастерключ в слоте, а мастер-ключ, шифрующий сам диск не меняется. По смыслу то же, но так точнее.


В ряде случаев — совсем незаметно изменений производительности или надежности.


Обсуждалось. Т.н. antiforensic-алгоритм в LUKS — соль для ключа хранится в "хрупком", растянутом виде. Это не панацея, но позволяет сделать восстановление ключа сложной задачей, если в заголовке просто повреждено несколько битов.

— Гость (08/09/2013 07:27)   <#>
/comment44987:
На примере zsh:
$ let "val = 0x24b7f2 ^ 0x6fc035"
$ echo $val
16#4B77C7
Т.е. 24b7f2 ⊕ 6fc035 = 4B77C7 (mod 16).
Вот в двоичной:
$ print $(( [#2] val = 2#10110010 ^ 2#10011011 ))
2#101001
Т.е. 10110010 ⊕ 10011011 = 101001 (mod 2). Мануалы: [1], [2].

То же самое на bash:
$ let "val = (( 2#10110010 ^ 2#10011011 ))" ; echo $(( 16#$val ))
65
$ let "val = (( 2#10110010 ^ 2#10011011 ))" ; echo $(( 10#$val ))
41
$ let "val = (( 2#10110010 ^ 2#10011011 ))" ; echo $(( 5#$val ))
21
$ let "val = (( 2#10110010 ^ 2#10011011 ))" ; echo $(( 4#$val ))
bash: 4#41: value too great for base (error token is "4#41")
$ let "val = (( 2#10110010 ^ 2#10011011 ))" ; echo $(( 2#$val ))
bash: 2#41: value too great for base (error token is "2#41")
Да, все знают, что bash sucks.

Можно написать скрипт для вычисления XOR двух файлов. Если кому-то не лень, покажите, как это (такой скрипт) короче записать.
— Гость (08/09/2013 07:38)   <#>

Воистину. zsh:
$ print $((500./3+2))
168.66666666666666
bash:
$ print $((500./3+2))
bash: 500./3+2: syntax error: invalid arithmetic operator (error token is "./3+2")
$ print $((500/3+2))
Warning: unknown mime-type for "168" -- using "application/octet-stream"
Error: no such file "168"
:)
— Гость (08/09/2013 11:19)   <#>
Самый простой вариант на C:
void xor_two_files()
{
        FILE* in1 = fopen("file1", "rb");
        FILE* in2 = fopen("file2", "rb");
        FILE* out = fopen("output", "wb");
 
        while ( !feof(in1) && !feof(in2) )
        {
                fputc( fgetc(in1) ^ fgetc(in2), out );
        }
        fclose(out);
        fclose(in2);
        fclose(in1);
}
Если размеры файлов не совпадают, в выходном файле будет лишний байт. Вот пример более аккуратный:
void xor_two_files()
{
        FILE* in1 = fopen("file1", "rb");
        FILE* in2 = fopen("file2", "rb");
        FILE* out = fopen("output", "wb");
 
        for (;;)
        {
                unsigned char c1 = fgetc(in1);
                unsigned char c2 = fgetc(in2);
 
                if ( feof(in1) || feof(in2) ) break;
 
                fputc(c1 ^ c2, out);
        }
        fclose(out);
        fclose(in2);
        fclose(in1);
}
Он с правильным обрезанием: если размеры файлов разные, будет обрезание по меньшему из файлов. Примеры кода платформонезависимы. Код медленный, т.к. ксорит по одному байту, но для небольших файлов и редких специальных случаев (типа тех, что обсуждаются в этом топике) он сойдёт.
— pgprubot (20/07/2015 19:21, исправлен 20/07/2015 19:25)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Не знаю, как в DragonFly, но такое впечатление, что в NetBSD (последний стабильный релиз) dmsetup существует лишь номинально. Если адресовать один из неиспользуемых дисковых разделов (в смысле disklabel'а — например, /dev/wd0k) с помощью dmsetup, то устройство /dev/mapper/DEV_NAME создаётся, но ничего с ним ни сделать. Оно не читается, на нём не нарезать ФС, не покормить им группу томов как физическим томом и т.д. Для чистоты эксперимента надо бы ещё проверить вообще неиспользуемый диск или хотя бы неразмеченное дисковое пространство. В гугле на тему использования dmsetup в NetBSD полнейший тотальный молчок.


Было бы логичным, если б device mapper, как более базовый кирпич для работы с диском (и LVM поверх него) был полностью независим как от DOS'овской системы разбиения дисков, так и BSD'шной (disklabel), но в инструкциях пишут то, что этому противоречит:


17.5. Disklabel each physical volume member of the LVM

The slice must begin at least two sectors after end of disklabel part of disk. On i386 it is sector “63”. Therefore, the “size” value should be “total sectors” minus 2x “sectors”. Edit your disklabel accordingly
#        size   offset    fstype   [fsize bsize   cpg]
d:  4197403       65      4.2BSD                       # (Cyl. 1 - 4020*)

Т.е. если какое-то блочное устройство надо подключить как физический том к VG, это устройство нужно предварительно разметить disklabel'ом и оставить там место для метаданных. Аналогичные требования для объединения блочных устройств через ccd:


The slice must begin at least one cylinder offset from the beginning of the disk/partition to provide space for the special CCD disklabel. The offset should be 1x sectors/cylinder (see following note). Therefore, the “size” value should be “total sectors” minus 1x “sectors/cylinder”. Edit your disklabel accordingly

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


Поидее, если какое-то блочное устройство используется как физический том или группа томов, пространство под метаданные выделяется из самого устройства, а не из дополнительного свободного места на физическом устройстве, где расположен данный физический том или группа томов. То ли всё так и есть, а в инструкциях пишут лишние требования, то ли действительно требования необходимы и вызваны тем, что device mapper был портирован таким вот корявым образом.

На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3