Cryptography-Digest Digest #925, Volume #9 Thu, 22 Jul 99 11:13:03 EDT
Contents:
Re: RSA public key ([EMAIL PROTECTED])
Re: yet more about fibo generators ([EMAIL PROTECTED])
Re: Xor Redundancies ([EMAIL PROTECTED])
Re: Your opinion upon this crypto-algorithm! ([EMAIL PROTECTED])
Re: Algorithm or Protocol? ([EMAIL PROTECTED])
publuc key (John Xiao)
Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram) (Roger Fleming)
Re: Public Key =>? Trapdoor Functions? (John Savard)
Re: How Big is a Byte? (was: New Encryption Product!) (John Savard)
Re: Your opinion upon this crypto-algorithm! (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA public key
Date: Thu, 22 Jul 1999 12:13:21 GMT
In article <[EMAIL PROTECTED]>,
vincent <[EMAIL PROTECTED]> wrote:
> Sorry to ask you what would be an easy question if I was good in Math.
> If I always take the same very small exponent for the public key (for
> example 3) and I compute the private key with p and q (the prime
> numbers) big enough, do I limit the number of private key which will
> result from this computation ?
>
> Is it weak to do so, because obviously it would make the encryption
> faster (as well as the key generation) ?
Well I think the exponents must be 0 < x < n. So your modulus will
limit the number of private exponents yes. However with 1024 bit
moduli this becomes unreal.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: yet more about fibo generators
Date: Thu, 22 Jul 1999 12:11:22 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Wed, 21 Jul 1999 21:37:28 GMT, in <7n5eim$919$[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] wrote:
>
> >Getting loads of information about the generators ( :( ) I decided to
> >look into it myself. I found some interesting information though...
> >
> >The period of Additive Generators is the same as LFSR generators.
>
> False. See, for example:
>
> http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect7.2.4
Yeah but doesn't each bit have it's own period?
> Additive RNG periods actually have been known for well over a decade:
>
> 114. Marsaglia, G. and L. Tsay. 1985. Matrices and the Structure of
> Random Number Sequences. Linear Algebra and its Applications. 67:
> 147-156.
For the entire word output yes because we assume the period of the
msb. But my point is that other bits have other periods...
> If you cannot find this information in your favorite crypto books,
> perhaps you should complain to the authors.
Or in my case move to another city :)
>
> For one thing, you are missing an explicit definition of what you
> imagine "dense LFSR generators" to be.
>
> If you mean "LFSR's having many feedback taps," they are no stronger
> than LFSR's with few taps. Both are linear mechanisms and if we know
> the taps, their unknown state can be computed when we have that same
> amount of known plaintext (or, of course, more).
Then why are spare generators (See the PIKE paper) feared? If dense
generators are no better that will make life much simpler.
> I have long advocated and used a nonlinear filtering system after the
> RNG proper. The particular design I use I call a "jitterizer." One
> description is available in:
Question: Is the give/take register a counter or fixed?
Question: Is this generator quick?
My simple 'delay[rnga()] += rngb()'
(delay is a array of 256 bytes, rnga and rngb are additive generators
with two taps).
Runs at 8.5MB/sec on my MII 300 which is rather quick. (in C).
I will check out your site.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Xor Redundancies
Date: Thu, 22 Jul 1999 12:17:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> You're right sometimes the problem isn't money, but often a vendor's
rush
> to make it results in an easily broken proprietary cipher or a wrongly
> implemented strong cipher. What angers me is a vendor who promises
> "unbreakbility," or at least a strong cipher, yet knows he can break
> the encryption.
Well because they assume the user doesn't know any better.
> It's also true, as you say, that vendors tack on "security" as an
> extra in some programs: MS Word, PKZIP, etc. The utilities I
> was thinking about are "encryption" utlilities: Turbo Encryto, UBE98,
> FileLocker, Crypt-o-Text, and others.
Alot of crypto utilities out their are crap. I should know when I was
12 I wrote 'Zcrypt' which was a really fast autokey cipher. It worked
in my view but I didn't know any better. A lot of these peoples are
just ignorant and don't care.
I cought up with the author of 'Absolute Security' which is repeated
OTP cipher. Basically you take a 'secret' random file and add it to
the message. You share the file so you can send 100s of messages with
the same file. However I tried to point out that re-using the same
keyfile would lead to all sorts of attacks (I proposed three different
attacks I think...). He is still pretty sure of himself. Oh well...
Basically if I can't see the source I won't get the program. A lot
of 'secure' programs are just simple RNGs that are linear or
tractable. Another program 'The Vault' uses a totally secure hidden
method with 20 bit keys... :) etc...etc...
BTW where is the snake-oil faq and is it upto date?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Your opinion upon this crypto-algorithm!
Date: Thu, 22 Jul 1999 12:28:48 GMT
In article <7n5i83$agg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'd be interested in your opinions upon this crypto-algorithm
> It's similar to DES/GOST. I uses a "Feistel-network" too.
> Please don't flame me if it's bullshit!
Actually it's more like LOKI/DES to me. The problem now is:
a) is it any faster then say RC5/CAST/Blowfish?
b) is it any more secure then say RC5/DES/Blowfish/IDEA/CAST ?
You can propose as many ciphers as you want but unless it is 'BETTER'
it's not worth looking at.
BTW you are missing a description of the key schedule.
> I have a full specification written in TeX (with some flowcharts)
> and a implementation in C++ which can use Electronic Code Bock (ECB)
or
> Cipher Block Chaining (CBC) mode.
Super get a PDF or PS copy and we are in the game.
> 1. The 64 bit plainblock is split into two 32 bit blocks.
> The one will be called "L" the other "R".
> 2. R is expanded by an expansion-matrix, which doubles 16
> of the former 32 bits up to 48 bit.
Could this be done with linear mixing (see ICE for an example) instead
of LUTs? This would speed up the cipher quite a bit. You might want
to try linear permutations such as PHTs as well. You could eliminate
the expansion and do this
R' = R ^ round.key
(a,b,c,d) = R'
a' = 2a + b
b' = a + b
c' = 2c + d
d' = c + d
b''= 2b + c
c''= b + c
d''= 2d + a
a''= d + a
(a,b,c,d) = (a'',b'',c'',d'')
result = ((sbox1[a] + sbox2[b]) xor sbox2[c]) + sbox3[d]
This is easy in software and has nice avalanche since it's a
permutation (upto the sboxes anyways).
> 3. The expanded R is XORed with the actual 48 bit round-key
> from the key-repository.
Novel concept. You had inspiration?
> 4. The expanded and XORed R is split up into four 12 bit blocks.
Whoa... this is a copy of R or the actual R register?
> 5. Each of this four blocks is now used as an index into
> four substitution-tables (S-Boxes)
> Each S-Box contains 4096 32 bit values. The 32 bit values
> are unique over all S-Boxes.
I would have though to use 12x8 sboxes... How are the sboxes made? Key
dependant?
> 6. The XORed results of S-BOX1 and S-BOX3 is added to
> the XORed results of S-BOX2 and S-BOX4
> short:
> (result(SBOX1) XOR result(SBOX3))+(result(SBOX2) XOR result(SBOX4))
> the whole result is therefore a 32 bit block.
Ala blowfish?
> 7. The 32 bit result of step 6. is XORed with L
> 8. The result of step 7. is the new R and the old R is the new L
>
> The expansion-matrix (E-Box) is designed so that doubled bits act in
> different S-Boxes.
So would linear mixing (PHT for example).
> The keyrepository contains a 48 bit roundkey for each round.
>
> The number of rounds is variable in steps of 2 (beginning with 2).
> Therefore the keylength is variable (keylength = rounds*48bit)
Whoa... I wouldn't tought this as being a 768bit key for 16 rounds.
There might be iterative attacks. I would use a keyschedule instead.
Are there any whitening keys?
> Further info's are available by email
Super... one thing... you posted here!
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Algorithm or Protocol?
Date: Thu, 22 Jul 1999 12:39:44 GMT
In article <7n5kci$csq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> But algorithms aren't expressions; the general definition of
> algorithms that I've seen are something like "a defininite and
> finite sequence of steps"; what's the "expression" for a
> mergesort or beam-search algorithm?
True.. hmm maybe we need another definitions... anyways OT.
My point was is it more important to
a) create a protocol to solve a situation [1]
b) or create an algorithm and publish...
[1] Including offline (i.e you encrypt then send), online (video
conferencing), remote (purchases), etc... Obviously no one protocol is
entirely secure. It depends on who or what you trust. Obviously no
one protocol will solve all problems. However if protocols for such
situations were openily and readily explored we might have more secure
digital operations.
Some argue that you can hack at what you trust (i.e the card holder...)
however this is certainly true for ALL analogue protocols as well.
It's a good/evil factor...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: John Xiao <[EMAIL PROTECTED]>
Subject: publuc key
Date: Thu, 22 Jul 1999 07:43:21 -0500
Can anyone show me a sample of public key?
I know how the key works conceptually, but just can't get into detail.
Thanks.
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram)
Date: Thu, 22 Jul 1999 12:41:49 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John McDonald, Jr.) wrote:
>On Wed, 21 Jul 1999 11:31:20 GMT, [EMAIL PROTECTED] (Roger Fleming)
>wrote:
><snip>
[...]
>>CGI on it, which means that a simple HTTP GET request can actually be a
> command
>>to execute a program on your webserver, with parameters chosen by the
> attacker.
>>Oops. Suddenly IP filtering isn't quite so obviously foolproof.
>
>You make a good point, but with a BIG problem... CGI requires that the
>programs are on the web machine. (Or off of a link that can be
>followed from the server.) As a webmaster, I am not going to simply
>allow Joe User to execute just anything! I'm certainly not going to
>let him access rm, or other useful commands.
Of course not; I'm not suggesting that. You were saying that filtering packets
other than http means the attacker can't do anything. In fact with CGI he can
run programs. These programs are probably harmless but that remains to be
shown; a very different kettle of fish to assuming "no risk".
>Furthermore, the CGI has to be in a directory that is 'see'able by the
>webserver. Usually, this works out to be /home/http/cgi-bin/ on
>linux, or another directory, but NEVER /.
Assuming your permissions are all correct, and your OS doesn't have any
security holes accessible through the execution of your scripts. These
assumptions are probably correct, but once again it needs to be checked; the
firewall doesn't let you get away with ignoring it if you're serious about
security.
>The webserver does not allow you to backtrack beyond the scope of its
>directories, if it is properly configured.
>With that in mind, it takes an idiot to set up the webserver such that
>unwanted executables can be called by someone connected through the
>browser.
Well, there are plenty of idiots out there, then. It happens.
>The most widely used server, apache, even allows you (forces
>you) to specify *exactly* which directories the server is allowed to
>execute CGI from.
>
>Furthermore, a user does not execute these by using an HTTP GET. They
>simply place the command right on the location bar with the
>appropriate tags. For instance,
>
>www.yahoo.com/cgi-bin/search.cgi?search=yer+mom+in+yer+home
Which is submitted to the server with a GET. Not that it matters; I just
meant to point out that the commands to run these programs are nothing exotic
or unusual, nothing that can be blocked with simple filtering without parsing
the URL.
>(Note that this is only an example.)
>The reason there is a distinction is because a GET is what the server
>sends out and expects back, but if you watch your location when
>executing CGI, you will find that you do not need to actually view the
>preceding pages. (This is how askjeeves.com and other Super-search
>engines search other Search engines. Confused? Good. <g>)
>Once again, IP masquerading is foolproof... (As close as you get..)
>
>Incidentally, as far as validation of update content goes, this is not
>an especially difficult task, if you are using a *nix platform.
I think you misunderstand me here. I am not talking about authenticating the
user who makes an update. I am talking about a legitimate publisher uploading
the wrong content (accidentally). This is basically impossible on all but the
highest security OS'es, and not completely solvable even on those. On a
commercial site, you can say "Oh well, we screwed up", but that's really not
good enough if you just told all the world's terrorists how to make a better
doomsday virus. Really secure OSes have ways of checking that the uploaded
data is unclassified, but ultimately their classification falls back to a
human opinion based on limited information.
Also on larger sites, it is common to have the page content a collaborative
effort from a number of individuals. If malicious alteration is possible by
one of these users, you need to be able to audit who made any changes. This is
doable on standard OSes but it isn't trivial and is not usually done. Once
again, I'm not saying that this is an insuperable problem, just that the
simplistic claim:
"No world write access to hard-drive => perfectly secure."
is wrong.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Public Key =>? Trapdoor Functions?
Date: Thu, 22 Jul 1999 13:01:33 GMT
Coms 1003 <[EMAIL PROTECTED]> wrote, in part:
>Does semantically secure, probabilistic public-key encryption necessarily
>imply the existence of trapdoor one-way functions?
Well, does Diffie-Hellman encryption, for example, involve a trapdoor
one-way function? Not directly, but the encryption *itself*, including
the conventional encryption with the agreed-upon key, might qualify.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 22 Jul 1999 13:47:46 GMT
[EMAIL PROTECTED] (Finder Keeper) wrote, in part:
>But zero isn't the first number. It's the zero-th number.
>Michael D. ([EMAIL PROTECTED]) wrote:
>: I think that a major problem that we all have is that our mothers, yes, mine
>: as well as yours, taught us that the first number is one(1) rather than
>: zero(0). It was cute when we were three(3), but now, as a result of that
>: conditioning, we cannot do math in our heads.
Somehow, I think people do realize that zero, not one, is the additive
identity, and most people can do addition in their heads. And yet, it
is true that when I play cribbage, it is sort of confusing that if my
hand counts 8, I have to leave only 7 spaces between the pegs...but I
think that would be true regardless of what convention we used for
counting.
And it is true that one begins counting with the first object, and if
one has a first object, one has one object.
So if one wishes to count pebbles, one considers the first pebble
counted to be pebble 1, and that does not cause confusion.
Naturally, though, the first memory storage location one counts is
location 0, since we want to use all possible combinations that a
group of however many digits - binary, decimal, whatever - can refer
to. This is not a big deal for such a specialized application, and
cannot be "remedied" without creating more problems than it solves.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Your opinion upon this crypto-algorithm!
Date: Thu, 22 Jul 1999 13:54:10 GMT
[EMAIL PROTECTED] wrote, in part:
>I have a full specification written in TeX (with some flowcharts)
That would have been nice...
>2. R is expanded by an expansion-matrix, which doubles 16
> of the former 32 bits up to 48 bit.
>4. The expanded and XORed R is split up into four 12 bit blocks.
>5. Each of this four blocks is now used as an index into
> four substitution-tables (S-Boxes)
>From this description, for all I know you could be doubling the first
16 bits of the 32 bits, and then using the bits in order to produce
12-bit parts.
Presumably, this is not happening, and you are doing something like
what DES does (each 12-bit chunk contains eight original bits from the
32 bits, plus four doubled bits from two other bytes), but that isn't
specified. And that is a fairly important point.
Otherwise, you probably have a perfectly good algorithm, although it
is now believed that a block size of only 64 bits may be a weakness.
It's not too different from the algorithms - Khufu and/or Khafre -
that inspired Blowfish, but retaining the expansion permutation, a
feature of DES that Blowfish, at least, discarded _is_ likely a very
good idea.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
