Cryptography-Digest Digest #860
Cryptography-Digest Digest #860, Volume #13 Sun, 11 Mar 01 09:13:01 EST
Contents:
Re: OverWrite: best wipe software? (those who know me have no need of my name)
Re: Really simple stream cipher ("Henrick Hellström")
Re: PKI and Non-repudiation practicalities (those who know me have no need of my
name)
Re: The Foolish Dozen or so in This News Group (those who know me have no need of my
name)
Re: The Foolish Dozen or so in This News Group (those who know me have no need of my
name)
Re: Applications of crypto techniques to non-crypto uses (those who know me have no
need of my name)
Re: Encryption software (Bram Labarque)
FIPS 140-2 PRG ("Yoad Lustig")
Re: = FBI easily cracks encryption ...? ("Mxsmanic")
Re: = FBI easily cracks encryption ...? ("Mxsmanic")
Re: = FBI easily cracks encryption ...? ("Mxsmanic")
Re: = FBI easily cracks encryption ...? ("Mxsmanic")
Re: Applications of crypto techniques to non-crypto uses (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
Re: = FBI easily cracks encryption ...? ("Tom St Denis")
Re: OverWrite: best wipe software?
Re: Encryption software ("Henrick Hellström")
Dumb inquiry
Re: Question ("Dragon")
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Sun, 11 Mar 2001 09:54:24 -
wtCq6.10367$[EMAIL PROTECTED] divulged:
"Anthony Stephen Szopa" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I think I have made Ciphile Software's OverWrite Security Utility
Version 1.2 perhaps the best wipe utility available for Windows.
Why do you think that?
i suppose we shouldn't be too hard on anthony. he doesn't know better,
and at times he does appear to learn. the really annoying "wipe" program
is the one that comes with nai's pgp products -- they make the same
ludicrous claims, and likewise barely mention the constraints.
--
okay, have a sig then
--
From: "Henrick Hellström" [EMAIL PROTECTED]
Subject: Re: Really simple stream cipher
Date: Sun, 11 Mar 2001 11:03:45 +0100
"Thomas Wu" [EMAIL PROTECTED] skrev i meddelandet
news:[EMAIL PROTECTED]...
But code in application layers is often written without the assumption
that the format check has security implications. Imagine an FTP daemon
that rejects an unknown command by including the offending command name
in the response; "FOO" results in "FOO: unknown command". Under these
circumstances, it seems possible that an attacker could exploit this
behavior under your model to get chosen ciphertext pairs and use it
to leverage attacks that would not be possible with explicit MACs.
A user-friendly feature at the application level suddenly turns into
a security weakness when these abstraction barriers aren't respected.
I came to think of some other things:
1. No matter how the encryption is arranged, the attacker will always have
partial knowledge of the plain text: All commands are four characters wide
and are separated from the parameter line by a space or tab character, all
replies begin with a three digit decimal number, etc. To prevent cipher text
only attacks or known plain text attacks, a new session key should always be
generated, ECB mode should not be used and the vector should not be reset to
the same value prior to each message within a session.
2. If e.g. a CBC mode cipher is used and the vector is either reset or
chosen by the sender prior to each command, an attacker could easily mount a
copy-and-paste chosen cipher text attack even if a MAC is used. If the
vector is not reset or if it is set in advance by the recipient, then a
denial-of-service attack is possible. In this respect, there is no
difference between e.g. CBC-MAC and an error propagating cipher.
Now, suppose that an error propagating cipher is used without padding the
messages and without vector resets. Then the following seems to be true:
(a) The probability will be higher that random chosen cipher text will
decrypt into intelligble plain text.
(b) The probability that a specific cipher text will decrypt into the same
plain text twice, is equal to the probability that any other random cipher
text will decrypt into that plain text once.
(c) Due to the abscence of padding, an eaves dropper will learn the length
of each message, but:
(d) Due to the abscence of padding and of a MAC, an eaves dropper will be
given less plain text and thereby less information about the key and the
vector.
(e) Due to the error propagation, a chosen cipher text attack might be
mounted at most once each session.
Considering (a)-(e), yes, it would be poss
Cryptography-Digest Digest #860
Cryptography-Digest Digest #860, Volume #12 Fri, 6 Oct 00 22:13:00 EDT
Contents:
Re: Q: does this sound secure? (Thomas Wu)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: NSA quote on AES (Mack)
Re: Storing an Integer on a stream (Joke) ("William A. McKee")
Re: CRC vs. HASH functions (Mack)
Re: NSA quote on AES (Bill Unruh)
Re: one time pad using a pseudo-random number generator (Bill Unruh)
Re: Choice of public exponent in RSA signatures (Bob Silverman)
Re: Rijndael test vectors (Mack)
Re: what is wrapped PCBC? (Mack)
Re: Getting best available security without knowing which cipher to use (Mack)
From: Thomas Wu [EMAIL PROTECTED]
Subject: Re: Q: does this sound secure?
Date: 06 Oct 2000 18:00:50 -0700
"William A. McKee" [EMAIL PROTECTED] writes:
So ... I scrapped my first attempt and use SRP instead. A very nice package
but it took a while to get the config.h right for WIN32. A big "Thank You"
goes to Tom and his team. (To Tom: If your interested in the diff, and there
were a few minor changes to make the code compile "clean" with MS VC++ 6.0,
Certainly - we'll discuss the platform-specific stuff via e-mail.
please email me. Also, I made some changes to the Java to make it 1.2/1.3
compliant.) The problem is that java.security.SecureRandom takes forever the
first time it is called so I replaced it with the good old java.util.Random.
Does this make the SRP weaker? If so, in what way?
Potentially, it may weaken the security if the random values have
insufficient entropy. For example, if the client secret "a" has a
limited number of possible values, an attacker might be able to
guess it from g^a that is sent.
Also, why is SRP safe against password guessing attacks? Seems like it
suffers from the same problem I had originally in my first attempt.
No it doesn't - the first attempt you described allowed an attacker who
eavesdropped on an authentication session to verify guessed passwords
against the exchanged messages. This attack doesn't work against SRP
because of the random secrets generated by the client and server. The
NDSS paper (available from the SRP Web site) explains the protocol in
more detail.
Thanks again,
Will McKee.
[EMAIL PROTECTED]
--
Tom Wu* finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Sat, 07 Oct 2000 03:26:55 +0200
Bryan Olson wrote:
Mok-Kong Shen wrote:
Bryan Olson wrote:
Mok-Kong Shen wrote:
[...]
Now please tell me what if there is no permutation
at all and you have before you the original block cipher
and you use a chosen ciphertext on it. Would that involve
less work or more work than in the case with permutation as
I described? I like to have a definite answer and a tiny
bit explanation for that.
If you think your question is so important, why are you
unwilling to work on it? I think it's nonsense, based on not
studying the issues. How much work is it to break an
unspecified block cipher? Have you even thought about whether
the question is well-formed enough to make sense?
Since you seem to claim that with permutation is poorer
than without (i.e. with the original block cipher) that
clearly would interest me (for the usefulness of the
scheme). Since you are the 'author' of the attack you
conceived, you are the person that can at least give
some useful information, isn't it?
Seem to claim? Give some useful information? I posted
it. It's been right there in front of you.
Why can't you say clearly with one short sentence here
whether my scheme is difficult to handle or easier to
handle than the normal case where the block cipher is
used without permutations? If may be that I am, for
whatever reason (good or bad), not aware of what you
have already said. But what I am requesting is only one
short sentence, and should cause you less effort than
the two lines above, I firmly believe. Why didn't you
do that? But I think I can tell the reason why you have
constantly avoided to give the answer through diverse
maneuvres: Because on the one side (understandbly) you
dislike to admit that it takes more work to crack my
scheme than the normal scheme. But on the other side
you also can't claim the opposite, because that's
impossible, as can be simply explained from 'first
principle', i.e. from a very general point of view. For
the block cipher, when used in the normal way,
Cryptography-Digest Digest #860
Cryptography-Digest Digest #860, Volume #11 Thu, 25 May 00 16:13:00 EDT
Contents:
Re: AES final comment deadline is May 15 ("Brian Gladman")
Re: Short Secure Serial Numbers (Andru Luvisi)
Re: Yet another block cipher: Storin (David A. Wagner)
Re: Yet another block cipher: Storin (Mark Wooding)
Re: HTML encryption (Eric Murray)
Re: RSA/PK Question (DJohn37050)
Anti-Evidence Eliminator messages, have they reached a burn-out point? (EE Support)
Re: pentium timings (lordcow77)
Actually this person faxed me an article of the U.S. commercial espionage in August,
1995 good work Tatu Ylonen ... actually I have tried to provide some intel in the
past ... (Markku J. Saarelainen)
Re: list of prime numbers (Custer)
Re: list of prime numbers (tomstd)
Re: RSA/PK Question (tomstd)
Re: Crypto patentability ("Paul Pires")
From: "Brian Gladman" [EMAIL PROTECTED]
Subject: Re: AES final comment deadline is May 15
Date: Thu, 25 May 2000 18:22:29 +0100
"Kenneth Almquist" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Scott Fluhrer wrote:
For the record, Rinjdael and Serpent in encrypt mode, and Twofish
bidirectionally makes it relatively simple for hardware to do key
scheduling on the fly, making the cost of changing a key zero.
With Serpent the calculation of the end of the key schedule can be
calculated efficiently; it is not necessary to calculate the full
key schedule. This is not mentioned in the Serpent AES submission,
presumably because the designers of Serpent were not aware of it.
My guess is that they were aware of this but did not consider it necessary
to expand on it at the time.
They were certainly aware of this later as I discussed an implementation
(unpublished) I did using this technique with one of them (Ross Anderson).
The cost I found for going to the end of the key schedule directly was about
25% of the cost of running the key schedule itself. But I did not spend much
time optimising this so its quite likely that this figure could be improved
on by quite a bit.
Brian Gladman
--
From: Andru Luvisi [EMAIL PROTECTED]
Subject: Re: Short Secure Serial Numbers
Date: 25 May 2000 10:35:04 -0700
Don't do it. You're just making your user's lives harder. Besides,
why should a user have to tell you who they are in order to use a
program which *they* *paid* *for*?
I made it through 5 years of college getting a math degree *without*
ever buying Mathematica, even though it's what the department used,
because I simply wasn't interested in telling them the size of my
nostrils or what my name is, since it's none of their damn business.
When you first install Mathematica, it has a 30 day time limit. You
have to register it and get a key before you can use it.
Haven't you ever needed to reinstall a program (maybe after a hard
drive crash) and been unable to because you lost your key?
Andru
--
==
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library|-|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==
--
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Yet another block cipher: Storin
Date: 25 May 2000 10:56:52 -0700
In article 8giahk$gvv$[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
Under what circumstances can a 448 bit yield 14 zero subkeys in
Blowfish?
Here the notes I wrote on it at the time.
I haven't re-checked them for accuracy. Let me know if I made some mistake.
The first 384 bits of the key will be chosen to be the first 384 bits of pi.
The key schedule starts by deriving initial subkeys
(they'll happen to be zero in the first 12 rounds, with the choice above)
and encrypting X_0 = 0 (the all-zeros plaintext) to get a result X_1.
The key schedule replaces the first two round subkeys with X_1 and
encrypts X_1 with the new subkeys to get a result X_2, and then repeats.
Our strategy will be to look for a fixed point.
If we can sure ensure that X_1 = 0, we'll have X_2 = X_3 = .. = 0, too.
(Why? Well, replacing the first two round subkeys by X_1 causes no effect,
because they are already zero, and thus encrypting the all-zeros plaintext
gives the same result as before, namely the all-zeros ciphertext.)
And this can be ensured by choosing the last 64 bits of key appropriately.
--
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Yet another block cipher: Storin
Date: 25 May 2000 17:55:49 GMT
Mark Woo
Cryptography-Digest Digest #860
Cryptography-Digest Digest #860, Volume #10 Fri, 7 Jan 00 11:13:01 EST
Contents:
Re: If you're in Australia, the government has the ability to modify y (The King)
Re: is signing a signature with RSA risky? (Pascal Scheffers)
Re: Square root attacks against DSA? (Paulo S. L. M. Barreto)
Re: Square? (Paulo S. L. M. Barreto)
Re: Unsafe Advice in Cryptonomicon (Terje Elde)
Re: MARS (Volker Hetzer)
Re: Wagner et Al. (Guy Macon)
Re: OLD RLE TO NEW BIJECTIVE RLE (John Savard)
Re: Truly random bistream ("Tony T. Warnock")
Date: 7 Jan 2000 08:25:34 -
From: The King [EMAIL PROTECTED]
Subject: Re: If you're in Australia, the government has the ability to modify y
Why does anyone think that a warrant is needed in America
any more? FBI agents walked into a home in central CA
looking for evidence, no warrant, no request to enter,
just brushed the owner aside- looking for evidence of two
militia men's attempt to blow up two huge gas tanks.
So the man who was brushed aside (yes, they just walked
in right in front of him) decided he should leave that
militia after the FBI visit.
This doesn't sound right. Unless there is a warrant, eminent danger,
owner approval, police can't just come in. /If/ they did, they know
that any evidence would be thrown out of court as illegally obtained.
Poppycock. The 4th Amendment has been rent asunder by 20 years worth of
government pecking under the banners of "War on Drugs" "War on Crime"
and the latest boogieman "Domestic Terrorism", just as most of the other
rights we mere citizens are supposed to have. Hell, the law-enforcement
industry even wants to repeal the Miranda decision. Read up on the RICO
and CALEA statutes.
If this did happen, the home owner should sue.
Sure he can sue. But first he must go to court and the court must decided
to *let* him sue. Then he can go to court again to sue. Then he can grind
for years in the court system, spending every last dollar over a period of
years battling the law-enforcement industry with their infinite time money
and manpower, all to be told "Yes the cops were wrong to do that. Sorry."
A citizen should never *never* NEVER allow a LEO onto his property and
especially his home unless presented with a warrant. If a LEO wants to talk
to you, tell him you'll be happy to speak with him at some neutral location
with your attorny present. If you don't have an attorney you'd best get one
right quick!
Steve
--
From: [EMAIL PROTECTED] (Pascal Scheffers)
Subject: Re: is signing a signature with RSA risky?
Date: Fri, 07 Jan 2000 08:33:02 GMT
I don't understand what you mean. You sign a message (not a
signature).
I should re-phrase my question:
Basically, can Alice generate another message and, by modifying her
private exponent, still get the same signature?
Can Alice later generate a signature over m', with another private
key.
m^s_a mod n_a = m'^s_a' mod n_a
What I intend to do in practice is:
Alice has a message for Bob. She signs it.
Alice sends the signature of the message to Trent, who then adds a
timestamp and gives the timestamp and his signature over it back to
alice.
Alice sends the message with her signature and Trents timestamp to
Bob.
--
From: Paulo S. L. M. Barreto [EMAIL PROTECTED]
Subject: Re: Square root attacks against DSA?
Date: 7 Jan 2000 03:17:15 -0800
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
says...
Attack the r value using Pollard rho, which can then be used to discover the
private key from s.
This was my very first idea, but how do you start the attack? Pollard rho
assumes (as do Pollard lambda and Shanks) that you know g^k mod p, but all you
have is (g^k mod p) mod q.
Paulo.
--
From: Paulo S. L. M. Barreto [EMAIL PROTECTED]
Subject: Re: Square?
Date: 7 Jan 2000 03:06:21 -0800
In article 853p87$h7b$[EMAIL PROTECTED], Scott says...
In article [EMAIL PROTECTED],
Paul Crowley [EMAIL PROTECTED] wrote:
[...]
For some applications the smaller block size could be a disadvantage.
Square has a 128-bit blocksize. Rijndael supports blocksizes of 128,
192, and 256 bits.
I haven't looked at Rijndael in detail, but do you mean "keysizes of 128,
192, and 256 bits"? An AES candidate must support those three keysizes,
but need support a block size of only 128 bits.
Yes, he does. Rijndael supports both keysizes and blocksizes of 128, 192, and
256 bits, giving 9 combinations. The number of rounds is size dependent,
however: 10 rounds if both parameters are 128, 12 rounds if the larger of them
is 192, and 14 rounds if the larger of them is 256.
Paulo.
--
From: [EMAIL PROTECTED] (Terje Elde)
Subject: Re: Unsafe Advice in Cryptonomicon
Date: Fri, 07 Jan 2000 11:58:09 GMT
In article [EMAIL PROTECTED], John
Cryptography-Digest Digest #860
Cryptography-Digest Digest #860, Volume #9Fri, 9 Jul 99 22:13:07 EDT Contents: Re: Electronically Exporting crypto source (legally) (Mok-Kong Shen) Re: Possible Extension for Block Ciphers ([EMAIL PROTECTED]) Re: Uncrackable? ([EMAIL PROTECTED]) Re: Electronically Exporting crypto source (legally) (Greg Ofiesh) Re: Electronically Exporting crypto source (legally) (Greg Ofiesh) Re: Stream Cipher != PRNG ([EMAIL PROTECTED]) Re: Electronically Exporting crypto source (legally) (Greg Ofiesh) Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED]) Re: Stream Cipher != PRNG (Nicol So) Re: Uncrackable? (NFN NMI L.) Re: Can Anyone Help Me Crack A Simple Code? (mercury) From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: Electronically Exporting crypto source (legally) Date: Fri, 09 Jul 1999 13:06:47 +0200 Dmitri Alperovitch wrote: I understand that in our society you can be taken to court for no reason whatsoever, but whether you lose or not is a totally different question. Considering that the government is now losing cases where the export rules have clearly been broken (i.e Bernstein case), it would seem to me that they would be more picky in the future about the battles that they choose. Otherwise, they are going to end up in the Supreme Court, a place that they probably want to avoid going to at all costs. Since we don't KNOW for sure, we can only speculate/conjecture what they 'want' (your last sentence). On a previous occassion I put up my personal speculation of why the bureaucrats (not only of one but of several countries) are doing the apparently irrational and illogical things: (1) To have some work items to justify their own payrolls. (2) To avoid strong crypto being used by the honest citizens so that the WWI has an easier job of getting informations in order to be used for secret commercial/industrial purposes. (The criminals can get their strong cryptos more easily than drugs anyway.) (3) To create a myth about crypto among the (unknowledgeable in crpyto) common people for (a) showing off that they are doing a supreme job to take care of the vital interests of the people and (b) generating (unconsciously) in the minds of the common people a 'definition' of what strong crypto (exactly) is, namely that what the authority forbids/restricts with the (indirect) implication that everything else is not strong and should not be used by the people. This last item (b) means (1) the interceptors have a narrower target field to deal with, (2) certain products, i.e. those in the category of being officially forbidden/restricted, will have a wider acceptance (owing to the general 'belief' of their superiority) which may be well inline with certain specifically national economical goals, (3) their will be less incentives generated in the public for supporting RD of new techniques in cryptology, leading to a general slowdown of progress which is obviously favourable from the standpoint of the bureaucrats for the bunch of reasons mentioned above. Well, these are my personal speculations. Speculations are just that, there are no 'proofs'. So please don't flame me too heavily if part or the whole of the above appears to be wrong or nonsense in your eyes. M. K. Shen == M. K. Shen, Postfach 340238, D-80099 Muenchen, Germany (permanent) http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99) (Origin site of WEAK2-EX, WEAK3-EX and WEAK4-EX, three Wassenaar-conform algorithms based on the new paradigm Security through Inefficiency. Containing 2 mathematical problems with rewards totalling US$500.) -- From: [EMAIL PROTECTED] Subject: Re: Possible Extension for Block Ciphers Date: Sat, 10 Jul 1999 00:01:19 GMT In article [EMAIL PROTECTED], Mok-Kong Shen [EMAIL PROTECTED] wrote: I use in my scheme WEAK3-EX, which uses a mixture of stream and block techniques, output of PRNG to influence the encryption of individual blocks. Besides plaintext/ciphertext chaining, I use what I term 'hash chaining', which is a hash value of a block of information bits in its 'intermediate' stage of being processed, i.e. a value that is not directly related to the input or output of a round (each block in WEAK3-EX is processed by a user choosable variable number of rounds). I believe my design has some non-trivail connection to what you suggested. Hmm neato. Basically though I think you are mixing pre-white keys. What I am doing is splitting the larger input into parts. I will look at your site though. You could make a 128-bit PRNG and whiten the input. This would provide a time dependant permutation of the input, then a key dependant permutation. This would greatly hinder the ability to choose inputs into it. Since there would be a dynamic whitening... Tom -- PGP key
