Cryptography-Digest Digest #487, Volume #13 Thu, 18 Jan 01 12:13:01 EST
Contents:
Re: keeping secret keys secret -- revisited (Niklas Frykholm)
Re: Where can I find software tools for Known-text decryption ([EMAIL PROTECTED])
Re: Compression (Tom St Denis)
Re: SAC question (Tom St Denis)
Re: Where can I find software tools for Known-text decryption (Richard Heathfield)
[H] one-way hash functions (aWARe)
Re: block algorithm on variable length without padding? ("N. Weicher")
Re: block algorithm on variable length without padding? ("Scott Fluhrer")
Re: Where can I find software tools for Known-text decryption ("Douglas A. Gwyn")
Re: Comparison of ECDLP vs. DLP (DJohn37050)
Re: Compression ("William A. McKee")
Re: NSA and Linux Security (John Myre)
Re: block algorithm on variable length without padding? (DJohn37050)
Re: Comparison of ECDLP vs. DLP (DJohn37050)
Re: NSA and Linux Security (Shawn Willden)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: keeping secret keys secret -- revisited
Date: 17 Jan 2001 08:29:58 GMT
>About a week ago, I posted a message with an idea on how to make a web
>site keep data on it that was secure. In this case, it was for sharing
>data, and the way it worked was this:
>
>(a) each area has a secret key
>(b) that secret key is encrypted once for each user with that user's key
>...
>So the idea was to use a very secure passphrase (like the 5*12-bit pass
>phrase) and have the user send that every time that they want to encrypt
>or decrypt something (probably as a temporary cookie in an SSL
>connection.) The problem is that at some point, the server has a copy of
>the user's plain-text key.
>
>Short of using a software package other than a web browser on the
>client-side, is there any way to prevent the server from ever having to
>know the user's key? I, of course, want to authenticate users, but I am
>not interested in being able to decrypt their data -- ever.
Well, someone must decrypt the data. If you don't do it, they must do it.
If you insist on only having a web browser on the client side, this means
that you must write the decryption utility in JavaScript or send it as a
plug-in or Java program.
You can have separate keys for your authentication and their decryption,
but let them both be derived from the same passphrase. For example, let
H(p) give the authentication key and H(p || 1) give the decryption key.
Since you only see H(p), you will never know the decryption key.
But if the users are using your plug-in to decrypt they pretty much have to
trust you anyway ;)
// Niklas
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Where can I find software tools for Known-text decryption
Date: Thu, 18 Jan 2001 11:53:34 GMT
It is my understanding that when you know some of the test in a file,
the rest of the file can be decrypted.
don c
In article <Fgt96.90333$[EMAIL PROTECTED]>,
"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> If the text is known, why do you need to decrypt it?
>
> <[EMAIL PROTECTED]> wrote in message
news:945k4g$4a6$[EMAIL PROTECTED]...
> >
> >
> > Are there any availble software tools for Known-Text decryption?
> >
> > thank you
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Compression
Date: Thu, 18 Jan 2001 12:32:50 GMT
In article <[EMAIL PROTECTED]>,
"Adrian S. Thompson" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Does anyone know where I can find the algorithms for different
> compression utilities (gz, zip, rar blah...)? This would help me to
> write a program to find patterns in cyphertext files. I realize that
> some may be 'top secret' patented algorithms, but any pointing in the
> right direction would be nice.
Compression algorithms compress, they don't perform statistical tests
required by a cryptanalyst
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SAC question
Date: Thu, 18 Jan 2001 12:36:43 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > > In the normal definition of the Strict Avalanche Criterion (SAC), changing any
>input bit, or selection of input bits, should change each output bit with probability
>of 1/2.
> > >
> > > However, for an invertable function, there *must* be some bias. In the
>entry for SAC in Terry Ritter's glossary, he gives the example that for a 2 bit
>table, if one entry is the original value, there are only 3 "changed" values, so an
>input difference can cause each output bit to change with probability 2/3, not 1/2.
> >
> > For a function to fulfill SAC it doesn't have to always have 1/2 of the output
>bits affected, just on average (i.e with probability 1/2). So it is possible that a
>single bit toggle causes four bits difference and still fulfill SAC.
>
> Eh? If it's a 2x2 table, then there are 2 inputs, and 2 outputs. There is no way
>to change 4 bits of output, since there aren't that many.
I don't get what you are saying. It's only logical that the function will
not affect the input, so no duh you only get upto 3 bits different. So what?
> Also, 2/3 *is* a probability. Reread what I wrote. Also, take your own advice
>about thinking before posting.
>
> > > If I were to consider an N bit table, the probability of an output bit
>changing when the input changes, should, if the table is as close to SAC as possible,
>change with probability of 1-(2^(N-1)-1)/(2^N-1).
>
> > Generally you count (over all the inputs) the number of times you flip one bit of
>input the output bit (specific input/output bits) togle. If the count is 2^(n-1)
>then it's SAC for those particular bits. If it's not then it's not SAC. simple as
>that.
>
> No. The strict definition of SAC says output bits change 1/2 of the time. If the
>count is 2^(n-1) that it changes, then the count is 2^(n-1)-1 of it not changing.
>Since (2^(n-1))/((2^n)-1) is not 1/2, then no substitution box of finite size is SAC.
I beg to differ. If there are 256 possible inputs, then it must flip for 128
of them and not flip for 128 of them. That satisfies SAC.
> Suppose I have an 8 bit table. Flipping 1 bit of input can cause any of 255
>different differences; The odds of a change is 128/255. Not 1/2. It's almost SAC,
>but it is not SAC.
Yeah but SAC only concerns a SINGLE bit of input *AND* a SINGLE bit of
output. Not multiple. So a 8x8 table can be SAC.
> > > Is there any particular term for this type of "Almost SAC?"
> >
> > Not SAC.
> >
> > > For instance, if a 128 bit cipher fulfills the property that if an input
>bit changes, then each of the output bits change with probability
>1-(2^127-1)/(2^128-1), what do you call that property?
> Getting rid of extraneous "-"s for easier reading: (2^127)/(2^128-1)
>
> > > Also, is there any term for calculating SAC on larger units than single
>bits? Maybe "bytewise SAC," or "wordwise SAC?"
> >
> > Stochastically random? If you are talking binary, bytewise is 'seventh-order' so
>you would say "seventh-order SAC" i.e changing any eight bits will change any other
>unit of eight bits with prob 1/256 (all bits flip simulataneously).
>
> Who cares about all 8 bits changing at once? I care about at least one of the 8
>bits changing, which is quite different. Changing any input byte (any of the 255
>possible nonzero changes to that byte) causes any output byte to change in one of 256
>possible ways, of which 255 are nonzero differences, and 1 of which is a zero
>difference -- that is, there's a 255/256 probability of the output byte changing, and
>a 1/256 probability of it not changing.
Um no, if a 8x8 function is truly random the bit will flip with a probability
of 1/2 not 255/256. I think you are mixing up various tests. SAC is on
SINGLE bits at a time.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Thu, 18 Jan 2001 14:13:27 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Where can I find software tools for Known-text decryption
[EMAIL PROTECTED] wrote:
>
> It is my understanding that when you know some of the test in a file,
> the rest of the file can be decrypted.
Maybe. The information certainly doesn't hurt, but it doesn't guarantee
a decryption.
A partly-known plaintext is known as a "crib", and it helps in
cryptanalysis but does not guarantee that you can extract the rest of
the plaintext.
How useful a crib is depends on the encryption algorithm.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: aWARe <[EMAIL PROTECTED]>
Subject: [H] one-way hash functions
Reply-To: swap "y" and "i"
Date: Thu, 18 Jan 2001 13:58:00 GMT
ola todos,
I've to reduce the 16bytes MD5 output to 8bytes (univocal):
I thought to use another one-way hash function which takes as input
the 16bytes generated by MD5, and gives the 8bytes...
Is any theoretical correctness problem involved with this step?
If I have 4 inputs key, is a good solution to use an hash function,
which gives 2bytes as output, for every key and to combine the four
outputs in a 8bytes key?
thanks to all
------------------------------
Reply-To: "N. Weicher" <[EMAIL PROTECTED]>
From: "N. Weicher" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 14:26:51 GMT
But then you fail the requirement that the ciphertext be the exact same
length as the plaintext, unless I am missing your point.
Neil
===============================================
"Adrian S. Thompson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> Couldn't a person just pad the plaintext, encrypt the plaintext, then
place an
> EOF at the first byte of the padding? Just a hypothosis. ;-)
>
> Take care,
> -=Adrian=-
> > N. Weicher <[EMAIL PROTECTED]> wrote in message
> > news:kAj96.59822$[EMAIL PROTECTED]...
> > > Is it possible to use a block algorithm (such as Blowfish or DES) to
> > encrypt
> > > plaintext where the length is not a multiple of eight bytes? I know
about
> > > padding, but what if padding is not an option, ie, the encrypted data
must
> > > be the exact same length as the plaintext data? Is this feasible? If
so,
> > > how is it done?
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 07:08:39 -0800
Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
news:9464bk$qsm$[EMAIL PROTECTED]...
>
> N. Weicher <[EMAIL PROTECTED]> wrote in message
> news:kAj96.59822$[EMAIL PROTECTED]...
> > Is it possible to use a block algorithm (such as Blowfish or DES) to
> encrypt
> > plaintext where the length is not a multiple of eight bytes? I know
about
> > padding, but what if padding is not an option, ie, the encrypted data
must
> > be the exact same length as the plaintext data? Is this feasible? If
so,
> > how is it done?
> One obvious way is to use a feedback mode that handles partial blocks,
such
> as CFB, OFB or counter mode.
>
> A rough overview of these modes:
>
> CFB:
> C[i] = P[i] ^ E( C[i] )
Sigh:
C[i] = P[i] ^ E( C[i-1] )
>
> OFB:
> T[i] = E( T[i-1] )
> C[i] = P[i] ^ T[i]
>
> Counter mode:
> C[i] = P[i] ^ E( i )
>
> Where:
>
> P[i] is the ith plaintext block
> C[i] is the ith ciphertext block
> E( ) is one block encryption using the block algorithm, with the key
> implicit
> T[i] is an internal value in OFB mode.
> ^ is xor
> If the algorithm refers to a ciphertext block before the first one, use
a
> (possibly implicit) IV
>
> It should be obvious that for each of these modes, if the receiver has
> ciphertext as long as the original plaintext, he is able to uniquely
> identify the original plaintext (assuming, of course, he has the key).
>
> And, yes, I'm fuzzing over some details with all three of these modes (CFB
> and counter mode, in particular, are actually defined more generally than
I
> stated). Check out Applied Cryptography for the details
>
> --
> poncho
>
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Where can I find software tools for Known-text decryption
Date: Thu, 18 Jan 2001 14:26:11 GMT
[EMAIL PROTECTED] wrote:
> It is my understanding that when you know some of the test in a file,
> the rest of the file can be decrypted.
Not if the encryption system is any good.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 18 Jan 2001 15:40:17 GMT
Subject: Re: Comparison of ECDLP vs. DLP
Wei Dai said and I insert my comments prefixed with DJ:
"In article <[EMAIL PROTECTED]>, djohn37050
@aol.com says...
> Another note, PKV is the COMPLEMENT of POP, proof of possession. Doing both
> provides high levels of assurance.
That's only true in DL or EC systems. In RSA, there is only POP, and no
PKV. So one could say RSA is simpler because you only need to do one of
these tests.
DJ: This is simply not true. For RSA, PKV is far harder than for DL/ECC, at
least if you go beyond partial PKV. See Bob Silverman's paper "RSA PKV" where
he describes how to use the private key owner as an oracle to do RSA PKV.
> Also, while PKV is used to detect keys that might attack your private key
when
> used in DH, there are many other potential concerns with an invalid public
key.
> If using an invalid key, the encryption may not be invertible and hence not
> able to be recovered by anyone or it may be invertible by anyone and hence
> recoverable by anyone.
But my point is that even if you have a valid public key, the
encryption may still not be invertible or may be invertible by anyone.
DJ: This is a strange statement. Security is all about assurances. I claim it
is an inherently different thing if I use an invalid public key versus other
ways security can fail. Each mode of potential failure needs to be looked at
and addressed or not addressed (accepted).
So the main purpose of PKV must be to detect keys that might attack
your private key.
DJ: This is A MAIN purpose, but not the only purpose, there are many.
This does not apply in the case of RSA. If you want
to make sure that the encryption is invertible by the owner you must do
POP.
DJ: I agree POP is useful, I am just saying it is not all there is.
This is the same between EC and RSA.
DJ: POP for EC and RSA can be done by doing the natural crypto operation, for
example, self signed cert. reqs. There are also other ways, with ECC you can
show you know the private key without revealing it via ZKP, I suspect the same
is true for RSA.
If you want to make sure no
one else can invert the encryption, you must check the entire
cryptosystem for errors or back doors. This is also the same.
DJ: One can look at the ECC/DL public key and tell in a straightforward manner
it is conforms arithmetically to the requirements of a standard. One cannot
look at an RSA public key and do that totally, only partially. So this aspect
is NOT the same.
> And here is a crucial point, if a public key is
> invalid, EVEN IF A SIGNATURE VERIFIES, the signature should be considered
> invalid. This is because the game is not being played in the intended
sandbox
> and hence all bets are off.
I don't agree with you here. It should be the key owner's
responsibility to make sure his published key is valid. Why should
everyone do extra work to validate his key when he can just do it once?
DJ: I agree it is the owner's responsibility to ensure it is valid. Exactly
how much work to do is a cost/benefit decision. It is also the user's
responsibility to ensure a public key is valid. Why? Becasue he may suffer
loss if it is not. Exactly how much work to do is a cost/benefit decision. A
CA can be a neutral third party that can validate a public key and provide
assurances for the owner and all users, so this makes sense as a service to
provide.
Anyway, with RSA there is no way for other people to validate his
public key, so under your definition no RSA signature can be
independently verified. Surely that's not what you want.
DJ: Again you think there is no RSA PKV, but there is, how much to use of it is
a cost/benefit decision.
--
http://cryptopp.com - free C++ cryptography and compression library
Don Johnson
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: Compression
Date: Thu, 18 Jan 2001 16:07:50 GMT
The nice people over in news:comp.compression can help you out.
Will.
--
William A. McKee <[EMAIL PROTECTED]>
http://www.cjkware.com/wamckee/
cjkware.com inc.
http://www.cjkware.com/
"We're starfleet: weirdness is part of the job." - Janeway
"I have seen things I cannot deny." - Scully
PGP public key at http://www.cjkware.com/wamckee/pgp/ ( ID = 0x11162FF2)
Finger Print: F5B8 6251 050C 7595 6A84 6C37 6041 4258 1116 2FF2
"We need your help... " - http://www.distributed.net/
Adrian S. Thompson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> Does anyone know where I can find the algorithms for different
> compression utilities (gz, zip, rar blah...)? This would help me to
> write a program to find patterns in cyphertext files. I realize that
> some may be 'top secret' patented algorithms, but any pointing in the
> right direction would be nice.
>
> Take care,
> -=Adrian=-
>
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Thu, 18 Jan 2001 09:04:25 -0700
Greggy wrote:
<snip>
> You know what is really sad? I can site a 1973 US Senate report that
> confirms everything I just said and you don't realize it.
<snip>
Except that "a 1973 US Senate report" isn't specific enough
to count. Do you perhaps have a reference that is easier to
check?
JM
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 18 Jan 2001 16:20:03 GMT
Subject: Re: block algorithm on variable length without padding?
You can also use ciphertext stealing from the previous block to fill out the
last block. This is no weaker than CBC. The trick comes in deciphering, you
need to handle the last partial block and previous full block appropriately,
but this is not hard to figure out.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 18 Jan 2001 16:29:26 GMT
Subject: Re: Comparison of ECDLP vs. DLP
Just to be clear, as a cryptographer, I appreciate having 3 recognized families
(IF, DL, ECC) to be able to choose solutions from. This is because each family
has different attributes and I can choose the family that fits the solution
better. Why use a hammer as a screwdriver? But, each family needs to have a
complete discussion of ALL its attributes, so that the decision can be made
using all relevant info.
Some apparently say "c = m**e mod n therefore use RSA as it is simpler than
ECC" which is a VAST oversimplification, in my opinion, to the point of being
just plain wrong. There can be reasons to use RSA and reasons to use ECC, but
the RSA encryption formula (which by itself is insecure) ain't one of them,
again, my opinion.
Don Johnson
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Thu, 18 Jan 2001 09:47:47 -0700
Greggy wrote:
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> > Greggy wrote:
> > > FDR and the congress technically, legally declared the citizens of
> the
> > > US enemies of the US
>
> > This is quite a statement. Can you provide a reference?
>
> Absolutely. I will look it up later tonight and post it back here for
> you.
Any luck on finding that reference?
Shawn.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
