Cryptography-Digest Digest #834, Volume #12 Wed, 4 Oct 00 05:13:01 EDT
Contents:
Re: Advanced Encryption Standard - winner is Rijndael (SCOTT19U.ZIP_GUY)
Re: Rijndael: making the "flaw" plainer (Mok-Kong Shen)
SHA C++ Implementation ([EMAIL PROTECTED])
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Rich Wales)
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
Verisign questions ("Alfred Geskin")
Re: is NIST just nuts? ([EMAIL PROTECTED])
Re: It's Rijndael (Fred Van Andel)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (jungle)
Re: It's Rijndael (David Schwartz)
Re: Verisign questions (Paul Rubin)
Re: SHA C++ Implementation ("Herbie T. Mac")
Re: Signature size ("Joseph Ashwood")
Re: Shareware Protection Schemes ("Joseph Ashwood")
Re: About implementing big numbers ("Joseph Ashwood")
Re: Choice of public exponent in RSA signatures ("Joseph Ashwood")
Re: Choice of public exponent in RSA signatures (Paul Rubin)
Re: Advanced Encryption Standard - winner is Rijndael (Mok-Kong Shen)
Re: My Theory... (Mok-Kong Shen)
Re: Question about encryption. (Mok-Kong Shen)
Re: Need help: considerations for IV and Keysetup ([EMAIL PROTECTED])
Re: It's Rijndael (Volker Hetzer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: 4 Oct 2000 04:41:12 GMT
[EMAIL PROTECTED] (David Schwartz) wrote in
<[EMAIL PROTECTED]>:
>
>Rick Braddam wrote:
>
>> > I see no evidence that the U.S. government ever reached the
>> > conclusion that Rijndael is not suitable for protecting classified
>> > information.
>> >
>> > Again, can you produce any evidence for this claim?
>> >
>> > DS
>>
>> From the same press release, here's a hint:
>>
>> When approved, the AES will be a public algorithm designed to protect
>> sensitive government information well into the 21st century. It will
>> replace the aging Data Encryption Standard, which NIST adopted in 1977
>> as a Federal Information Processing Standard used by federal agencies
>> to protect sensitive, unclassified information.
>
> This doesn't say that the U.S. has decided that Rijndael is
> unsuitable
>for protecting classified information. In fact, at the time this was
>written, it wasn't even known that the AES was Rijndael.
>
>> From the AES questions and answers page:
>>
>> 1. What is the Advanced Encryption Standard (AES)?
>>
>> The Advanced Encryption Standard (AES) will be a new Federal
>> Information Processing Standard (FIPS) Publication that will specify a
>> cryptographic algorithm for use by U.S. Government organizations to
>> protect sensitive (unclassified) information. NIST also anticipates
>> that the AES will be widely used on a voluntary basis by
>> organizations, institutions, and individuals outside of the U.S.
>> Government - and outside of the United States - in some cases.
>
> This doesn't say or imply that the U.S. has decided that Rijndael
> is
>unsuitable for protecting classified information.
>
>> 19. Who will be required to implement and use the AES?
>>
>> When the AES is published as a FIPS, the algorithm will officially be
>> identified as an approved encryption algorithm that can be used by
>> U.S. Government organizations to protect sensitive (unclassified)
>> information. As is currently the case, those Government organizations
>> will be able to use other FIPS-approved algorithms in addition to, or
>> in lieu of, the AES.
>
> This doesn't say or imply that the U.S. has decided that Rijndael
> is
>unsuitable for protecting classified information.
>
>> Commercial and other non-U.S. Government organizations are invited -
>> but not required - to adopt and implement the AES and NIST's other
>> cryptographic standards.
>>
>> The reference to "protect sensitive (unclassified) information" is
>> repeated in several other documents available at the NIST web site or
>> through its links.
>>
>> Good enough?
>> (Uncle won't specify "unclassified" unless that's exactly what he
>> means)
>
> No, not good enough. I'm sure whatever the government uses to
> protect
>it's most classified data is also suitable for protecting unclassified
>but sensitive data.
>
> For the third time, I ask you if you have any evidence to support
> your
>claim that the U.S. government does not consider Rijndael suitable for
>protecting classified data. I'm become more and more confident that you
>don't.
>
> DS
>
I am not sure what you want as plain as the nose in your head it
says that it is to be used for unclassifed data only. I guess you could
encrypt top secret data brag about it and put it on the net. If the feds
don't knocking on your door than I guess its ok.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Rijndael: making the "flaw" plainer
Date: Wed, 04 Oct 2000 07:20:58 +0200
John Savard wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
> >What do you mean by 'having the Byte Sub in line'? (You
> >have said that 'The Byte Sub step corresponds roughly to the
> >f-function'.) Thanks.
>
> Although the Byte Sub performs the same function as the f-function, it
> does so in a different way. The f-function in DES acts on a copy of
> one half of the block, and the result is only used to XOR with the
> other half of the block.
>
> On the other hand, the Byte Sub substitution actually changes the
> bytes themselves as they move from plaintext to ciphertext. Like the
> S-boxes in SAFER.
>
> So instead of being "at right angles" to the line from a plaintext
> byte to the same byte in the ciphertext, they are in the path of that
> line.
On the other hand this Byte Sub is a constant substitution,
while with the Feistel ciphers one uses one half to
control the substitution of the other part and with two
rounds the whole gets modified. I don't yet see why do
you feel that Byte Sub is more 'complicated' or 'stronger'
in some sense. Or am I misunderstanding you?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: SHA C++ Implementation
Date: Wed, 04 Oct 2000 04:57:38 GMT
Hi. I was wanting to know if there is any source
code for C++ that implements SHA(Secure Hash
Algorithm), aka SHS(Secure Hash Standard). I have
found some C implementations, but they do not seem
to work. Could someone please help? Thanks.
-GH
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: 4 Oct 2000 05:10:57 -0000
"jungle" wrote:
> message sig is BAD under v651 ... do you need any future tests?
Thanks. The signature checks out as OK in GnuPG 1.0.3, as well as the
modified PGP 2.6.3ia which I used to create the signature.
PGP 6.5.1 presumably uses RSAREF, which has a hard-coded key length
limit of 2048 bits, so I'm not surprised that 6.5.1 couldn't validate
a signature made with a longer key.
PGP 6.5.1i (the "international", non-RSAREF version) didn't validate
the signature either; when I tried, it said "file is signed, signature
not checked". I assume this version also has a hard-coded key length
limit in its RSA code.
It would be useful to know if the new PGP 7.0 handles long RSA keys.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 22:12:10 -0700
"SCOTT19U.ZIP_GUY" wrote:
> I am not sure what you want as plain as the nose in your head it
> says that it is to be used for unclassifed data only. I guess you could
The "only" is something made up. Find it for me.
> encrypt top secret data brag about it and put it on the net. If the feds
> don't knocking on your door than I guess its ok.
Since most of the evidence presented consists of claims about the AES
before it was even chosen, it can't possibly reflect a specific
conclusion about Rijndael.
If you go out looking for a building material suitable for use in
temperatues below 30 degrees, can you automatically conclude that the
building material is unsuitable for temperatures below zero?
If you make a list of ten building materials all of which are suitable
for use in temperaturse below 30 degrees, can you assume anything about
any of the materials suitability for temperatures below zero?
The English language does not provide a good way to make statements
without making implications. But the implied claims are merely implied,
and you can't treat them the same way. If the NSA says "all the AES
candidates are suitable for level 3" that's what it means. Does it mean
they're unsuitable for level 2? No. Does it mean any of them _are_
suitable for level 2? No. It means they're all suitable for their
intended purpose. No more. No less.
DS
------------------------------
From: "Alfred Geskin" <[EMAIL PROTECTED]>
Subject: Verisign questions
Date: Wed, 04 Oct 2000 05:27:19 GMT
Where can I find out the actual algorithms and key lengths used by verisign?
(I think it is RSA. I assume different classes of certificate might use
different key lengths.)
Oddly enough, they don't seem to make this info clearly available to
purchasers of their products!
-Alfred
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: is NIST just nuts?
Date: Wed, 04 Oct 2000 05:21:42 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>I believe there's some argument that the effective strength was only at
>about the 56-bit level anyway. According to the story, reducing the
>size of the keyspace reflected the properties of the underlying
>algorithm, and didn't really make the system weaker than it already
>was.
I don't think this is a meaningful statement. The key size does put an
upper bound on a cipher's strength, but apart from that, strength is
not a one-dimensional entity, because the cost of breaking a message
can vary a lot depending on the type of attack.
For example, if cipher A can be broken with 2^55 operations using 2^55
known plaintexts, it does not mean that that cipher's strength is "56
bits". 2^55 known plaintexts are impossible to get by in the real
world, so that cipher's strength remains at its upper bound.
Ultimately instead of talking of bits of strength, we should put a
dollar value to any attack we devise, according to a formula we all
agree in principle (this is not an obvious task, for example the cost
of known texts should grow much faster the linear). Using such a
formula, it becomes now possible to define an objective methodology to
compare the strength of ciphers even if none is really broken: Use the
most cost-effective attacks known and start comparing the cost of
breaking one round of each cipher, two rounds, three rounds, etc, until
the cost becomes too large. Finally compare the ciphers taking into
account not so much the percentage of rounds that can be broken at a
specific cost, but rather the rate at which the cost is growing at each
successive round. That rate will best reflect the structural strength
of the cipher. Maybe that is why Rijndael was chosen even though a
theoretical attack on 7 rounds was found: the cost of attack for each
additional round was growing extremely fast.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Fred Van Andel)
Subject: Re: It's Rijndael
Date: Wed, 04 Oct 2000 05:36:55 GMT
[EMAIL PROTECTED] (John Savard) wrote:
>It *helps* if the computers of the world all use the U.S. designed
>Microsoft Windows operating system, which means that anyone making a
>compiler that produces programs that run on it has to license
>"windows.h" from Microsoft (if not the Microsoft Foundation Classes as
>well, which nearly every compiler maker would also do) and therefore
>is compelled - regardless of which country they are located in,
>although I'm not aware of too many non-U.S. compilers for Windows - to
>include in their license agreements a clause requiring foreign users
>of the compiler not to do anything with it that might constitute a
>violation of U.S. export laws.
>
>So if you write and compile an encryption program outside the U.S. and
>Canada, you're committing software piracy!
>
But can you imagine Microsoft trying to sue a European company in a
Eoropean court for breaking an American export law. Said court will
take great pleasure in telling Microsoft where to stick it.
FVA
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Wed, 04 Oct 2000 01:38:32 -0400
attempt to import file made with your key [ richw.asc ] to v262 resulted in :
PGP did not find any key at this file ...
Rich Wales wrote:
>
> "jungle" wrote:
>
> > message sig is BAD under v651 ... do you need any future tests?
>
> Thanks. The signature checks out as OK in GnuPG 1.0.3, as well as the
> modified PGP 2.6.3ia which I used to create the signature.
>
> PGP 6.5.1 presumably uses RSAREF, which has a hard-coded key length
> limit of 2048 bits, so I'm not surprised that 6.5.1 couldn't validate
> a signature made with a longer key.
>
> PGP 6.5.1i (the "international", non-RSAREF version) didn't validate
> the signature either; when I tried, it said "file is signed, signature
> not checked". I assume this version also has a hard-coded key length
> limit in its RSA code.
>
> It would be useful to know if the new PGP 7.0 handles long RSA keys.
>
> Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
> PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
> RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 23:08:50 -0700
Fred Van Andel wrote:
> But can you imagine Microsoft trying to sue a European company in a
> Eoropean court for breaking an American export law. Said court will
> take great pleasure in telling Microsoft where to stick it.
It wouldn't be for violating an American export law, it would be for
violating an international license agreement. I think you would be quite
surprised how enthusiastic they'd be about defending intellectual
property rights and licensing agreements.
DS
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Verisign questions
Date: 03 Oct 2000 23:56:23 -0700
"Alfred Geskin" <[EMAIL PROTECTED]> writes:
> Where can I find out the actual algorithms and key lengths used by verisign?
> (I think it is RSA. I assume different classes of certificate might use
> different key lengths.)
>
> Oddly enough, they don't seem to make this info clearly available to
> purchasers of their products!
The key length is chosen by the customer, not by Verisign. These days
1024 bits is most common. Most browsers don't support keys longer
than 1024 bits. I don't know if Verisign can/will sign certificates
with keys longer than 1024 bits. A few people do choose to use
shorter keys (e.g. 512 or 768 bits), but there's generally no good
reason these days to do that.
------------------------------
From: "Herbie T. Mac" <[EMAIL PROTECTED]>
Subject: Re: SHA C++ Implementation
Reply-To: [EMAIL PROTECTED]
Date: Wed, 04 Oct 2000 02:07:10 -0500
Check out Wei Dai's outstanding CryptoPP package at
http://www.eskimo.com/~weidai/cryptlib.html.
The code is not for the faint of heart but it is well-written and
complete.
herbie
In article <8redc0$52l$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Hi. I was wanting to know if there is any source code for C++ that
> implements SHA(Secure Hash Algorithm), aka SHS(Secure Hash Standard). I
> have found some C implementations, but they do not seem to work. Could
> someone please help? Thanks.
>
> -GH
> [EMAIL PROTECTED]
>
>
> Sent via Deja.com http://www.deja.com/ Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Signature size
Date: Sun, 1 Oct 2000 22:52:48 -0500
What is your exact requirement? Would is be acceptable, for
example, to perform a 32-bit CRC of the data, encrypt the
result with a secret shared Blowfish key, and send that? the
result would be a 64-bit message where as long as the
Blowfish key remains secret will be strong (altering the
encrypted block will void the CRC with high probability). If
you have a long series of instructions, would it be
acceptable to perform a commit-like operation after some
1000+ instructions? that would let you use ECDSA, DSA, or
RSA signatures without the several hundred % inflation.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Shareware Protection Schemes
Date: Sun, 1 Oct 2000 22:48:10 -0500
> > - Who is the "protection" targeted at? The honest people
or do
> > you seriously belive that copy protection will work
against
> > everyone?
> I would be trying to prevent crackers/keygens from coming
out. I know that
> Deerfield had pretty successfully used RSA for their key
scheme.
Not gonna work, EVER. It's a steganographic problem, once
the attacker knows of it's presence(which will be obvious),
and has a working example of how to verify it (which you
will gladly supply for the cost of 1 license), the attacker
can undo it, regardless of what you do.
> > - What would stop a cracker from killing your key
validation
> > code in the software?
> Hash of the exe and dll's. Compressing the .exe to make
reverse engineering
> a good bit harder.
Which of course the attacker will take care of at the same
time.
> > - HOW will you validate the purchaser?
> Suggestions needed....like i stated, this is my first time
dealing with this
> situation.
Just take cash, at least you're less likely to get taken on
that front
> > - What would stop anyone from distributing the software
WITH
> > a (stolen or compromised) legitemate key?
> THAT I haven't got worked out yet. Mostly what i'm
concerned about right
> now is preventing serial number posting or the creation of
key generators.
> Hoping for suggestions on this one.
Assuming it's an x86 target platform, hash the CPU id send
have the user send that to you, hash it with your secret
key, and send it back.
It's not perfect and it's easily broken (simply disable the
call to check it).
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: About implementing big numbers
Date: Sun, 1 Oct 2000 23:00:57 -0500
> I would like to know if there is information on the web on
implementing in
> C big numbers, such as the ones used in RSA. Is it
difficult ?
Getting one that works is fairly easy. Just use the methods
most of us learned in grade school. Making it fast can be
exceedingly difficult. I recommend you use Miracl, or if you
want something free (but with various restrictions) the
BIGNUM stuff from openssl. There's also a bignum package
specifically under GPL.
> Would it be better and not too difficult to implement them
myself?
>From an understanding point of view, yes it would be better
to implement it yourself. Realistically though, I know how
to perform the big number math in a way that works, but
there is no reason for me to even consider taking the time
to write, debug, verify, QA, etc a bignum package when there
are so many exceptional ones cheaply available.
>
> I plan to do this under Linux, but I'll maybe port the
software on
> Windows.
Both my recommendations should work flawlessly on fairly
well anything you want to work on.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Sun, 1 Oct 2000 23:14:59 -0500
Well my personal view on it is that n-prime RSA can be no
stronger than 2-prime RSA, and against certain factoring
methods will be substantially weaker. I am personally
against n-prime RSA for the most part. There are of course
situations for it (places where security is not as important
as performance).
I can see where there would be standard support for n-prime
RSA, simply because it makes no difference to non-n-prime
systems (the math is the same).
On an associated note, how is the performance increased in
asymptotic terms? I am curious because as many have read I
am involved in a system where the factoring of the modulud
is of little import making it fairly safe for us to keep the
factorization no matter how many factors there are.
Joe
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: 04 Oct 2000 01:26:22 -0700
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> Well my personal view on it is that n-prime RSA can be no
> stronger than 2-prime RSA, and against certain factoring
> methods will be substantially weaker.
Why should anyone care what your personal views are if you don't have
any mathematical evidence for them?
> On an associated note, how is the performance increased in
> asymptotic terms? I am curious because as many have read I am
> involved in a system where the factoring of the modulud is of little
> import making it fairly safe for us to keep the factorization no
> matter how many factors there are.
A b-bit general modexp takes O(b**3) operations, if that's what you're
asking. And decryption mod N when you know N's secret factors means
doing one b-bit modexp for each b-bit factor, plus a CRT recombination
that's asymptotically dominated by the modexps.
Example: for a 4b-bit modulus with two 2b-bit factors, decryption
takes roughly [some constant c] * 2 * (2b)**3 = 16*b**3 operations,
while with four b-bit factors it would take c * 4 * b**3 operations
which is 4x faster.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Wed, 04 Oct 2000 10:47:51 +0200
David Schwartz worte:
>
> "SCOTT19U.ZIP_GUY" wrote:
[snip]
> and you can't treat them the same way. If the NSA says "all the AES
> candidates are suitable for level 3" that's what it means. Does it mean
> they're unsuitable for level 2? No. Does it mean any of them _are_
> suitable for level 2? No. It means they're all suitable for their
> intended purpose. No more. No less.
Impeccable logically, indeed. There are however always
people who want to read out of given texts something
that the authors have never dreamed of. The lawyers
earn their living partly because of that.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Wed, 04 Oct 2000 10:48:00 +0200
John Savard wrote:
>
> [EMAIL PROTECTED] (Thomas Pornin) wrote,
>
> >The AES contest showed that the community knows how to design secure
> >ciphers, we had 15 of them; the choice is merely marketing: the point
> >of a standard is that people use it, so the winner had to be the most
> >popular. Hence Rijndael.
>
> One or two of the 15 initial applicants were less than secure, I had
> thought. However, given the criterion for a 'break' is merely an
> attack faster than brute force - and a cipher with 2^96 complexity for
> the best attack is still "secure" by any practical standard - perhaps
> that is true.
That's probably the thought behind placing more weight
on speed and size as selection criteria. In other words,
the winner gains substaintially through better art
in economizing processing time and memory.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Question about encryption.
Date: Wed, 04 Oct 2000 10:48:06 +0200
John Savard wrote:
>
> Apparently, this is a publicity campaign for a novel.
>
> ANEC is a cipher algorithm that apparently includes everything but the
> kitchen sink: "hieroglyphic cipher base charts" and the "clairvoyance
> of recursive computational processes", whatever that might be, are
> involved.
>
> It's a pity that ANEC isn't real: I would have loved to see an
> algorithm that was even more bizarre and complicated than Quadibloc
> VIII MR7.
Let hieroglyphs be the input alphabet of your program
and let it output, say, old assyrian characters. Further
utilize the signals of extracelestial beings via the
SETI project as random bit sources and do some quantum
computation and you have a system that at least merits
a TV show.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Need help: considerations for IV and Keysetup
Date: Wed, 04 Oct 2000 08:40:52 GMT
To generate CBC IV values, Scramdisk uses 1024 random bytes stored in
the first 2 sectors of its volume. Hence, Scramdisk DOES require an
extra storage. With these 2 sectors and the current sector number of
the sector being encrypted, Scramdisk then produces a 128bit CBC IV
value.
Scramdisk also uses those 2 sectors as whitening value for the actual
encryption. John, is that what you mean by doing "extra work on the
whole block?" Yes, I have the whole block at hand. Could you give me
some hints in regard to this? Can I use the Scramdisk approach given my
design restrictions?
To the question why I encrypt at all: The whole project is some kind of
mental challenge for myself. It is not as much as who might be a
potential enemy of my data, as to what am I theoratically, and
moreover, practically able to do to secure data. Btw, tape backup
applications based on windows do not offer any adequate encryption
features. Many backup programs use the QIC-113 standard to store data.
Here you have the possibility to set a password - a password which is
simply stored as PLAINTEXT in one of the beginning blocks of the tape!
So much for security...
Ok, if necessary, I could lose my restriction that no extra space is
available. Since the first block containing the header of the tape is
of size 0x8000 bytes, and most of that space is according to the QIC-
113 standard unused, I might use that space to store additional
information. Of course 100% compatibility to possible future revisions
of the QIC-113 standard is not guaranteed anymore. Something I could
live with if it is the only way to make sure that IV's are properly
implentend.
I really appreciate your help!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Wed, 04 Oct 2000 11:09:36 +0200
Runu Knips wrote:
>
> David Lesher wrote:
> > Now all the flaming can start, right?
>
> Hmm, actually I'm very surprised about this !
Same for me. My personal ordering was Serpent, Twofish, Rijndael,theRest.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
