Cryptography-Digest Digest #207, Volume #12 Tue, 11 Jul 00 21:13:01 EDT
Contents:
Re: Random Numbers ("Paul Pires")
Re: Q: Hadamard transform (Tim Tyler)
equivalence of semantic security and indistinguishability in general? (David A
Molnar)
Re: Steganographic encryption system (Steve King)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Proposal of some processor instructions for cryptographical applications
(Michael Dales)
Re: SecurID crypto (was "one time passwords and RADIUS") ("Trevor L. Jackson, III")
Re: SecurID crypto (was "one time passwords and RADIUS") (David A. Wagner)
Re: exports? (Bill Unruh)
bank vault security (was Re: SecurID crypto (was "one time passwords and RADIUS"))
(Eric Smith)
RC4-- repetition length? (Bill Unruh)
OTP's again ("sbh78")
Re: cray and time needed to attack (Jerry Coffin)
Re: Steganographic encryption system (phil hunt)
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Random Numbers
Date: Tue, 11 Jul 2000 15:28:42 -0700
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 11 Jul 2000 09:12:16 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote, in part:
>
> >I don't know whether it is (or easily) possible to prove rigorously that
> >your procedure is exact. I would simply throw away the out of range
> >values.
>
> Oh, it is quite possible.
>
> Let us say that I want numbers that are from 0 to 999, and I have a
> source of numbers from 0 to 2056.
>
> If every number from 0 to 2056 is equally likely, then it does
> immediately follow:
>
> taking the last three digits gives you a number from 0 to 999 that is
> unbiased, because 0 and 1000 together are just as likely as 1 and
> 1001;
<Snip>
This doesn't pass a sanity check for me. That by itself means nothing. BUT,
Taking the last three digits is like doing mod 1000 and it seems that if the
mod and the number being operated on don't have common prime factors, then
it is biased. Consider that 0 to 2000 have 2 "hits" on all numbers from 0 to
999 but the numbers 0 to 56 have an extra hit from the 56 remainder. So for
every 2056 numbers processed you could expect to see the values of 0 to 56
three times but could only expect to see 57 to 999 two times.
Did I misunderstand your post?
Thanks,
Paul
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: Hadamard transform
Reply-To: [EMAIL PROTECTED]
Date: Tue, 11 Jul 2000 22:13:33 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: There exists 2-D Fourier transform. Does anyone have literature
: pointer of an analogous 2-D Hadamard transform? Thanks in advance.
No references, but:
An ordinary 2D Fourier transform may be considered to be composed of a
series of 1D tranforms, treating first the rows and then the columns.
i.e.:
---- ||||
---- ...and then... ||||
---- ||||
---- ||||
This can be done with other types of 1D transform.
One thing to note is (I believe) that the linearity properties of the
Fourier Transform mean that the order of application is of little
relevance. This may not be so for other transforms.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: equivalence of semantic security and indistinguishability in general?
Date: 11 Jul 2000 22:33:31 GMT
In public-key cryptography, we have a definition of security based on
the indistinguishability of ciphertexts, and a definition of "semantic
security." For that setting, the two definitions are equivalent. The
recent paper by Katz & Yung on private-key cryptography notes that
this equivalence is also the case in that model.
In the setting of AONTs, Boyko's paper gives two definitions based on the
idea of indistinguishability, and one based on the idea of semantic
security. No equivalence between indistinguishability and semantic
security is proved in the paper and it's left as an open problem.
So we have one setting where "indistinguishability == semantic security"
and one setting where "indistinguishability ?= semantic security."
Are there any settings where we can show "indistinguishability != semantic
security" for reasonable formal definitions of 'indistinguishability'
and 'semantic security' ?
thanks,
-David
------------------------------
Date: Tue, 11 Jul 2000 16:15:38 +0100
From: Steve King <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
John Winters wrote:
>
> In article <[EMAIL PROTECTED]>,
> phil hunt <[EMAIL PROTECTED]> wrote:
> >
> >Not at all. For example, I could encrypt 3 texts, of size 1k, 5k, and 10k,
> >and if the resultant cyphertext file was 30k, I'd have plenty of room to
> >hold them all. (Different bits of the cyphertext file code for the
> >different plaintexts).
>
> Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
> might keep you busy.
>
Surely you would make sure that the one the FBI would see the 10k one, and
the relly secret one, that you were interested in was 1k.
Not very efficient, but Top Secret stuff doesn't normally occupy a lot of
disk space.
--
Steve
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 23:57:12 +0100
Reply-To: [EMAIL PROTECTED]
On Tue, 11 Jul 2000 12:59:37 +0100, Sam Simpson <[EMAIL PROTECTED]> wrote:
>phil hunt <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Mon, 10 Jul 2000 22:51:37 +0100, Garry Knight
><[EMAIL PROTECTED]> wrote:
>> >In article <[EMAIL PROTECTED]>,
>> >[EMAIL PROTECTED] says...
>> >>I am thinking of developing a steganographic encryption system
>> >[...]
>> >>(1) does anything like this exist already?
>> >
>> >ScramDisk (for Windows) incorporates this kind of technology.
>> >http://home.clara.net/scramdisk/
>>
>> Scramdisk is quite interesting. Unfortunately it doesn't work with
>Linux.
>
>Funny you mention it - we're currently building a Linux driver to
>mount / create scramdisk containers. We expect working code
>(Blowfish / container files only) working soon.
Will it appear as an extra filesystem on linux, from a mount point?
>> It's quite similar to what I'm trying to do, except that it only
>>accepts
>> one valid decryption key.
>>
>> It's released under a wierd almost-open-source license; the license
>> says
>> you can't distribute modified versions, but then goes on to say
>> that if
>> you do, you must give them a copy.
>
>You're right - the license does need clarifying. We basically say:
>"you can use it freely, but you can't sell it or sell modifications
>of it".
One problem with that sort of license is that it cannot appear in
a Linux distro (because distros are usually sold). Perhaps you might
consider relaxing that requirement? -- The software would certainly see
more users if it was included with SuSE or Red Hat.
If you want to make money on your software, perhaps you could instead
have a requirement that people can only use it for personal not-for-
profit use, otherwise they have to pay you money for using it.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 23:58:52 +0100
Reply-To: [EMAIL PROTECTED]
On Tue, 11 Jul 2000 15:55:15 +0100, Jim Howes <[EMAIL PROTECTED]> wrote:
>John Winters wrote:
>>
>> Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
>> might keep you busy.
>>
>> John
>
>No, it's explained easily. The user has written a 1k message
>using Microsoft Word
:-)
ObBashBillG:
I once had a smallish (10 pages) Word document. The file was 100K.
When I made minor changes to it, it became 200K. When I exported it to
RTF, it became 2000K.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (Michael Dales)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
applications
Date: 11 Jul 2000 23:39:17 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
>
>Michael Dales wrote:
>
>> Hmmmm. In your original posting you said you were providing suggestions
>> for "future processors" - thus what's to stop Processor/FPGA hybrids
>> becoming common in the future? Do you know something we don't? ;-) The
>> rate at which acceptance of FPGAs is increasing suggests that
>> reconfigurable logic will become common place in the not too distant
>> future.
>
>I do believe that a computer with reconfigurable logic can indeed be
>desirable in certain situations. One issue that I think could be essential
>is that the programming should be relatively easy, i.e. there need to
>be good tools to support the user without much hardware expertise
>to do the job, which I was told is not quite yet the case with FPGA.
Again, hmmm. You're generally right - it's typically more complicated to
design and implement circuits than it is to design and implement software,
but think for a moment about the context of this discussion. The
instructions requested by you originally won't be automatically used by
the compiler, just as compilers have a hard time of automatically using
SIMD instructions in modern processors - you generally need to bring in
a smart human to get the best effect. Tightly coding encryption algs.
certainly fall into this catagory. At the end of the day I believe
that we're willing to spend more time at design time to get the benefit
of a better run time. The level of circuitry design for custom
instructions to tackle this problem is actually minimal, and a burden
that I believe programmers will be willing to carry to get better
performance.
Nothing comes for free - having custom hardware gives you great
flexability, but you need put in the extra work get the custom
instructions.
Having said that, work has been done on making compilers which will
seek out parts of code that can be converted into circuits, both
commercially (Handle C for instance is a C compiler which generates
hardware) and in researchville. In some of the work I cited earlier
compilation of circuits will be made easier in that they take in
data from the register file and return it there - by constricting the
environment to such a tight definition you simplify the job of finding
and implementing circuits (look for small operations that take in
two words and generate a single word (typically)).
--
Michael Dales --- email: [EMAIL PROTECTED] --- tel: +44 141 330 6297
Department of Computing Science, University of Glasgow, Glasgow, G12 8QQ
------------------------------
Date: Tue, 11 Jul 2000 20:07:11 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: SecurID crypto (was "one time passwords and RADIUS")
Roger Schlafly wrote:
> "Trevor L. Jackson, III" wrote:
> > If you doubt that bureaucratic inertia and market forces lead to denial of
>insecurity
> > consider the reaction of the French banking system to claims that their security
>was
> > weak. They were furious about it, but denied it.
>
> Have the French banks lost any money resulting from the small
> size of their RSA modulus? If not, they perhaps the security
> was strong enough for their purposes.
Yes. My (incomplete) understanding is that the person who found the problem
demonstrated
that he could take money out at will. He did so (using trivial amounts).
Point is he _proved_ the system was insecure, but the banks refused to admit, in spite
of
the proof and his demonstration thereof, that there was a problem.
Customer testimonials tell us nothing -- literally no thing -- about cipher security.
After all OAP-L3 makes claims similar to those criticized here. Does any reader find
the
OAP-L3 claims of customer testimonials persuasive?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: SecurID crypto (was "one time passwords and RADIUS")
Date: 11 Jul 2000 17:11:51 -0700
Roger Schlafly <[EMAIL PROTECTED]> wrote:
> Have the French banks lost any money resulting from the small
> size of their RSA modulus? If not, they perhaps the security
> was strong enough for their purposes.
Would they know? Reliably, I mean.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: exports?
Date: 12 Jul 2000 00:14:41 GMT
In <lzLa5.2$[EMAIL PROTECTED]> "George Gordon" <[EMAIL PROTECTED]> writes:
>What's the deal with www.cryptography.org/source ? Do any of you other
>readers know ?
Go back to the parent directory and all is explained. They have all of
the good stuff in a hidden subdirectory of that directory, and you have
to swear that you are US or Cdn citizen etc before you are told what it
is.
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: bank vault security (was Re: SecurID crypto (was "one time passwords and
RADIUS"))
Date: 11 Jul 2000 17:37:05 -0700
Roger Schlafly wrote:
> You local bank probably thinks it has a secure vault, but
> it still doesn't go out of its way to advertise the specs on it.
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Actually they do. The security of money entrusted to them is a
> significant marketing issue. All those FDIC stickers serve the same
> purpose. And if you inquire about the vault they'll tell you about
> the vault (e.g., for safety deposit boxes), their security systems
> etc.
The bank is willing to tell you general things about the nature of the
security, because they want you to believe it's secure so that they
will get your business.
Start asking them for fine details or blueprints, and you'll get a
different response. They may be happy to tell you that they have an
XYZco alarm system, and maybe even that it's a model 1234, but ask them
for details of where all of the sensors are, or where the wires run.
They won't give you that information because you don't have any
legitimate need to know.
The bank vault is designed to be strong even against knowledgeable
attackers, but it *might* be even stronger against ignorant attackers, and
it's not in the bank's best interest to educate the attackers.
Obscurity can have *some* value, though only a fool would count on it
primarily or exclusively.
With crypto algorithms, it is generally advantageous to make the details
public, because you want to encourage cryptanalysis *before* you deploy
a gazillion instances of the algorithm. But the bank vault is (or at
least can be) unique. Making the *exact* design of the vault available
for public scrutiny is unlikely to turn up any vulnerabilities that
aren't just as easily found with a model that is generally similar but
different in the details. Whereas with crypto algorithms, those details
can be critical to the security.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: RC4-- repetition length?
Date: 12 Jul 2000 00:43:19 GMT
What is the repetition length of the RC4 cypher? is it 256! (the number
of states of the matrix) or 256^2 256! (the number of states of the
matix times the number of different states of the counters) or something
much less than these? Are any keys known to give a short rep length or
do all keys produce the same (ie a traversal over all possible
permutations)?
------------------------------
From: "sbh78" <[EMAIL PROTECTED]>
Subject: OTP's again
Date: Tue, 11 Jul 2000 19:53:02 -0500
Ok, I have seen some commercial OTP products but they all talk about
creating a large key file and transferring it to someone else so that they
will be able to decrypt the messages sent to them. Here is my question
can't the problem of key distribution for one time pads be solved by Diffie,
Helman and Merkle's scheme. Think about the alphabet as a mod 26 system.
Define a=1, b=2, c=3...z=26. Now, if we take 'd' and encrypt it with 'y'
then our encrypted letter should be 'c' if we wrap around. Basically a
ceasar shift of -1 right?? (I am relatively new to this so forgive me.)
Anyway, lets say Alice encrypts a message with a OTP and sends her message
to Bob who encrypts the message with an OTP and then sends that message back
to Alice who decrypts with her OTP and sends it back to Bob who now decrypts
it with his OTP to get the plain text. No keys were exchanged and the keys
that were used were random and as long as the message. It could be done
with all the ASCII characters so that any file could be encrypted. Would
this work? Is it not implemented because it is impractical to do? Any
thoughts?
Just Curious,
Stephen
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Tue, 11 Jul 2000 18:56:18 -0600
In article <8kfl9o$snr$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > Excuse me, but I always heard that electrical signals in a wire
> > propagate
> > at about 1/3 of the speed of light. That means that with that 10-20%
> > buffering slowdown, in .3 ns they can travel about 1 inch.
> >
> Now this reply is downright UNFAIR!
Not unfair -- just wrong!
> Imagine! Confusing Mr. Coffin with facts when he was convinced that
> only he was right.
What fact? The old rule of thumb is that electricity in a wire
travels at one foot per nanosecond.
That would mean that for his math to be correct, .3 (or perhaps .33)
would have to be equal to 1/12th. It's pretty pathetic for you to
accuse anybody else of arithmetic errors, and then claim that .3 is
anywhere close to equal to .0833.
Worse yet, you're ignoring reality still more: propagation delay
doesn't really have to have any effect anyway: preload instructions
can completely negate its effects from the overall speed, and they're
also well known in current technology.
In short, you've reached the point that it's clear that you're NOT
going to let anything similar to facts get in your way. You want to
have the last word, regardless of how badly it misleads anybody who
listens to you. Since you're so childish that having the last word
(even though we both know you're wrong) means something to you, go
for it: feel free to post again, and I won't bother replying. It's
gotten to the point that the facts (as well as your lies) are on the
table, and anybody else who really cares can figure out what's real
and what's not.
For those looking on, I'll add only one more important point: Mr.
Silverman, though he's an intelligent man, is also in a position to
be BADLY biased on this particular subject, so his words on it should
be taken with several truckloads of salt. Mr. Silverman's income is
obtained from RSADSI, which in turn derives much of its income from
the sale of patent licenses, toolkits, etc., implementing RSA
encryption. Much of the attractiveness of RSA encryption is based on
the fact that with sufficently small keys, it's faster than some
other forms of encryption. As such, if the general public realizes
that they need larger keys with RSA, Mr. Silverman is likely to
suffer dire financial consequences.
I wouldn't accuse him of lying, exactly, but I'll just say that
having seen (for example) football fans watching a game, it's easy to
see that people can sincerely believe things when they want to badly
enough.
To keep things balanced, I suppose I should mention my own financial
connections. Unfortunately, I don't really have any -- the only
possibility of my having any financial interest would be through a
mutual fund, and I have no idea as to which direction I'd benefit
from (who knows, I might even be losing something if RSADSI loses a
sale, but at worst I'm sure it's not enough that I care).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: phil hunt <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 02:12:52 +0100
On Tue, 11 Jul 2000, Frank Gifford wrote:
> In article <[EMAIL PROTECTED]> you write:
> >I am thinking of developing a steganographic encryption system that
> >will enable a particular cyphertext to be decrypted into two or more
> >different plaintexts, depending on which key is used. (Provisionally
> >named 'stes'). To be more precise:
>
> Hi.
>
> In a sense, you have what amounts to a tar/zip archive of crypto messages.
>
> You have to be careful in thinking about a "real" and "fake" key. For
> example, the police think you have an illegal .jpg file [involving
> minors] in the ciphertext. So you turn over the "fake" key, they get a
> love letter to your boss's wife. But they look at the raw file and realize
> that there is room to store about 25K more data.
The system will deliberately create ciphertext files bigger than the
plaintext. So if the plaintext is 1K, a 25K ciphertext is possible.
> They get a court order to force you to turn over the "real" key - or you
> will have some serious explaining to do in court to try and convince a
> jury that the remaining 25K is random garbage and not encrypted data. If
> the prosecution brings in a crypto expert who can show that the data is
> in fact encrypted
If I use the right algorithms, this should be impossible, right?
> - even if he can't break the code - you will be held in
> contempt of court and likely to be found guilty.
(Possibly not comtempt of court, but rather an offence under the RIP
bill currently going through parliament).
> >(2) What's a good private-key cypher algorithm to use?
>
> There are certain pitfalls with ciphers in this context. Assuming you use
> a block cipher, you have to consider the chaining mode.
What's a chaining mode?
> Then you have to
> think about the IV to go with it.
IV? Intra-venous??
> A strong cipher should be indistinguishable from random noise.
Agreed.
> But if two
> streams of data seem to have blocks of repeated data in them, that is an
> indication that a block cipher was used. This is what I'm thinking about
> in terms of a cryptography expert for the prosecution. Showing repeated
> data which are, say, 64 bits in length and multiples of 64 bits apart would
> be enough to show that it wasn't random data and that the likely explanation
> is that it is encrypted data.
This is infact what blowfish does (I've just checked it). But I thought
blowfish was a strong cipher? -- obviously I must be wrong somewhere here.
So how do I get it so it doesn't repeat?
> >* strong encryption -- no-one can crack it (what key size do I need for this?)
>
> For "uncrackable", 256 bits for a symmetric key system.
Blowfish is a max of 448 bits, right?
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
** 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
******************************
