Cryptography-Digest Digest #279, Volume #12 Mon, 24 Jul 00 09:13:01 EDT
Contents:
Re: Random Appearance (Benjamin Goldberg)
Crypto Questions ("Clint Eastwood")
Idea - quantum crypto + chaffing & winnowing (Benjamin Goldberg)
Re: Can Anyone Recomend A Good Intro Text (John Savard)
Re: Random Appearance (John Savard)
Re: Random Appearance (John Savard)
Re: Proving continued possession of a file (Mark Wooding)
Re: Proving continued possession of a file (Mark Wooding)
Re: New stream cipher (Tom Anderson)
AESC-stream cipher ([EMAIL PROTECTED])
Re: Can Anyone Recomend A Good Intro Text (James Pate Williams, Jr.)
Re: VCR+ ("Bob Kow")
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Mon, 24 Jul 2000 09:38:12 GMT
Tim Tyler wrote:
>
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> : Joseph Ashwood wrote:
>
> :> OTP's are subject to known-plaintext attacks, ...
>
> : No, they are not, since the only plaintext that is "recovered"
> : is exactly the plaintext that was already known. [...]
>
> It depends on how you look at it. Recovering the plaintext is not the
> only possible aim of a known-plaintext attack. Another goal is
> recovering the key.
>
> With an OTP, known plaintext attacks may be used very effectively to
> recover the key (in the form of the corresponding section of the pad).
>
> This attack could be employed if you wanted to try to spot
> regularities in the keystream due to imperfections in the random
> number generation technique,
While this would, in fact, be a useful attack, it assumes that the
random number generator is less than random. Considering all the other
overhead of using a true OTP system, there is no reason for us not to
avoid the expense of using a good [physical entropy] RNG. If there's
no way of using the uncovered keystream to predict some other part of
the keystream, then known/chosen plaintext isn't particularly useful.
> or if you subsequently wanted to attempt to forge a message that used
> that section of the keystream.
Hmm... If you know [part of] the plaintext in an intercepted message
(that is, you didn't just overhear it, you stopped it from getting to
it's destination), you can XOR out [that part of] the original data, and
XOR in your own data.
> From this POV, a "naked" OTP is very weak. Few block cyphers will let
> you get at any keybits if you only have a word or two of known
> plaintext.
If you have known/chosen plaintext, and the ability to intercept,
modify, and resend messages, and if there's no message signing
(authentification) then, yes, OTP is weak. How often, though, is this
the case?
--
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
------------------------------
From: "Clint Eastwood" <[EMAIL PROTECTED]>
Subject: Crypto Questions
Date: 24 Jul 2000 09:55:27 GMT
Can anyone help out?
When using the Microsoft Crypto API, you can create 2 keys, one for
signatures, and one for encryption.
When creating S/MIME messages and certificates, do you only use the
encryption key? Is this key (named AT_EXCHANGE) used for both encryption
and signing?
Thanks for any help, Graeme Dykes
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Idea - quantum crypto + chaffing & winnowing
Date: Mon, 24 Jul 2000 09:58:27 GMT
I have a possible idea for a combination of quantum crypto,
and a chaffing and winnowing scheme:
Alice and Bob have a QC keystream generator set up between them.
They've got an unsecure, unauthenticated 'normal' channel also
available. Also, they've some small [Max size allowable for an HMAC
authentification key] secret between them.
Each message from A to B could contain the following information:
t = time-of-measured-keybit
i = bit-index-of-file
d = direction {45deg, 90deg, left-circular, right-circular}
c = keybit XOR databit
Message-packet = t || i || HMAC( d || c || t || i )
Whenever Bob recieves a packet, he uses t to look up what he measured
for d, and computes to HMACs, one for each possible c. If neither match
the HMAC from the message, it's a bad packet -- EITHER d was wrong, OR
the packet was corrupted in transit. The reason d isn't included
directly is because it can be looked up from t, and c isn't included
directly because it can only be 0 or 1.
Adding a small amount of chaff makes this even more secure.
Does this idea make any sense, or is it completely useless?
--
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can Anyone Recomend A Good Intro Text
Date: Mon, 24 Jul 2000 10:15:56 GMT
On Mon, 24 Jul 2000 02:58:31 GMT, Wade Reiber <[EMAIL PROTECTED]>
wrote, in part:
>I'm looking for a good introductory text on crytography. Any recommendations?
>The best one I've seen so far seems to be Bruce Schneier's "Applied Cryptography".
It is a good introduction to the field of modern-day cryptography on
computers. There isn't another book like it.
There are books which go more deeply into the mathematics of
public-key cryptography, such as "Handbook of Applied Cryptography"*+
by Menezes, Oorschot, and Vanstone, and the book "Decrypted Secrets"
that has been recommended covers cryptanalysis of both modern and
older ciphers.
Two other well-loved books on the subject are "Elementary
Cryptanalysis" by Helen Fouche Gaines, available under the title
"Cryptanalysis" from Dover: it's an introduction to - and a
comprehensive textbook on - solving pencil-and-paper ciphers, and "The
Codebreakers", by David Kahn, which covers the history of the subject
in depth.
Shortly after DES came out, a number of books on cryptography were
written; some of these are expensive, or hard to find, but some
libraries may have them: "Cryptography: A Primer" by A. Konheim,
"Cryptography: A New Direction in Computer Data Security"* by Meyer
and Matyas, and "Cryptography and Data Security" by Dorothy Denning.
Also, a book covering some of the same territory as Gaines is
available on the web, for example at the Crypto Drop Box: a U.S.
military technical manual.
http://www.und.nodak.edu/org/crypto/crypto/
* on the Dr. Dobbs CD-Rom; for that matter, so is Applied Cryptography
+ see its web site, at http://www.cacr.math.uwaterloo.ca/hac/
And you can also visit my web site, which covers many cipher systems
from old to new.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Random Appearance
Date: Mon, 24 Jul 2000 10:19:26 GMT
On Fri, 21 Jul 2000 17:19:41 -0400, Future Beacon <[EMAIL PROTECTED]>
wrote, in part:
>It seems that merely diluting the message
>would be possible, but I am thinking that a dense message that
>wastes no characters might seem orderly but not be the oder which
>is the intended message.
Well, there are transposition ciphers. But in general, it is simpler
to compress a message until the plaintext is random to start with, and
then use a cipher method that produces a transform to random-like
output. Then, it is easier to be confident that the result is secure,
since every part of the input is scrambled. "Order" can later be added
for steganographic or other purposes: i.e., the output can be put in
nice five-letter groups for ease of transmission.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Random Appearance
Date: Mon, 24 Jul 2000 10:23:45 GMT
On Sat, 22 Jul 2000 22:57:44 -0400, Future Beacon <[EMAIL PROTECTED]>
wrote, in part:
>I believe that it is possible. Winograd, at least 20 years ago, at
>MIT programmed a computer to form English sentences that were not
>predictable by the human correspondent. He had to understand
>grammar and logic very formally and well to do it. This kind of
>thing is covered in the subject of artificial reasoning. These
>kinds of achievements prompted me to try to form arbitrary English
>sentences from a string of random numbers. I am convinced that it
>is possible.
Yes, but this sort of thing is a kind of steganography. For the
cryptography itself, the input and output are close to pure random
bits. But before input, compression can be applied; and after output,
the output can be made to look like a picture, or text, or whatever.
Cryptography that operates directly on text that is ordered, retaining
the order through the process, and yet remaining secure, even if not
mathematically impossible, involves an extra complication that is not
needed.
One can certainly use a compression scheme on input, and then reverse
the same scheme on output: perhaps you're thinking of a compression
scheme that uses a dictionary of words and sentence patterns?
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Proving continued possession of a file
Date: 24 Jul 2000 10:35:17 GMT
Edward Keyes <[EMAIL PROTECTED]> wrote:
> How about the server sends the client a small bit of random data
> and asks the client to compute:
>
> HASH(RANDOM+FILE)
>
> This is easy for the client to do, easy for the server to verify,
> and extremely unlikely to be able to fake if you don't still have
> a copy of the file.
No. This requires the *server* to have a copy of the file, and (perhaps
more importantly) to grind its way through it each time. That's OK for
the client, but too much effort for the server (since it's dealing with
lots of clients).
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Proving continued possession of a file
Date: 24 Jul 2000 11:16:37 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> Mark Wooding <[EMAIL PROTECTED]> wrote:
> > A while ago, I was asked to come up with some mechanism whereby a server
> > could ascertain whether a client, which had previously transferred a
> > particular file to the server, still had a copy of that file itself.
> >
> > Let's call the file's data M, and we'll suppose that Alice is running
> > the server, and Bob is running the client. Last week, Alice knows that
> > Bob had the file M, and he sent it to her. This week, Bob claims to
> > still have the file, but Alice isn't convinced.
>
> Did you want a one-shot solution, or did you want the server to be
> able to repeat this verification some arbitrary number of times not
> known in advance?
The latter. Earlier attempts at this protocol, had they not had glaring
security problems which I noticed as soon as I got out of the car I was
in while designing the system, would have allowed 2^n - 1 challenges to
be created from n pieces of summary data, which wasn't too bad.
The hash-based method, which several posters suggested, had occurred to
me. I'd also thought of (and been reminded of) a simpler system whereby
Alice simply remembers a number of bytes in the file and their offsets
>
> If you want a one-shot solution, here's a very simple protocol:
> Last week:
> B->A: M
> Alice picks h randomly from H, a family of 2-universal hash functions,
> computes h(M), and stores it.
> This week:
> A->B: h
> B->A: h(M)
> Alice checks that the hash Bob sent matches what she stored last week.
> Cost: O(1) storage, O(1) bandwidth. Bob's computational workload is
> not so bad -- essentially, the cost to read M in from disk again.
>
> If you know in advance that you'll want to repeat the verification
> protocol n times, Alice can pick h_1,..,h_n, etc. Cost: O(n) storage,
> O(1) bandwidth per verification.
And, unfortunately, O(n) effort up front by Alice, which I didn't really
want to require.
The context of this protocol is backup server dealing with a (possibly
large) number of clients. The idea behind it is that, while it's nice
for a client to be able to inform the server that an old file is still
present without pointlessly sending it over the network (and so still
needs to be backed up) this can be abused by clients attempting to use
the backup server as a remote filestore. Since the server is trying to
cope with large numbers of clients, and possibly has the files only on
some inconvenient and slow medium such as a tape, it's nice to have some
method by which the server has an easy ride but the client has to do
lots of work.
> The (exceedingly clever!) protocol you proposed has the nice property
> that it has O(1) storage and O(1) bandwidth per verification, and the
> verification protocol can be performed any number of times. However,
> the tradeoff is that Bob's computational costs get noticeably higher.
Indeed. Sufficiently much higher that the protocol is impractical. I
think we'd decided to do without the protection this protocol might
offer anyway, so that's not really a problem.
> Note that there are ad-hoc tradeoffs that, in practice, probably allow
> to reduce Bob's computational workload without hurting security too
> much. Divide the message into d pieces, M_1,..,M_d. Last week, Alice
> should have stored an independent verifier for each piece. This week,
> Alice picks an index i in {1,2,..,d} at random, sends i to Bob, and
> executes the verification protocol on M_i with Bob. For higher
> confidence, this may be repeated r times. The result is that Alice's
> storage costs are increased by a factor of up to d, bandwidth per
> verification goes up by a factor of r, and Bob's workload goes down by
> a factor of d/r.
>
> The security analysis of the above ad-hoc mechanism is a bit more
> complex. Suppose Bob wants to fool Alice, and is willing to use
> storage space proportional to a fraction p of the size of M. Suppose
> that the original original verification protocol has probability q of
> error. Then the probability that Bob fools Alice in the modified
> variant is at most (p(1-q)+q)^r, which goes as something like p^r if q
> is small. Thus, to obtain some fixed security level, it suffices to
> take r = O(1/log(1/p)).
Hmm. Yes, that's useful. Thanks.
-- [mdw]
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 24 Jul 2000 12:17:07 +0100
On Thu, 20 Jul 2000, Scott Fluhrer wrote:
> <[EMAIL PROTECTED]> wrote in message news:8l6v3n$je5$[EMAIL PROTECTED]...
>
> > AOTP-Alex One Time Pad stream cipher.
> >
> > Performance of this implementation is 190 Mb/sec.
>
> - Your performance measurement "190 Mb/sec" is approximately completely
> meaningless. Is this MBytes/second or MBits/second? What hardware platform
> was this on? If it's 190MBytes/second on an 6 MHz IBM AT, well, I'm quite
> impressed. If it's 190MBits/second running on a 2000MHz Itanium, I'm not.
> One idea would be to normalize your measurements into cycles per byte
> encrypted. This number isn't the be all and end all of performance
> measurements, but at least it cancels out some of the variances due to CPU
> clock speed
when people post performance values, they should state the performance of
their machine. may i suggest that they quantify this with the integer
score from BYTEmark:
http://www.byte.com/bmark/bmark.htm
there are exes for PCs and source which should hopefully compile on other
platforms. BYTEmark seems to concentrate on CPU-based work, ignoring
memory or disk speed, and does include stuff which isn't very
crypto-oriented. it is a good general measure of speed, though.
tom
------------------------------
From: [EMAIL PROTECTED]
Subject: AESC-stream cipher
Date: Mon, 24 Jul 2000 12:10:17 GMT
Due to request to change the name of algorithm.
Relates to the thread 'new stream cipher'.
AESC-Alex Ernst Stream Cipher.
Performance of this implementation is 190 Mbyte/sec.
It was measured sending 256 byte in loop 777215 times.
Description.
Idea of this algorithm goes up to Vigenere cipher.
Plain text stream is a sequence of bytes.
Key stream is generated as stream of words but it
is used for encryption as stream of bytes.
Key has length 256 byte.
Vigenere Tableau is implemented as multiplication table
of finite group of the order 256.
Key stream is generated using finite group of the order
65536 and chained encryption.
Key schedule.
1. A key is interpreted as sequence of automorphisms of 256-group.
2. The key is interpreted as sequence of automorphisms of 65536-group.
3. The key is a start segment of key sequence generation using
65536-group and chained encryption, which may be called as
Quasi One Time Pad.
Encryption.
Byte of input plain stream and byte of key stream are
operands of group law of composition.
This gives one byte of output cipher stream.
Decryption.
Byte of input cipher stream and inverse to byte of
key stream are operands of group law of composition.
This gives one byte of output plain stream.
Delphi source code, EXE, description in pdf and
description to view online are available at
www.alex-encryption.de. Please follow links for 'AESC'
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: Can Anyone Recomend A Good Intro Text
Date: Mon, 24 Jul 2000 12:37:26 GMT
On Mon, 24 Jul 2000 02:58:31 GMT, Wade Reiber <[EMAIL PROTECTED]>
wrote:
>I'm looking for a good introductory text on crytography. Any recommendations?
>The best one I've seen so far seems to be Bruce Schneier's "Applied Cryptography".
Two introductory texts with nice exercises (in my opinion):
_A Course in Number Theory and Cryptography_ by Neal Koblitz
_Cryptography: Theory and Practice_ by Douglas R. Stinson
Two number theory books with chapters on cryptograhy:
_Number Theory in Science and Communication_ by M.R. Schroeder
_Number Theory with Computer Applications_ R. Kumanduri and C. Romero
A book with a chapter on public-key cryptography:
_Prime Numbers and Computer Methods of Factorization_ by Hans Riesel
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: "Bob Kow" <[EMAIL PROTECTED]>
Crossposted-To: alt.video.vcr,alt.2600
Subject: Re: VCR+
Date: Mon, 24 Jul 2000 12:43:37 GMT
If you can copy/paste this entire URL, you can find a calculator for what
you want. If you have a problem with that, just log on to www.ask.com
which is ASKJEEVES and ask the question there. That's how I got it.
http://www.ask.com/main/metaAnswer.asp?metaEngine=directhit&origin=0&MetaURL
=http://www.winternet.com/~gginc/java/vcr1.html&qcategory=sci_&metaTopic=G&G
+Inc's+VcrPlus(TM)+Pluscode+Java+Page&ItemOrdinal=0&logQID=A41E9F19E054D411A
7AF009027737F04
=======================================================================
(<[EMAIL PROTECTED]> wrote in message news:8l4hsn$qb3$[EMAIL PROTECTED]...
> Is there any publicly available software tool that can generate the
> VCR+ code?
>
> Bon.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
** 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
******************************
