Cryptography-Digest Digest #248, Volume #12 Wed, 19 Jul 00 16:13:01 EDT
Contents:
Re: Project (Mike Rosing)
Re: Crypto source code library suggestions? (Bill Unruh)
Re: VCR+ (Tom Anderson)
Re: PGP US Versions Broken,no good?? (Bill Unruh)
Re: VCR+ ("Joseph Ashwood")
Re: TAGGED INFORMATION ("Joseph Ashwood")
Re: PGP US Versions Broken,no good?? (Bill Unruh)
Re: Bit Shuffling (Jayant Shukla)
Re: Carnivore and Man-in-the-middle (phil hunt)
Re: stes-0.0.0 released (was: Steganographic encryption system) (phil hunt)
Re: VCR+ ([ Dr. Jeff ])
Re: telephone encryption. (Mok-Kong Shen)
Re: Bit Shuffling (lordcow77)
Signed Data ("Kevin Crosbie")
Re: stes-0.0.0 released (was: Steganographic encryption system) (bill davidsen)
Implementation of PSS-style RSA signing? (Thomas Wu)
Re: News about quantum computer (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Project
Date: Wed, 19 Jul 2000 12:15:54 -0500
Teo Li Xi wrote:
> I am currently working on a project to come up with a GUI using
> Visual C++. This GUI is supposed to be able to give a small tutorial to
> the user on the latest encryption technologies, and must also be able to
> let the user try out some of the existing available encryption
> algorithms.
>
> Has anyone done this before?
>
> Is there a place where I can actually go and download as well as to
> learn how to run the encryption algorithms? Thanx !
Check this one out: http://codebreaker.dids.com/
It's aimed at kids, but it should give an idea of what you're after.
The book author might even be interested in what you're doing.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Crypto source code library suggestions?
Date: 19 Jul 2000 17:53:09 GMT
In <[EMAIL PROTECTED]> Tom Anderson
<[EMAIL PROTECTED]> writes:
>http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
>the cryptlib web pages don't say it comes with source, but they do say:
They do
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.video.vcr,alt.2600
Subject: Re: VCR+
Date: Wed, 19 Jul 2000 18:54:12 +0100
On Wed, 19 Jul 2000 [EMAIL PROTECTED] wrote:
> Is there any publicly available software tool that can generate the
> VCR+ code?
see:
http://tallyho.bc.nu/~steve/videoplus.html
this works for the UK version, but the US version is similar. it isn't
complete, either - it can only do short codes. it's a rather interesting
problem!
tom
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: 19 Jul 2000 17:59:20 GMT
In <8l43e7$ri4$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Richard Herring) writes:
>In article <8l3c7a$v75$[EMAIL PROTECTED]>, Dave Ashley ([EMAIL PROTECTED]) wrote:
>> If I understand PGP correctly, there is an easy way to check.
>> Just encrypt the same file or text using the same key on both products.
>> If the output is the same, the later version has not been "broken".
>This doesn't work. In its public-key modes, The random session keys
>will be different each time, and so will the output ciphertext,
>for the same input, even when nothing is broken.
Except on the open source versions, you can replace the secret key
generator, and have it deliver exactly the secret key that the closed
source model used. Thus both will use the same public and same secret
key, and thus you can check to see if their implimentations of the
crypto algorithms work.
The key problem is key generation. How are those secret keys generated.
Are they just eh numbers fro 1 to 100 run through MD5? There is noway
you can tell without seeing source. Furthermore, as a post here a number
of years ago showed, you can generate RSA keys, such that the public key
undetectibly leaks all of the information about the factors of the key.
So, whether the algorithms work is checkable. Whether the key generation
works is not. Also whether extra "random " material in the protocol is
also a potential source of leakage, so you must know what every byte in
the output is.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: VCR+
Date: Wed, 19 Jul 2000 10:52:13 -0700
Crossposted-To: alt.video.vcr,alt.2600
> Is there any publicly available software tool that can generate the
> VCR+ code?
Yes.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: TAGGED INFORMATION
Date: Wed, 19 Jul 2000 10:55:21 -0700
It's called steganography. What you're doing is a fairly novel use of it
(using it to track the spread of something), but it's the same idea. One of
the currently used examples is the low order bit of WAV files, you can
change it without significantly effecting the quality of the recording.
Joe
"+wuff" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I use "tagged information" to track connections at times, and it never
> fails to work. I weave additional info into something I like to see if
> it makes its way around... and this additional info can not be removed
> if the recipient does not know about that.
>
> Does anyone have systematic information about that ? Was anything
> written up in a book about it ?
>
> +swiss+wuff+ http://www.swisswuff.ch
>
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: 19 Jul 2000 18:09:57 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Mark Wooding) writes:
>Richard Herring <[EMAIL PROTECTED]> wrote:
>> This doesn't work. In its public-key modes, The random session keys
>> will be different each time, and so will the output ciphertext,
>> for the same input, even when nothing is broken.
>Indeed. In fact, the public-key crypto is randomized too. PGP versions
>later than 2.3 (I think) use PKCS#1 padding for RSA, which takes a
>message M and pads it out like this:
> 00 || 02 || ... random nonzero padding ... || 00 || M
This makes no difference to the encoding of the document itself ( which
just uses M as the secret key to the secret key algorithm. Of course it
could use the random padding as an IV for the secret key encoding as
well, but I do not think this is done))
>DSA signatures are randomized. It's not possible to be sure, just by
>looking at a signature, that it doesn't contain a subliminal channel
>which (say) leaks bits of your secret key. You must audit your PGP
>source.
Uh, no, otherwise it cannot be a signature-- it must be checkable. Ie,
the signature may vary, but it will vary in a deterministic way.
Ie, you can check, maybe not by directly looking at the output, but by
making transformations on the output with knowledge you have, whether
the output corresponds to the claimed algorithms. Without source you
cannot check that random keys or any other random part of th eoutput is
not a leak.
Any source of public randomness in any part of the algorithm is
source of leakage ( since the random number could be generated by
encoding some information you want to leak with some encryption, which
only the outside leak user knows.) You do not want to use an algorithm
with random output without having the source.
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: Bit Shuffling
Date: 19 Jul 2000 17:48:40 GMT
[EMAIL PROTECTED] (Mark Wooding) writes:
>Please read the long thread between myself and Tom St Denis about why
>bit permutations in ciphers are a bad idea, including differential
Can you back this statement up with something more? A publication?
I can give you an example that refutes your claim. Take a look
at DES. The P-Box based fixed permutation used in each round
of DES is an example of bit-permutation making a cipher strong.
If you remove that operation, you can break DES using only
2^20 plain-text and cipher-text pairs. Ofcourse, if you don't
choose the P-Box properly you may still weaken DES, but the
point is that DES is stronger with P-Box based bit-permutation
than without.
regards,
Jayant
p.s.: The reference is "Differential Cryptanalysis of the
Data Encryption Standard" by Eli Biham & Adi Shamir.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: Carnivore and Man-in-the-middle
Date: Wed, 19 Jul 2000 17:58:32 +0100
Reply-To: [EMAIL PROTECTED]
On 18 Jul 2000 13:49:41 -0700, Eric Smith <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>> Perhaps. IMO it's more likely that our generation will be the first to
>> know total freedom of speech.
>
>Total freedom of private speech, maybe. Public speech with anonymity,
>they're doing everything in their power to eliminate. Perhaps things like
>Freenet (freenet.sourceforge.net) will work to preserve our rights in
>this area, or perhaps the government
Who is "the government"? There's lots of countries, and lots of govmts.
They all have different laws. if some ban Freenet, others won't.
>will manage to shut such things down
>(under the guise of protecting artists).
Freenet can be used to illegally distribute copyright material. But
so can email, netwets, ftp, and the web; the whole point of the net is to
make it easier for people to communicate.
Some jurisdictions will make it illegal to write or possess programs like
Freenet. Some (probably the majority) will say that they are legal if
they are capable of substantial legal use.
(There was a court cae over VCRs in the USA about this issue; VCRs
were deemed to be legal, because they could be used for doing legal
things).
--
***** 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)
Subject: Re: stes-0.0.0 released (was: Steganographic encryption system)
Date: Wed, 19 Jul 2000 18:51:44 +0100
Reply-To: [EMAIL PROTECTED]
On 18 Jul 2000 18:00:02 -0000, lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
>Phil Hunt writes:
>> It's on the web at <http://www.comuno.com/linux/stes/stes-0.0.0.tgz>.
>
>From the README file:
>: How it works
>: ------------
>:
>: The ciphertext file has two parts -- a Check Area (CA) and a Data Area (DA).
>: The DA actually holds the data and the CA tells stes which bits of the DA
>: are associated with each key.
>:
>: The DA is split up into 50 Data Items (DIs).
>:
>: The CA is split up into 30 Check Items (CIs). Each CI contains:
>:
>: - three 32-bit check numbers
>: - the length in bytes of the data associated with this key
>: - a bitmap which defines which DIs hold the data for this key
>:
>: The 3 check numbers (check1..check3) are multiples of 3 numbers
>: (mult1..mult3).
>:
>: When decrypting according to a key (k), the system will attempt to decrypt
>: each CI with that key. If the decrypted check values are found to be
>: multiples of mult1..mult3 respectively, then the system knows that the key
>: matches that CI (there's a 10^-12 probability of a false positive).
>:
>: Once a matching CI is found, the decryption program can read the rest of
>: the CI: it knows the size of the data, and which DIs hold it. (It is stored
>: from the lowest numbered DI upwards), so it can decrypt them with the key
>: and reproduce the data file,
>
>The check number mechanism seems slightly cumbersome. It would be more
>straightforward just to put a fixed value there. Some people will whine
>about known plaintext, but let's get serious: known plaintext is not
>a problem with a strong cipher.
Isn't it? I wanted to play safe on this one.
>The cheapest way to break this kind of
>system is by torturing the key holder,
This system is more resistant to that kind of attack than most cryptosystems,
because the key holder can disclose some keys, and the adversary doesn't know
whether they've all been disclosed.
>not by looking for known plaintext.
>No significant security weakness would arise by using a fixed check
>number to recognize proper decryption.
You may well be right; I'm not an expert.
>The system can hold only a fixed number of separate files, 30 in this
>case. I thought you might have something more elegant in mind that could
>handle an unlimited number of files. You didn't say anything about this
>limit in your earlier description.
There's two concepts here; number of keys, and number of files. At a later
date, I could expand the system so that each key holds a whole directory
structure, not just one file -- for example by having the key hold a tar
file, then untarring it to form separate files.
That would still leave the limit of 30 keys. This was just an arbitrary
limit to make it easier to code the 1st version.
>There is a limit of 50 DIs, and the header file says that DI size is 1K.
>Does this mean that you have a limit of 50K of data stored? This would
>also seem to be an unfortunate limitation.
Again this limitation was to make it easier to code. Later versions will have
no limit on the size of DIs, or the number of DIs or CIs. An adversary
won't know the number of CIs on a ciphertext file. Even someone who knows all
the valid keys won't know that.
>One possible weakness would arise if the attacker, by examining your
>disk, found earlier deleted copies of the ciphertext file. Looking at
>differences between those copies and the current one, they could see which
>segments had been updated, and demand that you produce the key for those
>parts. This would defeat your goal of producing only unimportant keys.
This is true. One way round it would be to make sure that all deleted files
are repeatedly overwritten -- IIRC PGP does something like this.
>Over time, with repeated updates, DI leaks will occur. When you put a
>file in, and then update it with a shorter file, the DI's allocated to
>the longer version will be lost and never be usable again.
Not true. There will be a command that lets you transfer the unused space
belonging to one key into another key. Of course, to do this you will
have to know both keys.
--
***** 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] ([ Dr. Jeff ])
Crossposted-To: alt.video.vcr,alt.2600
Subject: Re: VCR+
Date: 19 Jul 2000 13:25:22 -0500
In article <8l4hsn$qb3$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Is there any publicly available software tool that can generate the
>VCR+ code?
Certainly. And if you use a search engine with the terms "VCR
PLUS CODES", you're bound to run into it.
--
This signature file is dedicated to Da Gothic Angel herself, Nitallica.
Dr. Jeff is Nitallica's number one fan, willing slave, and keeper of
the strap-on boots she wears when in full battle mode. He also gets the
blueberry squishies whenever she mentions his name. :-)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: telephone encryption.
Date: Wed, 19 Jul 2000 20:47:05 +0200
George Gordon wrote:
> I saw a telephone encryption device in the August North American edition of
> Popular Science. Page 24. The device called Privatel is made by L-3
> Communications. It says it uses 168-bit encryption. I am in no way
> associated with this company. My question is: 3DES? Key-Escrow??
It uses 3DES, as far as I know.
M. K. Shen
------------------------------
Subject: Re: Bit Shuffling
From: lordcow77 <[EMAIL PROTECTED]>
Date: Wed, 19 Jul 2000 11:50:19 -0700
[EMAIL PROTECTED] (Jayant Shukla) wrote:
>I can give you an example that refutes your claim. Take a look
>at DES. The P-Box based fixed permutation used in each round
>of DES is an example of bit-permutation making a cipher strong.
>If you remove that operation, you can break DES using only
>2^20 plain-text and cipher-text pairs. Ofcourse, if you don't
>choose the P-Box properly you may still weaken DES, but the
>point is that DES is stronger with P-Box based bit-permutation
>than without.
>
Ahh, but there is also an expansion in the DES F function, used
before the input to the 6x4 S-boxes. Besides, I think its
reasonable that the collective nonmilitary cryptgraphic
community knows more about certain aspects of cipher design
today then it did thirty years ago. Bit permutations are free in
hardware; expansion by duplication is also free. A PHT network,
polynomial multiplication, or matrix multiplcation are
considerably more expensive. The Rijndael round function is far
more effective than the DES round function (even considering
that the DES function only acts on half the block). The maximal
differential characteristic of 16 round DES is something like
2^50; the number of active S-boxes in DES, even considering the
expansion and the bit permutation, is much lower than for most
modern ciphers.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Signed Data
Date: 19 Jul 2000 15:12:36 EDT
Does IE have a scripting function(VBScript, JScript....) which provides the
same function as crypto.signText?
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: stes-0.0.0 released (was: Steganographic encryption system)
Date: 19 Jul 2000 19:20:30 GMT
In article <[EMAIL PROTECTED]>,
phil hunt <[EMAIL PROTECTED]> wrote:
| This is a highly unfinished version, as the version number suggests: it
| encrypts but it doesn't decrypt. I've included a README file which explains
| how it works.
I wrote a compression program like that once...
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
There are those who make things happen, those who watch things happen,
and those who wonder what happened.
-- idea from _Pickles_
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Implementation of PSS-style RSA signing?
Date: 19 Jul 2000 12:24:02 -0700
Are there any free crypto libraries out there with an implementation of
PSS encoding for RSA signatures? PKCS#1 v2.1 refers to the technique
as "RSASSA-PSS", and the latest IEEE P1363a draft calls the encoding
method "EMSA3", but the two standards seem to differ slightly, for
example, in the ordering of hash inputs. What's a good place to look
if I want to generate standard-looking signatures of this form?
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: News about quantum computer
Date: Wed, 19 Jul 2000 22:15:59 +0200
Bill Unruh schrieb:
> In <[EMAIL PROTECTED]> Runu Knips <[EMAIL PROTECTED]> writes:
>
> ]In the german computer magazine c't, issue 15/2000 (from this monday),
> ]page 40 they say that the current record is 8 qubits, implemented with
> ]rydberg states of a single atom.
>
> This makes no sense. 8 bits is 256 states.
> I think the magazine has gotten itself very confused.
Would you please elaborate your first sentence? Why is it not possible
to have 8 qubits? Must the number of qubits be odd?
BTW, the pointer you gave in another follow-up mentions only
a case of 3 qubits. As far I can see, it is not about the 7 qubits
that you mentioned. Could you give the correct reference for 7 qubits?
Thanks.
M. K. Shen
------------------------------
** 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
******************************
