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 second copy of this you
>are only forcing the leakage of information.
Version 2 of this discussion document will introduce multiple files in
the same attachment - like zip files. Encrypting the
filenames/directory would probably be a good idea however.
>You fail to specifiy what chaining mode to use Rijndael in, you fail to
>specify where the IV is to be placed, you fail to specify which mode RSA is
>to b used in to encrypt the key.
CBC I believe. Thats how I implemented it in the first cut anyway.
>Including the sends and recipients e-mail addresses is foolish, just place
>the public keys and avoid the necessary look up who it is.
Do you mean include the whole public key of the sender? The point of
the signature is that it links public key of the sender obtained
through the key server using the senders email address. This way only
the person in control of the senders email address can sign a file.
Sending the public key, and then not looking it up would not make
sense. If you do look up a public key to find a email address you may
as well look up an email address to find the public key. I suggest a
find on a email address could be optimized easier than a public key.
>About your reference implementation: NO ONE WILL RUN IT IF YOU ONLY
>DISTRIBUTE THE EXECUTABLE, people who run real operating systems (aka UNIX
>OpenVMS, linux, etc) will never be able to run it. I even have a WinNT box
>that it will never run on.
Its been removed until I put up the source code.
>What I'd suggest is that you do one of two things; learn something about
>computer security especially encryption, or not bother people who have some
>semblance of a clue about computer security and encryption with your less
>than intelligent attempts to compromise the security of business.
> Joe
Bad day at work eh? While my spec isn't yet functionally complete, I
don't see any fatal flaws in its design. Having said that there might
be some steps I can take to make things more difficult, and I will
take that onboard.
I am looking at using PGP, however PGP doesn't address some of the
issues I am trying to solve.
Issues revolve around difficulty of use. Most encryption systems
require users to obtain public keys through a manual process. My
implementation obtains public keys when a email is sent without user
intervention. With PGP there is a user intervention to download keys.
The same applies to receiving encrypted emails. My system connects to
the key server to obtain a key when a encrypted email arrives from
someone who it does not hold the key for.
I have also restricted the options for the system. All emails are
ALWAYS encrypted - remembering that this will be used for documents,
not generic emails. This means that all transmissions are always
encrypted and signed - the user has no option about this.
My whole concept was to reduce the number of interactions with users
to reduce the number of screw ups caused by users who are not crypto
experts. All options that require crypto knowlege by the user have
been removed.
There is a huge potential for secure email, and I am trying to bring a
solution that works for people. I am not a cryptologist, although I
do know enough to implement some of this stuff in a sensible way.
I appreciate that you know much more than crypto than me, however I am
trying to make something useful, and I don't think I deserve personal
attack for my efforts.
Regards,
Peter Harrison
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Life cycle of keys
Date: Sun, 25 Feb 2001 00:42:03 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> In a recent thread Douglas Gwyn has proposed to dynamically
> transmit new keys for block encryption, leading to much
> interesting theoretical discussions.
>
...
> It is thus of interest to ask a practical question, which
> for concretness I like to formulate thus: How many MB can
> one safely encrypt with AES and a single (random) key of
> 128 bits?
>
The short answer should be totally disgusting, that like DES, AES put
against Shannon's unicity distance as one thrust at establishing strength
results in the same conclusion, what a gosh awful cipher in that regard.
The value is 2-3 times 128 bits.
Should banking interests. for example, like the assignment of using of
such poor security? No, to a one they will tell you that they what maximal
security, and if given the facts, this ain't it.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Am I doing something silly by including my gnupghome with my archive?
Date: 24 Feb 2001 23:44:25 -0800
jtnews <[EMAIL PROTECTED]> writes:
> I'm making CD-RW disks with encrypted archives
> of my work with an unencrypted gnupghome
> directory on it.
This doesn't seem like a wise idea unless you're sure your passphrase
is long enough to not be guessable by brute force. I'm assuming you're
leaving copies of the discs off-site which means other people might
access them.
If you're trying to protect the key long-term, the passphrase should
have at least 90 bits of entropy. So if it's a Diceware password
(www.diceware.com), for example, it should be 7 or more words long.
http://www.nightsong.com/crypto/dice.php gives you 5-word Dice
passphrases, so you could generate two such phrases (giving 10 words)
and use 7 (or more) of the words.
Really though, your safest bet is to encrypt the entire disc with a
long passphrase of the above type.
For more about backups, see www.taobackup.com.
------------------------------
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: RSA - public key exponents and plain text.
Date: Sun, 25 Feb 2001 09:18:53 +0100
John Savard wrote:
> Some people have used 257, or even 3. (I wonder why they don't use
> 17.) So, yes, the public exponent can be quite small. (Note that the
> ones given here as examples are of the form 2^n+1; this is to make
> exponentiation more efficient.)
It is now some sort of common knowledge _not_ to choose too small encryption
or decryption exponents:
- Choosing a too small _decryption_ exponent d can be really dangerous.
As long as d < n^{0.292}, where n is the RSA modulus, there is a way
to factor n efficiently (this was proved by Boneh and Durfee recently).
So you should _really_ avoid small decryption exponents (actually it
is believed that RSA is already insecure in case d < sqrt(n), but we
currently don't have a proof for this).
- In case you use a small encryption exponent, things are much more
complicated. We currently don't have a method that breaks RSA totally
in this case. However, there are some protocol attacks that exploit
small encryption exponents (sending one message to several persons
with low encryption exponents is insecure, re-sending polynomially
related messages can be dangerous, cracking of stereotyped messages
might be possible, etc.). These attacks leave no good feeling of the
RSA system with low public exponents. One should perhaps avoid it
too...
--Stefan.
--
====================================================================
[EMAIL PROTECTED] (remove "XXX" before replying)
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Really big numbers in C
Date: 25 Feb 2001 10:45:27 +0100
In article <[EMAIL PROTECTED]>,
Taylor Francis <[EMAIL PROTECTED]> wrote:
>> Then you cannot be using Visual C++ 6.0 but must be using Visual
>> C++ 1.52 or earlier, since this was the last version of Visual C++
>> which could generate DOS programs.
>>
>> If you use Visual C++ 6.0, then your so-called "DOS program" is
>> really a Windows-32 Console Application. If you don't believe be,
>> try to run your "DOS program" on a real DOS machine, with no
>> Windows....
>
> Agreed... that's what I'm doing...
> BUT...I don't know how to program in Windows... just in C that runs
> under 'DOS'...
You're programming against the Standard C API, which Visual C++ 6.0
will translate into a Win-32 Console Application.
There are other API's you can learn to program against, and they're
available in Visual C++ 6.0. The Win-32 API allows you to write a
program with windows in C as well as in C++. And then you have MFC,
which is an easier way to write windowed programs, but it requires
C++, i.e. you must first learn some C++ in case you don't already
know it. Once you know that, Visual C++ has some "wizards" (helper
programs) which generates most of the API related code for your
windowed application.
It's all there in your Visual C++ 6.0, including help texts, tutorial
examples of code, etc -- all you need is time to learn it.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sun, 25 Feb 2001 11:47:20 +0100
Nicol So wrote:
>
[snip]
> In Douglas's scheme, traffic encryption keys double as the key
> encryption keys of their successors. I think this is a bad idea (and I
> think it has been pointed out). Ideally the TEKs, if related to one
> another at all, should be so related that knowledge of one (together
> with intercepted traffic) would not allow easy derivation of the others.
One can send new keys this way, assuming a master key G
and a newly chosen encryption key K: U=E(G,K). Send U and
E(K,P_i) where P_i are plaintext blocks processed by the
new key.
One can avoid sending key materials over the line, if one
has a PRNG appropriately seeded in a session. Then the new
key for encryption is K=E(G,R) where R is the PRNG output.
M. K. Shen
===========================
http://home.t-online.de/mok-kong.shen
------------------------------
Subject: Re: RSA - public key exponents and plain text.
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Sun, 25 Feb 2001 11:01:50 GMT
Rich Wales <[EMAIL PROTECTED]> 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.
That's why I'm asking about the public key exponents; I'm sure more
questions will follow, and finally the software that I'm going to use
(don't worry, we're only talking about a short Perl-script, nothing too
long).
> 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.
Of course.
/Tony
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption?
Date: Sun, 25 Feb 2001 12:47:32 +0100
"John A. Malley" wrote:
>
> Well, I finished the paper. Equation 2 reads as pseudocode for a loop:
>
> 1. x(n+1) = 4*lambda*x(n)*( 1 - x(n))
>
> 2. x'(n+1) = 4*lambda*x'(n)*( 1 - x'(n))
>
> 3. P(n) = x(n) XOR x'(n) where P(n) is the chaotic "pseudorandom"
> stream
>
> 4. C(n) = P(n) XOR plaintext(n) (the authors let y(n) stand for
> plaintext(n) in the paper)
>
> so C(n) = x(n) XOR x'(n) XOR plaintext(n)
>
> The variables x(n) and x'(n) are then set with the current values of
> x(n+1), C(n) and x'(n+1) as follows:
>
> 5. x(n) = x(n+1) XOR C(n) which is the same as x(n) = x(n+1) XOR x(n)
> XOR x'(n) XOR plaintext(n);
>
> and
>
> 6. x'(n) = x'(n+1).
I suppose that the following re-formulation is easier to
understand (I use g for their P):
g := x xor x';
c := g xor plaintext;
x := 4*lambda*x*(1 - x) xor c;
x' := 4*lambda*x'*(1 - x');
A point that immediately comes to mind here is that the
lambda in the two equations above probably need not be
the same.
> Several things about the paper puzzled me.
>
> First , 0 <= x(n), x'(n) <= 1. As I understand this cipher, the k-bit
> representations of x(n) and x'(n) are XORed with k-bit representations
> of plaintext(n) but the authors never actually say so in the article.
The x and x' are real numbers. I conjecture that they multiply
these with 2^k where k is the size of mantissa or use the
mantissa directly.
> The cryptanalysis of the cipher did not seem thorough to me. Here are
> some things in the paper that prevent me from accepting their results
> without question:
>
> if ever x or x' takes on the value of zero, then all subsequent values
> of x or x' remain zero and the "perturbation" of one chaotic sequence by
> another ceases. P would then just equal either x or x' from that point
> on and the "mixing" of two chaotic sequences ceases. This phenomenon is
> not mentioned in the paper and neither are its effects on the
> cryptanalysis of the cipher.
>
> and
>
> in section 4.4 of the paper, the authors state that P(n) and P(n+1) will
> never both be all zero bits if the plaintext(n) to be enciphered is
> never all zero bits. They claim "a null vector has no information
> content and is never transmitted." This is odd to me. We cannot rule
> out a block of all 0 bits in the plaintext - image files and binaries,
> for example, can have "long" strings of 0s in them. What is the effect
> of a long string of all-0 plaintext on the cryptanalysis of the cipher?
As pointed out by another follow-up, 0 of x doesn't matter.
0 of x' can be checked at the start of the algorithm,
thus avoiding future 0.
>
> and
>
> what is the effect of the finite resolution (number of bits)
> representing x and x' on the cryptanalysis of the cipher? Are there any
> repeating cycles in the lower-order bits of a k-bit representation of x
> and x' as the cipher executes?
x' would certainly cycle on a computer with finite word
size. x is influenced by plaintext and hence doesn't have
a 'pre-determined' behaviour.
>
> It's an interesting idea, mixing chaotic sequence this way, but I don't
> trust using it without seeing more rigorous cryptanalysis.
Agreed. It is to be noted that what is actually involved
are two non-linear PRNGs (x is special in that it incorporates
plaintext, x' is a PRNG in the normal sense).
M. K. Shen
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
