Cryptography-Digest Digest #222, Volume #12 Thu, 13 Jul 00 23:13:01 EDT
Contents:
Re: Random Numbers ("Paul Pires")
Re: Big Brother Is Reading Your E-Mail (jungle)
Re: Perl routines for vigenere cipher? ([EMAIL PROTECTED])
Re: Cryptographic Camouflage ("Joseph Ashwood")
Re: Steganographic encryption system (phil hunt)
Re: Perl routines for vigenere cipher? (JPeschel)
Re: Cryptographic Camouflage (John Myre)
Re: General Question on cryptography (John Savard)
Re: Cryptographic Camouflage ("Joseph Ashwood")
Re: Has RSADSI Lost their mind? (Stefek Zaba)
Re: Use of EPR "paradox" in cryptography (Bill Unruh)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Bodo Moeller)
Re: Has RSADSI Lost their mind? (Paul Rubin)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Random Numbers
Date: Thu, 13 Jul 2000 13:18:48 -0700
Got it. Some times two simple explanations can penetrate the skull when one
clear explanation can't.
My thanks,
Paul
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Big Brother Is Reading Your E-Mail
Date: Thu, 13 Jul 2000 16:21:38 -0400
Samuel Hocevar wrote:
> On Wed, 12 Jul 2000 23:44:08 -0400,
> jungle <[EMAIL PROTECTED]> wrote:
>
> > > This program broke the PGP encryption in two minutes flat,
> > > so you're not even safe with encryption.
> >
> > what program will broke PGP in 2 min flat ?
>
> If we told you, we'd have to kill you.
I did not directed my question to you, but
=====BEGIN PGP MESSAGE=====
hQBsA6GrOHZC9xe9AQL/blsYb5lD9DirhIa5cagH8sd57/HmXcHEmSlpvL6G30GA
kLckpdN51TF3aAn3iIu5g1jhhtNE9WOL6ej9Vq2RrGaidyr90C70aqeihKDJ3j8g
Ywe+PlHMNq2q5i/0J188pQGcHU//I+WXzPh1RhP5ouLK3eyUDsMCMO6mGxrpj76B
EK/AGWnug1lZwYwE+x9LRb/rsMx285IQrWxr1VCdZZ/LH2qJ4nR1CMbIvQgt2ax4
/LHaJ1UyA92gTVncnudd+PX/bx4SpdRRKPvMR9zV/5xOZhlzgrQp/D90TOzaetDy
DNcjNg61TVlEg5K4s7e3rosMivNW9r7/8h1EpEYDZPNQhx6sxkULfSeb7u5DZoxP
bTbi4xDciEaH/OznQUL0gcAIN70uf/YPP9MqkNszb4rLnremIahMUtKDFVQwZdpW
9X/90lvOx+lVSichQQOXSiidxIGJarqnONXqWnDavPsVLTs3u/S4vnJYyo84p7ux
yLvXXFBYtu/Rk0An/lXQ1HqqEAe4ZiWCjE7XTxEFNDwDjihAI7X/pRFInqV3gA8s
gE/YYKFDXeXJQDS+aN27R+6akTDQ8jOXLQR0T86HpZ8FLdwvr/qBXC90DDkRqYxx
HQ3f3W24fPrQ6oRVC1Zmoh8jwIfNx/J9cxUcvkfcb+XQ23oxTpgteWa5wIx/YA==
=rcKe
=====END PGP MESSAGE=====
, you did read already in my encrypted message above ...
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Perl routines for vigenere cipher?
Date: Thu, 13 Jul 2000 21:00:27 GMT
In article <8kknbr$i6r$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Length of Cleartext Length of Ciphertext
> 1 2
> 2 4
> 3 5
My error. With the cleartext of 3, the ciphertext is 6. (I didn't see
the space at the end).
So 2*length(cleartext) = length(ciphertext)
I also noticed that the same cleartext does not generate the same
ciphertext.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Thu, 13 Jul 2000 14:14:08 -0700
[following data left for clarity]
> <snip>
> > E = encrypted version of e (using strong methods, 3DES is the current)
> > D = encrypted version of d (lightly encrypted, a strong cipher with a
small
> > pin), there's actually more to it, there are some bits that are left
clear
> > because they can be verified without knowlede of e
> > PQ = pq in clear
> >
> > Authentication protocol:
> > Client:
> > Get challenge C from server
> > Decrypt D to get probably d
> > compute X= (C+ padding)^d mod PQ
> > send X to the server
> > Server:
> > decrypt E to get e
> > compute (M+padding) = X^e mod PQ
> > verify M as a recent valid challenge
> <snip>
>
> Is C randomly chosen each time?
C is as randomly chosen as I can get it to be, and I've spent quite a bit of
time working on it.
> How about the padding?
We use a strong random number generator, and it is uniquely chosen by the
client. However this is the weakest point in the authentication, it has less
entropy than I'd like.
> Do e and d vary between clients?
Yes e and d and both unique for each user, otherwise the authentication
would be seriously flawed
> How about the pin?
The pin is user chosen, we have no control over what they choose, but it is
treated as a passphrase so the user can use something substantial if they'd
like.
> Does the client know E or e or both?
The client knows E, but the key to decrypt it is (at least under our
security assumptions) unknown to the client (it is restricted to the server
where it is gaurded as our most precious data, just as d is on the client).
We have made every effort to make the signature unverifiable by any except
the server, so that an attacker can (hopefully) only perform online attacks
which can be detected.
I should note that in order for you to make an accurate analysis of the
security you should know that the key to decrypt E to e is same across all
certificates belonging to one server, but differs between each installation.
The certificate database is considered completely insecure, although we do
have a central location for them, they are maintained on the client
machines.
Joe
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Thu, 13 Jul 2000 14:26:58 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 12 Jul 2000 18:43:34 -0400, jungle <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>>
>> On Wed, 12 Jul 2000 00:40:39 -0400, jungle <[EMAIL PROTECTED]> wrote:
>> >current, well working stego have ration of 1 to 2 ...
>> >and all are super safe / super stego ...
>> >you are creating stego that will have ratio of 1 to 30 ...
>> >
>> >what a waste of resources ...
>>
>> I'm not forcing you to use it, you know.
>
>I'm not stopping your from developing un - needed software, to ...
I'm not stoping yu form riting badlee-spellt and punchtuatid mesajiz,
eyethur ...
--
***** 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] (JPeschel)
Date: 13 Jul 2000 21:39:49 GMT
Subject: Re: Perl routines for vigenere cipher?
[EMAIL PROTECTED] writes:
>I just started investigating the security of a commercial application
>that encodes (and stores) a password using what Is apparently a trivial
>cipher? If I can reverse engineer the lgorithm I
>can prove my point about the error of "security through obscurity."
>
Have fun. I enjoy having a site where I do just that.
>I've been using Perl and known cleartext to find the algorithm.
>This is my first cryptographic analysis, and it's fun so far, but I
>admit that my cryptp background is minimmal.
>
>The ciphertext is limited to the ASCII characters above "space"
>(hex 20) to 7F. I have a few examples of known cleartext at this time.
>(and two dozen examples of ciphertext).
>
>Length of Cleartext Length of Ciphertext
>1 2
>2 4
>3 5
>
>I am getting more examples of cleartext/plaintext pairs,
>(I need the help of a sysadmin for this.)
>
>Does anyone have any tools, preferably in Perl, for investigating
>the possible key/algorithm? This is trivial for an expert
>(i.e. not me.), and I am hoping someone has some tools and hints
>that can help automate the search for the key & algorithm.
>
>Perhaps this isn't a Vigenere, because the length of cleartext
>isn't the length of the ciphertext?
>
>What should I be looking for?
Since commercial encryption products
often add information to an encrypted
file, it could be Vigenere cipher. I
wouldn't decide that it is a Vigenere
until you have tried to encrypt some
longer plaintext using a short, say
two character, password. Try encrypting
a string of As using BB as the password.
Test the resulting ciphertext to see
if the cipher is a Viggie.
If not, you'll want to observe the
the case and range of the cipher text:
is the ciphertext limited to all caps,
to printable characters. You'll need
to try several plaintext-ciphertext
pairs. Use the same password with
slightly varied plaintexts; try
slightly varied passwords with the
same plaintext.
After generating your pairs, you can
run single character, digram,
and trigram frequency tests. You may
might want to run IC tests, too. This
will give a better idea of what sort
of cipher you're dealing with.
If you have access to the program
and are able to reverse-engineer
it, your job may be even simpler.
You can find examples of the sort
of thing I'm talking about on my
web site, and also on the site of
my friend Pavel Semjanov.
(http://194.85.96.197/psw/)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Thu, 13 Jul 2000 16:17:01 -0600
This is interesting. But be sure to stop me if I get
annoying...
Joseph Ashwood wrote:
>
> [following data left for clarity]
> > <snip>
> > > E = encrypted version of e (using strong methods, 3DES is the current)
> > > D = encrypted version of d (lightly encrypted, a strong cipher with a
> small
> > > pin), there's actually more to it, there are some bits that are left
> clear
> > > because they can be verified without knowlede of e
> > > PQ = pq in clear
<big snip>
Let's see if I understand. The server generates p, q, d and e. It
encrypts e as E and stores it, along with PQ = pq, in a place that
is accessible to the client and to attackers. Then somehow the client
gets d, which he encrypts to D and stores locally. So the encryption
of e is to prevent attackers from substituting their own pq, e?
What have I got wrong so far?
Meanwhile, what other communication is going on? That is, I
don't see what you could do with the above authentication except
say, "yep, that was really my client". Then what? Or is my
model of the communication path way off?
JM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: General Question on cryptography
Date: Thu, 13 Jul 2000 23:31:15 GMT
On 13 Jul 2000 12:41:39 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
> Ok John way to go thats one. What are the next 5?
Kerckhoff's six dicta are listed on my site at
http://home.ecn.ab.ca/~jsavard/crypto/mi0611.htm
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Thu, 13 Jul 2000 16:49:43 -0700
> Let's see if I understand. The server generates p, q, d and e. It
> encrypts e as E and stores it, along with PQ = pq,
Actually both are placed in an X.509 public certificate as an extension.
> in a place that
> is accessible to the client and to attackers.
> Then somehow the client
> gets d, which he encrypts to D and stores locally.
D is actually generated by the server (based on the client's input) and
placed in the certificate extension along with E and PQ. Although we are
working on changing this.
> So the encryption
> of e is to prevent attackers from substituting their own pq, e?
Actually it's because with a small pin protecting the D->d operation if e is
know d can be found (I started some discussion a few months back on sifting
through a series of d given e in RSA).
>
> What have I got wrong so far?
Realistically only the placement of D, which is placed in the cert (which is
then transferred to the user).
>
> Meanwhile, what other communication is going on? That is, I
> don't see what you could do with the above authentication except
> say, "yep, that was really my client". Then what? Or is my
> model of the communication path way off?
Your model is quite accurate, we deal only with strict authentication, and
even then only to the one server, instead of authenticating to generic
entities.
Joe
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: Has RSADSI Lost their mind?
Date: 11 Jul 2000 15:32:52 GMT
In sci.crypt, Mark Wooding ([EMAIL PROTECTED]) wrote:
> RSADSI have more talent than just Rivest: Silverman, Robshaw, Kaliski
> and Yin are certainly not fools, to name just a few.
Matt Robshaw is no longer with RSA Labs either...
Stefek
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
Date: 14 Jul 2000 00:17:25 GMT
In <[EMAIL PROTECTED]> Tim Tyler <[EMAIL PROTECTED]> writes:
]: They can now do for example a oneway hash of the bits they have, and
]: compare those. If they agree, they they are pretty certain that she
]: also did not eavesdrop any substantial percentage of the secret bits.
]Somehow, this stage never seems to get mentioned in classical descriptions
]of quantum cryptography.
There are actually more sophisticated techniques than this which go under the
name of bit distillation, in which you can take x bits of which you suspect the
attackers knows y of, and produce a set of x-y bits which you know they have no
information about.
]: (If E was lucky and did eavesdrop on a some, the prob of not being
]: detected goes something like .75^n where n is the number of bits.)
]This figure is some distance from the original 1/2^(no_of_bits_checked)
]probability of eavsdropping being detected suggested by most descriptions.
If she guessed right as to the polarisation, then 100% of the bits will agree
If she guessed wrong about the polarisation, then still 50% of the bits will
agree between the two sides. Ie the probablility of A and B discovering a wrong
bit is is the probability of her guessing the wrong polarisation times .5. If the
polarisations are randomly and equally chosen, this is .25 as the prob of A and B
disagreeing, or .75 of agreeing.
]: They can now do a running hash of the bits, (eg, each 128 bits of
]: key is run through say MD5 to give 128 bits of new key which depends
]: on all of the 128 bits-- since the probability is negligible that E
]: listened in on 128 bits and was not detected (.75^128 =10^-16),
]: this gives a key which Eve does not know any bits of.
]This stage never seems to get mentioned in classical descriptions
]of quantum cryptography either :-(
AGain, bit distillation does not rely on classical hashing.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: 13 Jul 2000 19:32:48 GMT
Mark Wooding <[EMAIL PROTECTED]>:
> I may write Lim-Lee prime generation stuff at some point.
It's available as part of GnuPG.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Has RSADSI Lost their mind?
Date: 14 Jul 2000 02:03:18 GMT
In article <[EMAIL PROTECTED]>,
Mark Wooding <[EMAIL PROTECTED]> wrote:
>Alternatively, use ephemeral Diffie-Hellman with DSA authentication,
>which has been in SSL for ages. (And I wish more people would use it:
>the forward secrecy properties of Diffie-Hellman are a major benefit.)
The trouble is that not that many browsers support it.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Thu, 13 Jul 2000 22:55:28 +0100
Reply-To: [EMAIL PROTECTED]
On 12 Jul 2000 14:54:36 GMT, Paul Hughett <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps phil hunt <[EMAIL PROTECTED]> wrote:
>
>:>Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
>:>might keep you busy.
>
>: Not at all. If you try to encrypt a 1K file, the system will *always*
>: produce a ciphertext which is substantially larger. This has the advantage
>: of helping to defeat traffic analysis attacks.
>
>: Since stes will be open source, it probably won't be too difficult to prove
>: to a court that this is the case.
>
>The hard part comes when to try to prove to a court that the 1k plaintext
>is the *only* message stored in this 30k ciphertext.
This will depend on the jurisdiction you live in. If a court will imprison you
for failing to prove something that is impossible to prove, then you are not
living somewhere under the rule of law, so stes cannot help you.
--
***** 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: Thu, 13 Jul 2000 22:58:06 +0100
Reply-To: [EMAIL PROTECTED]
On Thu, 13 Jul 2000 02:17:07 +0100, Michael Rozdoba <[EMAIL PROTECTED]> wrote:
>
>The kind of security I was after is two fold. First, after the data has
>been decrypted, used & discarded, there should be no possibility of
>decrypted data being recovered from harddisc, either from deleted
>temporary files or swap. Second, if possible, that the state of the system
>at all times should be such that if the power is cut, all sensitive data
>is lost (once the contents of memory have become irretrievable).
>
>Are your aims likely to meet these requirements?
Yes.
(The initial release of stes won't; it'll basically be a technology
demonstrator. But later releases can incorporate whole filesystems)
>> >Can a program, that doesn't know it's handling sensitive data, be
>> >wrapped up in such a way that it is protected from doing anything
>> >undesirable with that data? A naive approach would be a mechanism to
>> >only permit it access to files in memory, but that could require huge
>> >amounts of memory.
>
>> Modern PCs have 64-128M of memory, which is plenty for many applications.
>
>For many, yes - but for some applications data of the order of GBs is
>involved. Incidentally, any idea what speed will be like, very roughly?
It'll run at the speed blowfish decodes in, plus however long it takes to
read the file off your hard drive, plus whatever inefficiencies I've added
due to my bad programming.
--
***** 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: Thu, 13 Jul 2000 23:01:42 +0100
Reply-To: [EMAIL PROTECTED]
On Thu, 13 Jul 2000 10:23:51 +0100, Andrew McDonald <[EMAIL PROTECTED]> wrote:
>On Wed, 12 Jul 2000 02:12:52 +0100,
>phil hunt <[EMAIL PROTECTED]> wrote:
>> On Tue, 11 Jul 2000, Frank Gifford wrote:
>> >
>> > 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?
>
>Ah. Methinks you need to read up on using crypto.
There's nothing like implementing a system for learning about the tech
involved!
I've now switched over to a version of the blowfish algorithm that uses
chaining mode.
>Initial/Initialisation vector.
Each Data Item (a Data Item is part or all of a file being encrypted) will use
a different IV.
>> Blowfish is a max of 448 bits, right?
>
>Just remember that keyspace on its own is not a measure of security.
>Consider how many keys a simple substitution cipher has, but it is
>not generally secure.
Yeah, but blowfish is secure against the sort of simplistic tricks that
would work against a substitution cipher, 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
******************************
