Re: Strong Encryption for Backup Exec Desktop - Veritas

This is a discussion on Re: Strong Encryption for Backup Exec Desktop - Veritas ; On 9 Oct 2000 04:47:55 -0400, "Siouxie" wrote: > >Hi, >I wrote an application that enables strong encryption for your backups using >Backup Exec Desktop (any version). The encryption/decryption process is transparent. >More information on the encryption method that is ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: Strong Encryption for Backup Exec Desktop

  1. Re: Strong Encryption for Backup Exec Desktop

    On 9 Oct 2000 04:47:55 -0400, "Siouxie" wrote:

    >
    >Hi,
    >I wrote an application that enables strong encryption for your backups using
    >Backup Exec Desktop (any version). The encryption/decryption process is transparent.
    >More information on the encryption method that is used can be found on:
    >http://csrc.nist.gov/encryption/aes/
    >Rijndael, Serpent, and Twofish are implented.
    >Tell me what you think, as I havent received a reply from Veritas yet.


    It's hard to know what to say because we don't have any concrete
    information. Also, I wouldn't trust your program (or anyone else's
    for that matter) for my confidential data until I could be sure that
    there are no trapdoors or flaws in the implementation. That requires
    a product that has been in use for some time and been subjected to
    varius forms of attack.

    There is a long, sorry history of people who claim good security
    because they used the "right algorithm," yet messed up because their
    implementation created opportunities for attacks, e.g. attacks based
    on known data structures (e.g. DOS directories) or a comparison of
    cryptotest and plaintext. Or poor controls on weak keys. Etc., etc.,
    etc. You know the drills.

    So, sounds good. Show us more.

    But seeing that Veritas can't seem to tie their shoelaces correctly, I
    wouldn't expect them to run after you with your add-on.

    Oh, where do you live? In the USA or outside? If you're in the USA,
    you'll be subject to the export laws if y ou try to sell this product
    outside the US. Even posting this on a world-accessible web site
    could get you in legal doo-doo.

    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.

    Phil

  2. Re: Strong Encryption for Backup Exec Desktop


    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).


  3. Re: Strong Encryption for Backup Exec Desktop

    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).



  4. Re: Strong Encryption for Backup Exec Desktop


    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).

    >



  5. Re: Strong Encryption for Backup Exec Desktop

    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).

    >>



+ Reply to Thread