Hi Phil,

I am not exposed to US export restrictions since I live in Germany and every
part of the program was written in Germany as well.

You're right about the problems with potential trapdoors, no matter whether
they are on purpose or because of a flaw in the implementation. Well, I am
thinking of releasing the source code as well, depending on the feedback
I receive from Veritas. The problem is even contacting them, because their
emails seem to have an autoreply, and I am not willing to call long distance
for their customer support (and I am not really sure if some compentent person
would pick up the phone).
I worked hard on the implementation, in fact it took most of the time of
the project. Several people who are also very experienced with cryptology
helped me designing the implentation. Lemme give you a short overview: one
of the selected ciphers (rijndael, twofish, serpent) in cbc-mode; user key
hashed with sha1 to 160bit (there are no "weak" keys for the cipher mentioned
above. Only weekness could be a short or well known password chosen by the
user, for which I at least give the limitation of 10 characters); user key
is used to ncrypt/decrypt the 256bit master key, which is on the first block
of the tape; with the master key, you decrypt a table, also on the first
block, which is used to generate unique Initialization Vectors and Whitening
Values which are needed to properly implent
the CBC mode; The block number of the tape is used as an index to this table.

Well.... assuming that I did not put any trapdoor in my program on purpose,
this implentation is theoratically as well as practically very secure (like
the attack you mentioned known as Known-Plaintext-Attack, or other attacks
like Differential Cryptoanalysis have no chance with this implentation).
Btw, when
you choose a password for your tape in backupexec, that password is written
in clear text(!) in the first blocks of your tape. So much about security...

> So, sounds good. Show us more.

As soon as I hear from Veritas....(when will that be I wonder)

> One final thought. If I run your program and something
> doesn't work with my BE, Veritas won't support me if I'm using > your vxd
or dll.

That is correct. Fortunatly, you can test your drive first without my encryption.
Hey, it can be turned on/off with a simple button! From a programming point
of few, I can see where there might be problems...and I did everything to
prevent any potential problems in future (i.e. I didn't use anything that
could be version-specific).

Will this work for both Backup Exec Desktop Pro 4.5 and Backup Exec
8.5 (Server)?

Veritas decided to use two different encryption schemes so password
protected backups from one version cannot be used to restore files
using the other version.

Stu


"siouxie" wrote:

>
>Hi Phil,
>
>I am not exposed to US export restrictions since I live in Germany and every
>part of the program was written in Germany as well.
>
>You're right about the problems with potential trapdoors, no matter whether
>they are on purpose or because of a flaw in the implementation. Well, I am
>thinking of releasing the source code as well, depending on the feedback
>I receive from Veritas. The problem is even contacting them, because their
>emails seem to have an autoreply, and I am not willing to call long distance
>for their customer support (and I am not really sure if some compentent person
>would pick up the phone).
>I worked hard on the implementation, in fact it took most of the time of
>the project. Several people who are also very experienced with cryptology
>helped me designing the implentation. Lemme give you a short overview: one
>of the selected ciphers (rijndael, twofish, serpent) in cbc-mode; user key
>hashed with sha1 to 160bit (there are no "weak" keys for the cipher mentioned
>above. Only weekness could be a short or well known password chosen by the
>user, for which I at least give the limitation of 10 characters); user key
>is used to ncrypt/decrypt the 256bit master key, which is on the first block
>of the tape; with the master key, you decrypt a table, also on the first
>block, which is used to generate unique Initialization Vectors and Whitening
>Values which are needed to properly implent
>the CBC mode; The block number of the tape is used as an index to this table.
>
>Well.... assuming that I did not put any trapdoor in my program on purpose,
>this implentation is theoratically as well as practically very secure (like
>the attack you mentioned known as Known-Plaintext-Attack, or other attacks
>like Differential Cryptoanalysis have no chance with this implentation).
>Btw, when
>you choose a password for your tape in backupexec, that password is written
>in clear text(!) in the first blocks of your tape. So much about security...
>
>> So, sounds good. Show us more.
>
>As soon as I hear from Veritas....(when will that be I wonder)
>
>> One final thought. If I run your program and something
>> doesn't work with my BE, Veritas won't support me if I'm using > your vxd
>or dll.
>
>That is correct. Fortunatly, you can test your drive first without my encryption.
>Hey, it can be turned on/off with a simple button! From a programming point
>of few, I can see where there might be problems...and I did everything to
>prevent any potential problems in future (i.e. I didn't use anything that
>could be version-specific).

No, it won't work because BE Pro 4.5 uses different drivers to access your
tape than BE 8.5 Server. They also uses a different tape standard to format
the tape (hence aren't fully compatible).
Btw, there is NO encryption involved when using BE Pro 4.5 with password
option. The password is simply in the volume table stored in cleartext (Plaintext).
I wrote a util that extracts this password for you (and anyone else who has
your tape) to show the danger of trusting in an insecure password.

Greets

Stewart Berman wrote:
>Will this work for both Backup Exec Desktop Pro 4.5 and Backup Exec
>8.5 (Server)?
>
>Veritas decided to use two different encryption schemes so password
>protected backups from one version cannot be used to restore files
>using the other version.
>
>Stu
>
>
>"siouxie" wrote:
>
>>
>>Hi Phil,
>>
>>I am not exposed to US export restrictions since I live in Germany and
every
>>part of the program was written in Germany as well.
>>
>>You're right about the problems with potential trapdoors, no matter whether
>>they are on purpose or because of a flaw in the implementation. Well, I
am
>>thinking of releasing the source code as well, depending on the feedback
>>I receive from Veritas. The problem is even contacting them, because their
>>emails seem to have an autoreply, and I am not willing to call long distance
>>for their customer support (and I am not really sure if some compentent
person
>>would pick up the phone).
>>I worked hard on the implementation, in fact it took most of the time of
>>the project. Several people who are also very experienced with cryptology
>>helped me designing the implentation. Lemme give you a short overview:
one
>>of the selected ciphers (rijndael, twofish, serpent) in cbc-mode; user
key
>>hashed with sha1 to 160bit (there are no "weak" keys for the cipher mentioned
>>above. Only weekness could be a short or well known password chosen by
the
>>user, for which I at least give the limitation of 10 characters); user
key
>>is used to ncrypt/decrypt the 256bit master key, which is on the first
block
>>of the tape; with the master key, you decrypt a table, also on the first
>>block, which is used to generate unique Initialization Vectors and Whitening
>>Values which are needed to properly implent
>>the CBC mode; The block number of the tape is used as an index to this
table.
>>
>>Well.... assuming that I did not put any trapdoor in my program on purpose,
>>this implentation is theoratically as well as practically very secure (like
>>the attack you mentioned known as Known-Plaintext-Attack, or other attacks
>>like Differential Cryptoanalysis have no chance with this implentation).
>>Btw, when
>>you choose a password for your tape in backupexec, that password is written
>>in clear text(!) in the first blocks of your tape. So much about security...
>>
>>> So, sounds good. Show us more.
>>
>>As soon as I hear from Veritas....(when will that be I wonder)
>>
>>> One final thought. If I run your program and something
>>> doesn't work with my BE, Veritas won't support me if I'm using > your
vxd
>>or dll.
>>
>>That is correct. Fortunatly, you can test your drive first without my encryption.
>>Hey, it can be turned on/off with a simple button! From a programming point
>>of few, I can see where there might be problems...and I did everything
to
>>prevent any potential problems in future (i.e. I didn't use anything that
>>could be version-specific).
>

It looks like they are trading on the Backup Exec name for their
Desktop versions. They appear to be two completely different products
and the desktop one seems very limited -- a true WIndows 98 type of
product.

It is unfortunate that they do not offer a workstation version of
Backup Exec 8.5 at a reasonable per unit price. At least that is a
corporate grade product.

Stu

"Siouxie" wrote:

>
>No, it won't work because BE Pro 4.5 uses different drivers to access your
>tape than BE 8.5 Server. They also uses a different tape standard to format
>the tape (hence aren't fully compatible).
>Btw, there is NO encryption involved when using BE Pro 4.5 with password
>option. The password is simply in the volume table stored in cleartext (Plaintext).
>I wrote a util that extracts this password for you (and anyone else who has
>your tape) to show the danger of trusting in an insecure password.
>
>Greets
>
>Stewart Berman wrote:
>>Will this work for both Backup Exec Desktop Pro 4.5 and Backup Exec
>>8.5 (Server)?
>>
>>Veritas decided to use two different encryption schemes so password
>>protected backups from one version cannot be used to restore files
>>using the other version.
>>
>>Stu
>>
>>
>>"siouxie" wrote:
>>
>>>
>>>Hi Phil,
>>>
>>>I am not exposed to US export restrictions since I live in Germany and
>every
>>>part of the program was written in Germany as well.
>>>
>>>You're right about the problems with potential trapdoors, no matter whether
>>>they are on purpose or because of a flaw in the implementation. Well, I
>am
>>>thinking of releasing the source code as well, depending on the feedback
>>>I receive from Veritas. The problem is even contacting them, because their
>>>emails seem to have an autoreply, and I am not willing to call long distance
>>>for their customer support (and I am not really sure if some compentent
>person
>>>would pick up the phone).
>>>I worked hard on the implementation, in fact it took most of the time of
>>>the project. Several people who are also very experienced with cryptology
>>>helped me designing the implentation. Lemme give you a short overview:
>one
>>>of the selected ciphers (rijndael, twofish, serpent) in cbc-mode; user
>key
>>>hashed with sha1 to 160bit (there are no "weak" keys for the cipher mentioned
>>>above. Only weekness could be a short or well known password chosen by
>the
>>>user, for which I at least give the limitation of 10 characters); user
>key
>>>is used to ncrypt/decrypt the 256bit master key, which is on the first
>block
>>>of the tape; with the master key, you decrypt a table, also on the first
>>>block, which is used to generate unique Initialization Vectors and Whitening
>>>Values which are needed to properly implent
>>>the CBC mode; The block number of the tape is used as an index to this
>table.
>>>
>>>Well.... assuming that I did not put any trapdoor in my program on purpose,
>>>this implentation is theoratically as well as practically very secure (like
>>>the attack you mentioned known as Known-Plaintext-Attack, or other attacks
>>>like Differential Cryptoanalysis have no chance with this implentation).
>>>Btw, when
>>>you choose a password for your tape in backupexec, that password is written
>>>in clear text(!) in the first blocks of your tape. So much about security...
>>>
>>>> So, sounds good. Show us more.
>>>
>>>As soon as I hear from Veritas....(when will that be I wonder)
>>>
>>>> One final thought. If I run your program and something
>>>> doesn't work with my BE, Veritas won't support me if I'm using > your
>vxd
>>>or dll.
>>>
>>>That is correct. Fortunatly, you can test your drive first without my encryption.
>>>Hey, it can be turned on/off with a simple button! From a programming point
>>>of few, I can see where there might be problems...and I did everything
>to
>>>prevent any potential problems in future (i.e. I didn't use anything that
>>>could be version-specific).
>>