Cryptography-Digest Digest #745
Cryptography-Digest Digest #745, Volume #13 Sun, 25 Feb 01 07:13:01 EST Contents: Re: Super strong crypto (wtshaw) Re: Encrypted Email for Business Documents (Peter Harrison) Re: Life cycle of keys (wtshaw) Re: Am I doing something silly by including my gnupghome with my archive? (Paul Rubin) Re: RSA - public key exponents and plain text. (Stefan Katzenbeisser) Re: Really big numbers in C (Paul Schlyter) Re: Super strong crypto (Mok-Kong Shen) Re: RSA - public key exponents and plain text. (Tony L. Svanstrom) Re: Fractal encryption? (Mok-Kong Shen) From: [EMAIL PROTECTED] (wtshaw) Subject: Re: Super strong crypto Date: Sun, 25 Feb 2001 00:25:21 -0600 In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: From where this amateur sits, differential cryptanalysis is a very powerful tool indeed. What am I missing from where I sit? Those most skilled in using it are unlikely to tell you if a particular new cipher is indeed as resistant to DC as you would like. -- Better to pardon hundreds of guilty people than execute one that is innocent. -- From: [EMAIL PROTECTED] (Peter Harrison) Crossposted-To: alt.sources.crypto,talk.politics.crypto Subject: Re: Encrypted Email for Business Documents Date: Sun, 25 Feb 2001 07:10:48 GMT On Fri, 23 Feb 2001 16:56:58 -0800, "Joseph Ashwood" [EMAIL PROTECTED] wrote: [send to both newsgroups and personal e-mail] I've taken a cursory look at your idea, and there are several areas in which it seems to be lacking. First why this is not a good idea. There is nothing special about business documents as opposed to every other type of document that is already encrypted (much like business documents are) using either PGP or similar technology. If there is a common library for Delphi, Java, C/C++ and Visual Basic that is open source I would certainly like to hear about it. I would be happy to use PGP if there were common implementations in all languages. Because there isn't I face either writing my own technology or implementing PGP by myself. The fact that you do not encrypt the message just the attachments is a distinct disadvantage of your system as opposed to every other system of it's type in general use. Perhaps if I was designing a generic email encryptor you might have a point. However this system is specifically for sending Documents. By binding yourself exclusively to Rijndael (which by the way is NOT officially AES yet, it has merely been tapped as the one that will be renamed AES when the FIPS comes out) is a problem. My reasoning for using just one set of public key and symetric key algorithms is that the users won't be making decisions about what one to use. As long as the algorithms included are secure I don't really see how adding additional algorithms improve security. You fail completely to address how the public keys are stored, what format they are to be in, etc. Just an example of 2 completely incompatible formats are X.509 and PGP. Correct. I havn't nailed everything down yet. This is just a proposal for something I'm writing - not a formal proposal to a standards body. The concept the you have dubbed "signature" this "signature" is far from a real digital signature. I'd suggest you read up on what exactly a digital signature is, and take a look at technology like PSS and DSA before attempting to create your own. Misunderstanding here is my fault - I stated 'public key of the sender' instead 'private key of the sender' when I desribe the signing process. This was simply a typo. Then again I'd suggest that you avoid the problem all together and use DSA or PSS. A digital signature certifies the SENDER not the recipient, your current idea (encrypting the MD5 hash to the recipient) is worse than useless because you identify it as a signature. I already implement RSA signing, although I note PGP can use RSA and DSA. My implementation is working fine. My current implmentation ensures the file transmitted has not been altered by the same method PGP uses in principle (ie the implementation differs slightly in detail, but not in substance). By exposing the signature outside of the encrypted block you subject the signature to basic attacks, and fraud while protecting the payload. There have been several attacks on signatures of similar form (reference PKCS 1 version 1). The attack you mention here is against muiltiple session attempts against SSL. I don't see how altering the signature in transit could do anything but invalidate the message. Also a replacement message couldn't be faked without knowing the senders Private Key. Also, from what I can see PGP signatures are exposed outside the encrypted block. Sending the file name is at best idiotic, filenames are designed so that they tell the reader something about what is being sent (reference every vbs script that took advantage of this), by sending a
Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #13 Sun, 25 Feb 01 14:13:00 EST
Contents:
Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
Re: RSA - public key exponents and plain text. (William Hugh Murray)
Rabin's IDA in Java ?? (Yaniv Azriel)
Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher) ("Henrick
Hellström")
Re: Tempest (Mok-Kong Shen)
Re: Encrypted Email for Business Documents (Peter Harrison)
Re: Simple, possibly flawed, stream cipher ("Scott Fluhrer")
Re: super-stong crypto, straw man phase 2 (Nicol So)
Diffie-Hellman via Complex Associative Hash Functions (Jim Steuert)
From: William Hugh Murray [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: super-stong crypto, straw man phase 2
Date: Sun, 25 Feb 2001 16:58:28 GMT
Nicol So wrote:
William Hugh Murray wrote:
... going from 15 to16 rounds for the DES adds
both complexity and protection; going from 16 to 17 adds complexity but
no additional protection. The upper bound of the protection comes from
the brevity of the key. ...
I don't think we know enough about DES to be able to say that. There may
be more efficient attacks than currently known/published. And round 17
may make such attacks less effective or less efficient. Unless we know
that no such attacks exist, we really cannot say for sure that round 17
adds no protection.
It is not necessary to know that there is not a more efficient attack than
brute force. It is sufficient to know that brute force against the key is
the most that anyone will spend. That is to say, an exhaustive attack
against the key is the most that any one will spend without regard to what
else they know. They may not spend that much if they know a more efficient
attack but they will clearly not spend more. (Of course, I have trouble
believing that if I knew a cheaper attack that it would benefit me more to
keep that fact a secret than to disclose it, but then, DES was merely an
example.)
What differential cryptanalyis told us was that, for the DES, there was a
subtle balance between the number of rounds and the length of the key. A
longer key would not add much protection if the number of rounds was held
constant. Additional rounds would not add much protection if the key were
kept constant. Until Biham and Shamir published, many people thought that a
longer key, for example, 64 bits, which would raise the cost of an exhaustive
attack dramatically but not that of differential cryptanalysis, would add
protection.
(Of course, since the conditions for differential cryptanalysis are not
practically met, it might add protection to lengthen the key. This is true
IFF differential cryptanalysis is the only attack whose cost is determined by
the complexity of the cryptogram. As I was trying to suggest when I started
this thread, DC is a valuable tool, not because it lowers the cost of
recovering a message without the key (which is the criteria that I thought
Doug Gwyn was using) but because it gives us a way to compare the complexity
of otherwise similar algorithms, e.g., another Feistel algorithm with
different s-boxes or a different number of rounds.)
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
--
From: William Hugh Murray [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: RSA - public key exponents and plain text.
Date: Sun, 25 Feb 2001 17:01:17 GMT
Rich Wales wrote:
Tony L. Svanstrom wrote:
Yeah, but this isn't about PGP... Basically I'm going to allow
people to send me encrypt messages by using RSA directly on it.
If you're going to use RSA directly, be sure you've studied it very
carefully (including recent research results) in order to avoid the
known security pitfalls.
You can start by reading Zimmerman on the limitations of PGP/
Remember that RSA is slow in comparison with symmetric algorithms; this
is one reason why PGP doesn't use RSA to encrypt the actual cleartext.
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: Yaniv Azriel [EMAIL PROTECTED]
Subject: Rabin's IDA in Java ??
Date: Sun, 25 Feb 2001 19:07:34 +0200
has any one source code for Rabin's Information Dispersal Algorithm in
java ?
(I found C++ Crypt++ source but it makes too many calls to other
parts of the lib and looks a pain to port..)
--
From: "Henrick Hellström" [EMAIL PROTECTED]
Subject: Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher)
Date: Sun, 25 Feb 2001 18:21:19 +0100
Here is a similar cipher that
Cryptography-Digest Digest #748
Cryptography-Digest Digest #748, Volume #13 Sun, 25 Feb 01 18:13:01 EST
Contents:
Re: Diffie-Hellman via Complex Associative Hash Functions (Mok-Kong Shen)
Re: Simple, possibly flawed, stream cipher ("Henrick Hellström")
Re: SHA-1 (was Re: Password authentication ...) (Tim Tyler)
Re: fiat shamir (David Hopwood)
Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
Re: OverWrite freeware completely removes unwanted files from harddrive (Anthony
Stephen Szopa)
Re: OverWrite freeware completely removes unwanted files from harddrive (Benjamin
Goldberg)
Fair(er)play (JPeschel)
Re: Fair(er)play (JPeschel)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Diffie-Hellman via Complex Associative Hash Functions
Date: Sun, 25 Feb 2001 20:37:49 +0100
Jim Steuert wrote:
Why can't Diffie-Hellman be accomplished using
associative (and balanced) hash functions? If both Alice and Bob
start with a common very long public initial seed, and their secret exponents are
not so large as to compress it to nothing (an important requirement), then
common secret = bob's:(Seed^a)^b will equal alice's: (Seed^b)^a where
where a is alice's part of the secret and b is bob's part of the secret.
In this usage, a nesting of xor and prime-modulus associative operators
may work.
I don't understand why do you need the concept of a 'hash
function'. (Do you have any concrete hashing function in
mind that works in the current context?) I suppose that what
you require is a (general) multiplication operator (that is
associative), as you said in your original article. If you
choose such an operator (other than the normal one on
integers) like the one for a vector (of integers) of your
previous post, then I guess that you are faced with three
tasks: (1) Prove that the operator is associative. (2) Show
that taking the logarithm is hard. (3) Demonstrate that it
is more efficient/economical than the scheme currently being
used.
M. K. Shen
--
From: "Henrick Hellström" [EMAIL PROTECTED]
Subject: Re: Simple, possibly flawed, stream cipher
Date: Sun, 25 Feb 2001 20:36:57 +0100
"Scott Fluhrer" [EMAIL PROTECTED] skrev i meddelandet
news:97bhlf$7ql$[EMAIL PROTECTED]...
However, from it appeared what you were doing, well, it didn't appear to
be
exactly what I was thinking of. Some comments about what those variables
were would definitely help. Perhaps I'll throw together my own analysis
program.
Here are some comments:
* By convention, arguments of functions and procedures are prefixed with the
letter 'A' to distinguish them from constants and local and global
variables.
* IBox is the "inverse" of the function f(s) = (SBox[s] xor SBox[s+1]), or,
rather, IBox[x] contains the solutions s to the equation x = (SBox[s] xor
SBox[s+1]).
* Key is the initial value of State. It is only kept for display purposes.
* Guess is the result of the attack, i.e. the guessed value of Key.
* I count the frequencies of solutions s to the equation (x xor y) =
(SBox[offset + s] xor SBox[offset + s+1]), where x is the present adjusted
output value (the impact of lower state values is eliminated), y is the
previous adjusted output value, and offset is the offset from the initial
value of state[i]. If there is no solution, the event is not counted.
Otherwise the frequency of each solution is incremented by 1/count, where
count is the number of solutions.
* Dev is the deviation of the most frequent solution. It is only calculated
for display purposes.
BTW I detected one error in the procedure Analyze1, but it seems as if it
did not have any major impact on the success rate. The correct code should
be:
procedure Analyze1(const AOutput: TOutputArray;
const ASBox: TSBox;
const AState: TStateArray;
const Index: Integer;
const AIBox: TInverseSBox;
var AFreq: TFrequencies);
var
i, j, k, count, offset: Integer;
s: TStateArray;
x, y, dx: Byte;
df: Real;
yval: Boolean;
begin
(* Transfer the known initial values of State[i] to a local variable: *)
for i := 0 to Index - 1 do
s[i] := AState[i];
(* We don't know the initial value of State[Index], of course, but we will
calculate the offset from the initial value: *)
s[Index] := 0;
(* We don't have any previous adjusted value yet: *)
yval := False;
for j := 0 to HighOutput do begin
x := 1;
(* Step through the state update procedure, up to Index: *)
for i := 0 to Index-1 do begin
if Odd(x shr i) then s[i] := (s[i] + 1) mod 256;
x := x xor ASBox[s[i]];
end;
(* Do we have a possibly valid hit? *)
if Odd(x shr Index) then begin
s[Index] := (s[Index] + 1) mod 256;
(* Calculate the offset from the initial value of State[Index]: *)
Offset := 256 - s[Index];
(*
Cryptography-Digest Digest #749
Cryptography-Digest Digest #749, Volume #13 Sun, 25 Feb 01 21:13:01 EST
Contents:
Re: Rnadom Numbers ("Simon Johnson")
Re: SHA-1 (was Re: Password authentication ...) ("Henrick Hellström")
PGP key servers ("Gregory Pierce")
Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Simon Johnson")
Re: OverWrite freeware completely removes unwanted files from harddrive ("Trevor L.
Jackson, III")
Re: Encrypted Email for Business Documents (phil hunt)
Re: PGP key servers (Tom McCune)
How to find a huge prime(1024 bit?) (Thomas Boschloo)
Re: Simple, possibly flawed, stream cipher (David Wagner)
Re: Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher) (David
Wagner)
Re: Super strong crypto ("Bryan Olson")
Re: Diffie-Hellman via Complex Associative Hash Functions (Jim Steuert)
From: "Simon Johnson" [EMAIL PROTECTED]
Subject: Re: Rnadom Numbers
Date: Sun, 25 Feb 2001 23:12:15 -0800
Tim Tyler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
Simon Johnson [EMAIL PROTECTED] wrote:
: Would I right in saying that if a crypto-secure pseudo-random generator
was
: unable to be cryptanalysed until x bytes of stream were recovered then
all
: of the bytes previous to the x'th byte must be statistically random?
[...]
Unable to be cryptanalysed by who?
yeah, good point. I assume that this question cannot be answered then until
the problem surrounding p=np is solved, right? Since we can't actually
_prove_ security against all attacks until that solution is found, can we?
You see my logic is this: If any stream generator is completly unpredictable
until x bits of stream are recovered, then all the bits from 1x-1 must
be perfectly pseudo-random.
This, i feel, is a statement of the obvious but i wondered if it could be
proved for a given algorithm i think i've answered my own question.
__
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
--
From: "Henrick Hellström" [EMAIL PROTECTED]
Subject: Re: SHA-1 (was Re: Password authentication ...)
Date: Mon, 26 Feb 2001 00:15:28 +0100
"Tim Tyler" [EMAIL PROTECTED] skrev i meddelandet
news:[EMAIL PROTECTED]...
What you describe would be very, very suprising. Are you using SHA1 in
counter mode? OFB mode? If you are feeding it repeating values that
might explain your results.
OFB - I iterated the algorithm, each time padding the previous output with
zeroes.
If you insist that you find the results "very, very surprising", I find it
equally probable (1) that I didn't perform a sufficient number of tests, or
(2) that there is a flaw in the library implementation of SHA-1 I was using.
Have you repeated the test? What were your results?
Your results with 3DES are equally astonishing. What chaining mode are
you using?
CBC-mode, a zero string plain-text, but only a modest number of different
keys and initialization vectors. Certainly, you could get _any_ result out
of this test, just you choose the key and plain text carefully. But a string
of zeroes seems to me as a trivial first hand choice for a chosen plain text
attack, so, yes, I agree that it would be an interesting result.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
--
From: "Gregory Pierce" [EMAIL PROTECTED]
Subject: PGP key servers
Date: Sun, 25 Feb 2001 23:15:46 GMT
Hello,
I was wondering if anyone else using PGP was having trouble downloading
public keys from the mit and pgp.com key servers?
-Greg
--
From: "Simon Johnson" [EMAIL PROTECTED]
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Date: Sun, 25 Feb 2001 23:43:04 -0800
Sundial Services [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
S. wrote:
Therefore OTP:s really are unbreakable,
provided the pad is truly random and secret.
... which, of course, is the Achilles heel of this system in practice.
If you cannot keep a message secret, who's to say that you'll actually
be able to keep the one-time pad secret, and safe from Mr. Murphy's Law?
The word "perfect" simply does not apply to real-world human enterprises
of which cryptography of course is one. Conditions are never perfect;
"ka-ka occurs," and a real system must be able to handle that.
Well, the problem is an OTP cryptosystem isn't unbreakable. Okay, in the
theortical sense it is. But people tend to forget that the secret gets
decrypted at some point, meaning it can be stollen etc.
The only way an OTP cryptosystem could ever be 100% secure is if:
1. The secret encrypted never existed in plain-text form.
2. The OTP is unpredictable and can't be reproduced.
3. The secret was never decrypted.
and if these three conditions are met, then there is no point to it existing
anyway.
--
From: "Trevor L. Jackson, III"
