Cryptography-Digest Digest #388, Volume #12 Wed, 9 Aug 00 14:13:01 EDT
Contents:
Re: Multiple encryption passes (Terry Ritter)
Re: Sci. Crypt cipher contest and Chutzpah ([EMAIL PROTECTED])
Re: Physical RNG ("CMan")
Re: Crypto and CCTV ("Jamie")
Re: Not really random numbers (Mark Wooding)
Re: IDEA's current security (Stephan Eisvogel)
Re: OTP using BBS generator? (Mok-Kong Shen)
PKCS#7 ("Kevin Crosbie")
Re: Sci. Crypt cipher contest and Chutzpah ("Paul Pires")
Re: Software license software with PK ???? ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Multiple encryption passes
Date: Wed, 09 Aug 2000 16:25:52 GMT
On Wed, 09 Aug 2000 11:19:19 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt ArchimeDES
<[EMAIL PROTECTED]> wrote:
>On Fri, 04 Aug 2000 22:18:18 GMT, AllanW <[EMAIL PROTECTED]> wrote:
>[...snip...]
>>My proposal is to use more than one pass through the data
>>when encrypting it. The first pass would take the plaintext
>>and produce the first ciphertext, which I will call C1.
>>Nothing in C1 would indicate which algorithm was used to
>>create it.
>[...snip..]
>>Again, nothing in C2 would indicate which type of encryption
>>was used. And so on until we feel that the data is secure
>>enough.
>Security by obscurity?
>Hmmm, the security of a cryptosystem is not given by the secrecy of
>the algorithm used, only by the secrecy of the key (Principle of
>Kerckoffs).
Presumably, cipher selection would be part of the key.
It would be known that the system used multiple different ciphers.
The group of ciphers from which some would be selected also might be
known. But the particular ciphers selected for use at a particular
time need not be known, because that could (should) be keyed.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Sci. Crypt cipher contest and Chutzpah
Date: Wed, 09 Aug 2000 16:15:38 GMT
In article <_n_j5.4522$[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
> It's been a little more than 10 weeks since Chutzpah was posted to the
> Sci.Crypt cipher contest. I was trying to impress everybody with my
> self-control and not chum for comments. I would appreciate comment on
this
> cipher if anyone has read it and are so inclined.
>
Sir,
I think the lack of comments stems from two sources.
1. The cipher is quite complex
2. The cipher has an unusual structure i.e. stream/block mix
I have taken a look a Chutzpah and found it to be quite confusing to
analyze. No doubt this is a problem with my abilities and not the
cipher :-)
My usual tatic for analysis of a block cipher is to start with a
plaintext and trace the evolution to the cipher text. Since the cipher
uses IV and state variables this method is of less use.
In particular, I found it difficult to visualize the internal state of
the cipher given your analog to a pyramid. I gave it a few hours and
then gave up. I certainly didn't find anything wrong but I don't think
that I fully understood the cipher either.
As a bit of consolation, I think my entry, Vortex, had the same problem.
In an effort to make it secure, I created an f() function the is pretty
complex. I believe the complexity of the function caused many people to
give up early. David Wagner was the only one to give it serious
consideration. I am happy to report that all of his objections were
answered by my design.
Tom's ciphers and Mark's Storin has received a good bit of analysis due
to the simplicity.
As for the 'crack my cipher' posts, I can usually spot a flaw by merely
-reading- the post. Finding a crack is usually quite simple thus you
get a lot of comments.
-Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Physical RNG
Date: Wed, 9 Aug 2000 09:31:54 -0700
Exactly, but a lot cheaper and you don't have to maintain all those hot
lamps and pay for all that electricity (especially in California where there
is not enough electricity because of the "not in my backyard" attitude of
the local left wing pinko commie greens). With the suspended AOL disks, a
25 watt desk lamp and a breeze from the window supply all the power
required.
:--)
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Tom Anderson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 9 Aug 2000, CMan wrote:
>
> > Take a few of those AOL CD's you get in the mail and suspend them from
> > strings. Shine a lamp or two on the scene while a fan blows them
> > around. Snap a few pictures with you USB webcam. Whiten the results
> > by hashing the video data.
>
> reminds me of lavarand:
>
> http://lavarand.sgi.com/
>
> they use pictures of lava lamps to generate random numbers, which is
> pretty cool. they work by temperature differentials, you know, but i
> understand that they're not impossible :).
>
> tom
>
> ps oh, for funk's sake:
>
> <quote src="http://lavarand.sgi.com/cgi-bin/how.cgi">
> Step 4: Seed a pseudo-random number generator
>
> The 140-byte value gets fed through the Blum Blum Shub ...
> </quote>
>
> WILL THIS MADNESS NEVER END?
>
------------------------------
From: "Jamie" <[EMAIL PROTECTED]>
Subject: Re: Crypto and CCTV
Date: Wed, 9 Aug 2000 17:35:39 +0100
The mechanisms to scramble video does exist.... and i assume it runs in
realtime... sky tv make use of such technology every day. Yes i know it can
be cracked ... people have told me that hacked sky viewing cards are quite
easy to buy (!!!lol!!), or from a different point of view digital
cam-corders just generate a bit stream.... and a bit stream is a bit stream
is a bit stream... so ripe for any cyphering technique you choose.
Tampering is a non-issue here, as soon as encryption is used (to prevent
unauthorised viewing) then a signing algorithm to detect tampering is not
much more effort to implement. Public key encryption is not even nessecary
and maybe too slow anyway. Since in real life only one trusted authority is
needed to install the cameras, encrypt and record the video, store the
recording tehn make it availabe when required by the police/courts... who
ever parliament gives such authority to, then a symetric cypher is ideal.
In alprobablity the technology is withing the grasp of the average person
today.... the camera's are all over the place already, an mpeg2 hardware
compressor for a pc costs less than £500. Software to record the captured
video into files tends to come free..... Links to software to encrypt and
sign files on a pc can be found all over these news groups...and finnaly
there have been solutions to back up files for archive since one day after
the first computer crash (lol). It would take the best part of one hours
effort to put such a system togeather for a cometant IT worker.
The question on blackmail is much more significant, simplistic answers along
the lines of let everyone see everything must be dismissed after all, any
right you have to know what i'm doing is balanced by a right i have to keep
my own afairs private. If a tape shows your wife kissing a stranger who
should see the tape? When do moral issues and legal issues meet? Even when
the police are involved there are guidelines requireing that such tapes only
provide information in answer to a specific question that is posed before
the tapes are viewd.
To my mind the human issue is almost always more complex than the technology
issue and technology doesn't as a rule solve "people problems" only people
can solve people problems
Jamie
"Tom Anderson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 9 Aug 2000, Dave Foulger wrote:
>
> > With the rise (especially here in the UK) of public CCTV surveillance
>
> i assume by this you mean CCTV surveillance of public places, eg streets,
> railway stations, shops, etc. places anyone can enter. this assumption
> underlies the rest of this post ...
>
> > I have been thinking about how encryption systems could help with 2 of
> > the worries I have.
> >
> > 1) Unauthorised use of CCTV material. (Blackmail, unauthorised release
to
> > press etc.)
>
> this worry seems to imply that you think CCTV recordings should be private
> information - held only by the police, council, or some other hopefully
> trustworthy public body. now, given that these are recordings of things
> which happened in public, why do you think this?
>
> this comes from a suggestion i read of (in Wired, hence the rather dotty
> libertarian-style point of view) which addresses both your worries. this
> was that CCTV output should be broadcast on public TV (there are plenty of
> unused channels, and most transmissions could be very local). this ensures
> that everyone knows everything (so there is no possibility of blackmail)
> and there cannot be any tampering, as everyone has seen it in its original
> form (provided there is no tampering with the signal between camera and
> broadcast; i imagine such tampering would be rather hard to do, especially
> if the delay between capture and broadcast was verifiably short).
>
> i don't think i'm seriously suggesting this; there is a simple answer to
> the question i posed, about publicness, which is that whilst the
> information is in principle [1] public, it is in practice not, as nobody
> except the state can be everywhere at once, and this is an unwritten
> assumption in our social structure blah waffle etc.
>
> > 2) Tampering with evidence (Given the general poor quality of the
> > video image and often static background I imagine that the average
> > desktop PC could now fake video evidence such as pasting someone
> > walking across the frame or changing the date/time info)
>
> if you don't like public CCTV, try this: the CCTV authority publishes
> signed hashes of the footage *in real time*. if someone brings up suspect
> footage, you can hash it and check the hash against the published version.
> if there is a mismatch, then the suspect footage cannot be correct - it is
> either altered or shot at a different time or place.
>
> > The idea I have in mind would involve encrypting the video as it is
> > recorded (on digital video tape, recordable dvd or any other medium).
> > I think that some form of public key system might work. The public key
> > for encryption would be stored on the video recorder, on a smart card
> > or something similar so it could be updated if the private key is
> > compromised) . The private key (or keys if using secret sharing) to
> > decrypt the video would be held by say one or more senior police
> > officers).
>
> this addresses your first point, but doesn't really secure against direct
> interference with the hardware, failures of key secrecy or high-level
> corruption. hardware security would best be addressed by making the
> cameras digital, and putting the encryption right in the package -
> tampering with this could not be cheaper than just installing another
> camera next to it, which would have the same effect. human error and
> corruption could be addressed by a layer of secret sharing; one key is
> needed to encrypt the data and two (or N) to decrypt; the recorder/camera
> has the encryption key, and the public keys are shared by the police,
> council, home office, MI5 and various trustworthy bodies such as the
> courts, Charter 88, the law society, Amnesty, the stand.org.uk people,
> etc. thus, footage could not be accessed without the involvement of people
> we trust, possibly several people we trust. if you don't want the
> trustworthy bodies to actually see the footage, wrap it in another layer
> of encryption before putting the shared-secret stuff over it, and only let
> the police, home office or (best of all) the courts know the key.
>
> this would pretty much demand specialised encryption hardware, which might
> have the side effect of making it cheap enough for the rest of us to use!
>
> > I would like the video recorder to sign and timestamp the video as it is
> > recorded to prevent forgery.
> >
> > How do the group feel this could be done? A sealed signing key built
into
> > the recorder?
>
> the crucial bit is to publish the signed info, so that it can be publicly
> verified.
>
> tom
>
> [1] is that principal or principle? i assume the latter, but both meanings
> make some sense ...
>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Not really random numbers
Date: 9 Aug 2000 16:38:11 GMT
Jamie <[EMAIL PROTECTED]> wrote:
> 2 The period must be greater then 2^^20
> (So numbers generated dont repeat)
Are you sure you need a period that long?
Note that m ^^ n = m ^ m ^ m ^ ... ^ m, where there are n m's.
n 2 ^^ n
1 2
2 4
3 16
4 65536
5 2^{65536} = 2003529930406 ... 895905719156736 (19729 digits)
6 2^{2003529930406 ... 895905719156736} !
In order to construct a generator with a period n, it must have at least
n possible states. This requires log_2 n bits of storage.
When you find a universe with enough particles to store 2 ^^ 19 bits,
please let me know.
Or did you type an extra `^' by accident? ;-)
-- [mdw]
------------------------------
From: Stephan Eisvogel <[EMAIL PROTECTED]>
Subject: Re: IDEA's current security
Date: Wed, 09 Aug 2000 19:02:34 +0200
Runu Knips wrote:
> IDEA (1992) isn't much older than Blowfish (1994), and
> because its proprietary it doesnt get as much analysis
> as Blowfish I think.
I don't remember where I read this but before AES candidates
appeared, IDEA was No.2 of *the* most crypt-analyzed
algorithms (right after DES).
You could argue the drawbacks (weak key classes, patented,
the frequent MULs) are significant, however I would counter
this by saying: weak keys are easily avoided [1], if you need
it for a commercial project the royalties are small, and if
you have a CPU with no h/w MUL you need to buy a good one.
The authors even bothered to put out an update to IDEA which
eliminates a timing side-channel attack.
Call me an IDEA zealot, I appreciate the beating IDEA took,
the small number of rounds it requires, and the beauty of its
design which doesn't squeeze security out of ugly s- and
p- boxes, but destills it from algebra alone.
> Well, your choice.
Indeed.
Stephan
[1] see Schneier AC2, p.323 bottom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Wed, 09 Aug 2000 19:23:25 +0200
David A Molnar wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> > I'm confused...
> > a) If the factors of the modulus ARE congruent to 3 mod 4, then are
> > short cycles likely, unlikely, possible, or impossible?
> > b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what?
>
> A long time ago I built a BBS generator in Scheme. I found that
> there were varying cycle lengths when using a modulus n = p q with p and q
> congruent to 3 mod 4. When p or q were congruent to 1 mod 4, or not
> actually prime, then I ended up with an alternating 0-1-0-1-0-1 output.
> You can try this yourself if you have a favorite programming language
> with bignums; building a BBS generator doesn't even require modular
> inversion.
I find the phenomenon you observed fairly interesting. It
means that in this case there is a (sufficiently long)
sub-sequence of the output with numbers alternating between
even and odd. Wouldn't it be conceivable that there be also
(sufficiently long) sub-sequences of all even numbers or
all odd numbers, giving rise to 00000.... or 11111....,
though these has not been observed in your experiments?
Anyway, in any such situation the statisticl quality of the
bit sequence could evidently be considered to be very poor.
Would the LSB of BBS, i.e. with p and q of the form 3 mod 4,
have, on the other hand, very good statistical quality? The
period length issue of the LBS sequence is yet to be confirmed
(see a previous follow-up of mine in this thread). But the
question of whether it does not contain sufficiently long
sub-sequences of the above mentioned or similar genre seems
to require elucidation too. I suppose one should probably do
some amount of experiments with the serial tests and Maurer's
universal statistical test. Until some such informations are
available it seems to be rather risky to use BBS in my humble
view.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: PKCS#7
Date: 09 Aug 2000 17:18:23 GMT
Has anyone got a good C implementation of PKCS#7?
I need to encapsulate a signature hash and certificate in PKCS#7.
Thanks,
Kevin
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Sci. Crypt cipher contest and Chutzpah
Date: Wed, 9 Aug 2000 10:25:47 -0700
<[EMAIL PROTECTED]> wrote in message
news:8ms031$sjm$[EMAIL PROTECTED]...
> In article <_n_j5.4522$[EMAIL PROTECTED]>,
> "Paul Pires" <[EMAIL PROTECTED]> wrote:
> > It's been a little more than 10 weeks since Chutzpah was posted to the
> > Sci.Crypt cipher contest. I was trying to impress everybody with my
> > self-control and not chum for comments. I would appreciate comment on
> this
> > cipher if anyone has read it and are so inclined.
> >
>
> Sir,
>
> I think the lack of comments stems from two sources.
>
> 1. The cipher is quite complex
> 2. The cipher has an unusual structure i.e. stream/block mix
>
> I have taken a look a Chutzpah and found it to be quite confusing to
> analyze. No doubt this is a problem with my abilities and not the
> cipher :-)
Not so! I have made a living by exploiting a mis-wired brain and am familiar
enough with it to know that I don't relate ideas well. Time again I come up
with a "brilliant write-up" and wach everybody scratch their head and say
"Huh?". It's a mystery to me. Ever diligently pursue a goal and just bomb
out?
>
> My usual tatic for analysis of a block cipher is to start with a
> plaintext and trace the evolution to the cipher text. Since the cipher
> uses IV and state variables this method is of less use.
>
> In particular, I found it difficult to visualize the internal state of
> the cipher given your analog to a pyramid. I gave it a few hours and
> then gave up. I certainly didn't find anything wrong but I don't think
> that I fully understood the cipher either.
Thank you for the feedback. I shot myself in the foot here didn't I?
I don't know if it helps but the tetrahedron (pyramids have 5 sides) is just
to show how the key substitution table was constructed. It's a justification
for the values being there and that is all. The tables themselves are just
lookups. But you probably figured that out.
I have much more material (graphs, charts and what-not) that I culled out
because the paper was getting way too big. I could post that too but I think
it would be the second shot to the foot and not a cure :-)
>
> As a bit of consolation, I think my entry, Vortex, had the same problem.
> In an effort to make it secure, I created an f() function the is pretty
> complex. I believe the complexity of the function caused many people to
> give up early. David Wagner was the only one to give it serious
> consideration. I am happy to report that all of his objections were
> answered by my design.
I have more work to do. The number and type of operations are not complex
but relating what they all do together in cooperation is still lacking. Each
operation is simple but describing what it does, in cooperation, to the
whole is not that straight-forward. Kinda like crypto.
>
> Tom's ciphers and Mark's Storin has received a good bit of analysis due
> to the simplicity.
>
> As for the 'crack my cipher' posts, I can usually spot a flaw by merely
> -reading- the post. Finding a crack is usually quite simple thus you
> get a lot of comments.
>
> -Matthew
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Software license software with PK ????
Date: Wed, 9 Aug 2000 11:07:42 -0700
I hate to be the bearer of bad news, but to the best of my knowledge, there
are no public key algorithms that do not inflate the size of the encrypted
data. The closest you could get would be something like a ECC exchange
(about 160-bits) used to encrypt a couple of blocks of a block cipher of
your choice. Total: around 500bits (2 public keys, one for each side, and a
128-bit encrypted block) and reasonably secure. You could slim it down
various ways, by having the program generate a new ephemeral key every time
a certain part is run, and storing your key long-term in the program. That
way all that needs to happen is the user sends their public key with the
registration, and you send them the block encrypted with the semi-ephemeral
key, so you only send the block ciphered data,but the complete transfer is
inflated by the clients public key.
Joe
"Benny Nissen" <[EMAIL PROTECTED]> wrote in message
news:KBbk5.11515$[EMAIL PROTECTED]...
> Hi All
>
>
>
> My background is the need for a good public key library implementation to
>
> do software license software (will make a hackers key-generator useless).
I
>
> am unable to use RSAREF because it output the same size (crypt text) as
>
> the modulus size, and this make the output far too big compared to my
>
> needs (if I like to make it secure)
>
> I need a public key encryption algorithems that maintain the same size
>
> public encrypted as decrypted (as with most block cifers).
>
> The plain text document will be known, and also the public key will be
>
> known. Then a test will see if the encrypted version match the plain text
>
> version.
>
> I do not know if this is possible in some way with Elliptic Curve
>
> cryptography or other PK algorithems?
>
>
>
> Thanks
>
> Benny Nissen
>
>
>
------------------------------
** 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
******************************
