Cryptography-Digest Digest #917, Volume #8 Sun, 17 Jan 99 02:13:03 EST
Contents:
Secure Filesystem Questions (Anonymous)
Re: Too simple to be safe (Nathan Kennedy)
Re: Too simple to be safe (Nathan Kennedy)
file size of encrypted vs. unencrypted data (Grant Karlin)
Re: Too simple to be safe ("Kazak, Boris")
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Too simple to be safe ("Kazak, Boris")
Re: Too simple to be safe (Michael Hirsch)
hello! ("ROTA Computer Consultants")
Re: file size of encrypted vs. unencrypted data (Casey Sybrandy)
Re: Too simple to be safe (Paul Rubin)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
----------------------------------------------------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Secure Filesystem Questions
Date: 17 Jan 1999 02:39:10 +0100
I've been playing around with TCFS. It uses a very weak user authentication scheme at
the
moment, relying on the user's Linux login password only to authenticate the user. The
actual
64-bit secret key used is stored in a secondary file in /etc/tcfspasswd. When you
want to
start using your key within a secured fs mount point subdir tree, it asks for your
login password,
then extracts your encrypted secret key from /etc/tcfspasswd and in turn decrypts it
using
unix-style crypt(). It finally puts the decrypted key into a kernel structure where
it is
subsequently used for CPC-mode file enc/dec.
I want to increase the strength of this authentication method. I plan to increase the
keysize to
128 bits, but that is probably irrelevant to my question. I was thinking along the
lines of having
the user enter a passphrase in order to activate his secret key. I've been rummaging
around
inside GnuPG for ideas and examples on how to do this and got some pretty good info
there in
terms of secure memory allocations, passphrase manipulation, etc.
Do I lose anything by not even storing the encrypted secret key somewhere on disk?
That is,
I say forget about /etc/tcfspasswd, just hash the passphrase down to 128 bits and use
it
directly to encrypt/decrypt. Can I safely ignore using salt? I mean, if the key
isn't even stored
in any form on disk, I don't have to worry about dictionary attacks, right? Am I
missing
something? The weakest link in the chain here, as I see it, is the passphrase. That
I want
to leave entirely up to the user. If they choose a lame passphrase then tough
noogies.
Second question: If I use RIPEM-D160 to hash the passphrase down to 160 bits and then
select only 128 of those bits to use as the key, do I gain anything over simply using
a 128-bit
hash algorithm?
Third (and last) question: Is it true that with this scheme I don't even need a
random number
generator? Aside from CBC Init Vectors, which I haven't found too much discussion on,
I
can't see where I even need one.
Thanks for any and all responses.
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 02:05:25 +0800
"Kazak, Boris" wrote:
<snip>
> Like that the information about the key is communicated in the open
> text, and the key is never reused. No digital signatures, no CA's.
>
> Any comments? Respectfully BNK
Just one. Why do you do this, i.e., as opposed to a trusted cipher?
Obviously key exchange isn't a problem as you already have 150K key in
common. If you need something extremely simple, you could use an RC
cipher, and if you need something paranoidly trusted, you could use 3DES or
4DES or 3DES+Blowfish+RC5+Twofish+RC6 in which case if even one of these
trusted ciphers (well, some of them are trusted, I think most
cryptographers would bet on it even if they wouldn't certify it) does its
job, and you implement it right, it would be secure.
Or is it just a tradeoff, guaranteed security for a little bit more
overhead and less coding time?
Nate
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 02:16:24 +0800
[EMAIL PROTECTED] wrote:
> The cryptosystem proposed seems to assume that irrational
> numbers are random enough for cryptographic purposes. This
> is not always the case. Some irrational numbers can have
On the other hand the conjecture that, say, the digits of pi are normal, is
probably almost as safe as saying that factoring is hard.
> a long string of zeros, for example. XORing this section
> of an irrational number with a plaintext would reveal the
> plaintext. Taking the sqrt(prime) would usually produce a
> random looking string, but in the 135 bit range, you are
> in unknown territory as far as that goes. You might rarely
> pick a poor choice which has a weak sqrt for XOR purposes.
I read somewhere on an irrational site, that PI has been so far been found
to be normal, whereas sqrt(2) is slightly less random, and sqrt(3) is
slightly less random still. No evidence or example was offered.
> Also, rational numbers can be contrived which have good
> properties for XOR encryption, but which are easier to
> compute.
Excuse me, how is this so? Any p/q for integers P and Q will repeat or
terminate unless I am very muchly wrong. And we all know repeating is a
Bad Thing.
------------------------------
From: Grant Karlin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: file size of encrypted vs. unencrypted data
Date: Sat, 16 Jan 1999 21:34:55 -0500
I am trying to determine what the change in the required bandwidth is to
send encrypted data (using standard SSL transactions) over a network
versus sending the unencrypted data.
For example, if I have a 10kb file what is the size of the encrypted
file sent when using 40-bit encryption? 128-bit encryption? An
explanation of how this is computed would be appreciated.
Is the answer the same for both binary and text files?
Thanks for your help.
Grant
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sat, 16 Jan 1999 22:11:20 -0500
Reply-To: [EMAIL PROTECTED]
Paul Rubin wrote:
>
> If your symmetric cipher (about which you say nothing) is any good,
> then your security is good and fancy method of key setup (like the
> 150 kbyte file) won't make it any better.
>
> If your symmetric cipher (about which you say nothing) is not good,
> then your security is bad and fancy method of key setup (like the
> 150 kbyte file) won't make it any better.
==================
Let's say that it is a trustworthy "Blowfish"
=====================
>
> Either way, the 150 kbyte file and the S,N scheme don't seem to help you.
> The symmetric cipher is a much more important issue.
>
> Also, I don't mean to be disrespectful in saying this, but the nature
> of cryptography is that if you don't know exactly what you're doing,
> it's very easy to make a mistake that can compromise your security and
> get you in a lot of trouble.
>
> So I think you're much better off using something like PGP, which
> is widely available and has been heavily analyzed by a lot of people.
============================
I was not going for "fancy", this is just practical.
And this scheme seems to work with any block cipher, regardless...
Additionally, we use KOI-8 encoding for Russian plaintext, this
hopefully will make the attacks a little more difficult, if they
will use the English-plaintext stereotype :)
Respectfully BNK
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 15 Jan 1999 10:21:07 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>>A single coin flip is, to all practical
>>tests, a "true" random number generator, but is unable to mask more
>>than a single bit of information.
>
>That is why the specification for a TRNG focuses on the sequence, not
>the individual bits. A TRNG is a physcial device capable of outputting
>all possible sequences equiprobably. That says nothing about the
>individual bits making up the sequence, although some things about
>them can be inferred.
>
>If you recall from the discussions a year ago, this point was debated
>and that is how this consensus definition for a TRNG prevailed. We
>decided that it was the generation of the sequence, not individual
>bits, that was important.
>
>>Similarly, if I use a set of
>>five coin flips to generate a "truly-random" key for a Caesar
>>cypher, the resulting system is still insecure as hell. The
>>key itself is still random, but it's carrying more than its
>>rated wattage, if you'll permit me an engineering metaphor.
>
>I do not see how the above statements made by the original poster or
>by me in any way implies that. But maybe I am missing something.
>
>>Conversely, I can still use algorithmic methods that are not truly
>>random and be able to mask small messages;
>
>Why only small messages? What is so special about small messages? Why
>can't a large message be considered the concatenation of many such
>small messages?
Because small messages are, in a formal sense, less uncertain than
large messages; there are fewer of them, so they are individually
more probable, and hence contain less entropy. The formal condition
for perfect security is that the entropy of the key exceeds the
entropy of the message [plus a few other handwaved conditions], which
is, of course, smaller for short messages.
>If you say that one small message can slip under the radar but many of
>them cannot, that still does not say anything about the security of
>the system. I could probably slip almost any cipher under the nose of
>the best team of cryptanalysta and they would not have enough to go on
>to know how I constructed it. For all they know, based on "one small
>cipher", I could have used the Washington to Moscow OTP system.
But, for sufficiently small messages, *even if they know what system
you use*, you can still achieve perfect security if the message
is short enough.
>
>For example, here is a typical "small message": 10111010...
>
>Now, from that tell me what my message is. Is it "attack at dawn" or
>"attack at dusk" or "attack at noon" or "do not attack"?
>
>>a good example would
>>be, for instance, using about 1000 characters of running (English)
>>text -- a classic book cypher -- using a good hashing algorithm (or
>>even a good compression algorithm) to distil 256 pseudorandom bits from
>>those thousand characters, and then using those bits as an XOR mask to
>>hide *no more than 256* bits* of plaintext.
>
>That method is still under debate, at least in my mind. But then you
>hedged it by saying that it was only good for "one small message".
Well, the classic book cypher is *NOT* perfectly secure; Friedman
was proving that routinely by cracking them around the first World
War. But the proof that 1000 characters of English text contain
enough randomness to hide 256 bits of plaintext is mathematical;
re-read the Shannon papers for the numbers.
>So what? I claim any cipher is good for "one small message".
>
>>This can be proved secure,
>>subject to some handwaving about the hashing algorithm being sufficiently
>>(and provably) "good." Hey, such proofs exist for LZ77.
>
>Do you have a reference for that, preferrably on the Web?
The proof of the optimality of LZ77 is in the original Ziv-Lempel
paper.... um, IEEE Trans. Info. Theory, IT-23(3), May 1977. It's
discussed a bit in the Bell, Cleary and Witten book on _Text Compression_
(1990, Prentice-Hall).
Informally, the proof of security for the short message case --
a ''perfect'' key-based cypher with an N-bit key will generate
2^N different cyphertexts for a given plaintext block if the
key is set properly. If the plaintext is N bits or shorter,
then 2^N includes all possible decryptions. If each of the
N-bit keys are equally likely, no information is leaked (except
the size) and the encryption yields perfect security.
However, if the plaintext message is longer than N bits, then
the pigeonhole argument shows that not all possible cyphertexts
are possible encryptions -- and conversely, not all possible
cleartexts are possible *de*cryptions of a given cyphertext.
Or in other words, information gets leaked. Again, see the
Shannon papers for the argument in glorious mathematical detail.
So the point is that the *process* that generates the bits isn't
the important part; the important part is the degree of randomness
in the key vis a vis the randomness of the message. So if you
have an unbounded message length (contrast with "short", which
in this context mostly means "bounded") you need an unbounded
supply of randomness, which usually means a TRNG. If you have
a bounded message length, then there's a maximum amount of randomness
necessary to provide perfect security which *can* be achieved
via algorithmic means.
-kitten
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sat, 16 Jan 22:30:19 -0500
Reply-To: [EMAIL PROTECTED]
Nathan Kennedy wrote:
> Just one. Why do you do this, i.e., as opposed to a trusted cipher?
> Obviously key exchange isn't a problem as you already have 150K key in
> common. If you need something extremely simple, you could use an RC
> cipher, and if you need something paranoidly trusted, you could use 3DES or
> 4DES or 3DES+Blowfish+RC5+Twofish+RC6 in which case if even one of these
> trusted ciphers (well, some of them are trusted, I think most
> cryptographers would bet on it even if they wouldn't certify it) does its
> job, and you implement it right, it would be secure.
>
> Or is it just a tradeoff, guaranteed security for a little bit more
> overhead and less coding time?
>
=====================
You got it somehow wrong - I am actually using "Blowfish" and this
is how we establish the session key. Each message has a luxury of its
own key, never twice the same one.
Respectfully BNK
> Nate
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: 16 Jan 1999 21:01:22 -0500
[EMAIL PROTECTED] writes:
> Here is how to find square roots:
> _______________________________
>
> [EMAIL PROTECTED] wrote:
> "Suppose we want to find the square root of A.
> Make a guess/estimate, and call this guess x_0.
> For i > 0, let
>
> x_i = (x_(i-1) + A/x_(i-1))/2
>
> It can be proven (easy), that
> lim x_i = sqrt(A) as i goes to infinity."
> See "Advanced Calculus" by Buck
right. This is newton's method. The really nice thing about it is
that the number of digits of accuracy more than double at each step as
you get close. So getting 1024 digits doesn't really take very long.
Of course, you'd need to carry more digits in your computation each
time, too, but I still think it would be quite fast.
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: "ROTA Computer Consultants" <[EMAIL PROTECTED]>
Subject: hello!
Date: Sun, 17 Jan 1999 03:54:52 GMT
hello, my name is robert
i am currently in college and am studying computer science
recently i have become aware of the job demand for cryptography
experience. i would like to know if there is anyone in
this newsgroup or outside that might be willing to answer questions
as my experience grows with this new subject. further, if anyone is
willing to teach me more about the details of cryptography i
would be grateful.
please correspond by email.
thanks!
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: file size of encrypted vs. unencrypted data
Date: Sun, 17 Jan 1999 00:03:03 -0500
The key length is irrelavant to the size of the ciphertext, it's the block
size the algorithm uses that matters. For example, if the algorithm you're
using encrypts 64-bits, or 8 characters, at a time, you would have at most 7
extra characters as a result of padding. However, if you use a stream
cipher, you shouldn't have that problem, unless you expanded RC4 or
something similar to encrypt using blocks bigger than 8-bits.
Grant Karlin wrote:
> I am trying to determine what the change in the required bandwidth is to
> send encrypted data (using standard SSL transactions) over a network
> versus sending the unencrypted data.
>
> For example, if I have a 10kb file what is the size of the encrypted
> file sent when using 40-bit encryption? 128-bit encryption? An
> explanation of how this is computed would be appreciated.
>
> Is the answer the same for both binary and text files?
>
> Thanks for your help.
> Grant
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 04:39:12 GMT
In article <[EMAIL PROTECTED]>, Kazak, Boris <[EMAIL PROTECTED]> wrote:
>> If your symmetric cipher (about which you say nothing) is not good,
>> then your security is bad and fancy method of key setup (like the
>> 150 kbyte file) won't make it any better.
>------------------
>Let's say that it is a trustworthy "Blowfish"
>---------------------
Ok, Blowfish is a good choice. But what chaining mode do you use
and are you sure it's implemented correctly? How did you generate
the 150 kbyte file? For example if it came from a 16-bit rand()
generator, it has almost no real entropy and so it is useless.
There are a lot of opportunities to mess up.
>I was not going for "fancy", this is just practical.
>And this scheme seems to work with any block cipher, regardless...
>Additionally, we use KOI-8 encoding for Russian plaintext, this
>hopefully will make the attacks a little more difficult, if they
>will use the English-plaintext stereotype :)
I still don't see the need for the 150 kbyte file. It creates a
vulnerability since if the file is seized, the game is over.
It might even be better to just keep re-using the same key.
If you don't want to do that, use a single permanent memorized
key (passphrase) to encrypt a temporary key which is different
for each message.
Best would be to use a public key method like Diffie-Hellman key
exchange for every message to create a new secret key, and destroy
each new secret key after using it once.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 17 Jan 1999 06:00:35 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
** 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
******************************
