Cryptography-Digest Digest #264, Volume #11 Mon, 6 Mar 00 09:13:01 EST
Contents:
Re: On jamming interception networks (Jerry Coffin)
Re: RC4 and salt (Johnny Bravo)
Re: ascii to binary (wtshaw)
Re: Crypto.Com, Inc. (Jerry Coffin)
Re: ascii to binary (Jerry Coffin)
ask ("Andrzej Nowak")
Re: Database Cryptography????? ("seifried")
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: On jamming interception networks (Mok-Kong Shen)
Re: On jamming interception networks (Mok-Kong Shen)
Re: Database Cryptography????? (Bo Lin)
Re: why xor?(look out,newbie question! :) (John Savard)
Re: Crypto Speeds... (Eric Young)
Re: Encryption product for IBM mainframes (Mark Currie)
Re: Passphrase Quality ? ("Stephen P.")
Re: online-Banking: 128-Bit SSL or Java-Applet ? (Marc Koch)
Re: Can someone break this cipher? (Jeffrey Williams)
----------------------------------------------------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Sun, 5 Mar 2000 23:18:07 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> In one previous follow-up I have remarked on some other people's
> suggestions on the internet in the past (I read many times
> such suggestions) of intentionally putting words such as 'bombs'
> in e-mails in order to 'waste' the resources of the interception
> agencies and hence block these. (There was last year even an
> action asking people to do that on a particular day.) I argued why
> that is not useful to achieve the intended purpose. For those at
> the agencies are certainly not unintelligent. They 'must' know
> that no terrorist, unless he is a fool, would ever write such words
[ ... ]
Over and over again, criminals have done all SORTS of stupid things
to get themselves convicted. They've bragged about their crimes to
people they'd never met before while they were in jail. One went to
a bar and bought a round for the house, explaining to the guy sitting
next to him exactly what crime he'd committed to have the money. It
just so happened that not only was this a bar where quite a few off-
duty policemen hung out, and this was a Policeman, but if the guy had
been intelligent at all he'd have noticed that the Policeman in
question was still IN UNIFORM!
In short, you're simply giving the VAST majority of criminals credit
for a GREAT deal more intelligence that they've ever had.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: RC4 and salt
Date: Mon, 06 Mar 2000 00:55:55 -0500
On 5 Mar 2000 09:27:32 -0800, [EMAIL PROTECTED] (David A.
Wagner) wrote:
>> Just append a 32-bit tag to the session key when you encrypt/decrypt.
>> You can even use the time() function if you don't want to code anything
>> else. As long as each session key is unique [which is possible in this
>> case].
>
>No, that's not the standard method (I hope not, anyway!), and to me it
>sounds scary and quite possibly insecure. (See Roos' RC4 analysis.)
Not by appending the 32 bits, weak keys only exist in a limited class of
keys based on the first two bytes of the key, the salt won't affect it
unless the key is less than 15 bits. For a key that short, being one of
the weak keys won't really matter.
>Go read how SSL/TLS do it. Basically, they append a 32-bit unique tag
>to the master key and *hash* them to get a RC4 session key.
Bad idea, in any hash with an even distribution 1 in 255 of every
messages will be one of the weak keys. You would have to hash the
message, detect the weak keys, then generate a new 32 bit tag, generate a
new hash and test that. If you are using printable ASCII for the pass
phrase you can ignore the problem, it is impossible for two printable
ASCII chars to create a weak key. Another solution would be to generate a
padding char and discard it up front for every message, weak keys only
leak one byte of plaintext.
32 bit tags are rather on the small side unless you are keeping track of
them, collisions are a very bad thing for RC4 salts since they are sent in
the clear so are easily detected and matched up. 80 bits would be safer.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: ascii to binary
Date: Sun, 05 Mar 2000 23:28:11 -0600
In article <[EMAIL PROTECTED]>, "Robert P. Rumble" <[EMAIL PROTECTED]>
wrote:
> See Recommended USA Standard Code for Information Interchange (USASCII)
> X.34-1967 (and predecessors) which define encoding some characters and control
> codes into 7 (yes, only seven). I know of no standard encoding into
eight bits,
> other than adding parity.
I don't know if I still have the manuels, but I remember the day that the
the bigger keypunches started to arrive. Before there were 10 rows on
punched cards, the characters were 0 to 9, A to Z (upper case only),12 or
so symbols. Paper tape only had 7 rows of usable holes, with not all
combinations being used.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: Sun, 5 Mar 2000 23:35:40 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Douglas A. Gwyn wrote:
> >
>
> > It's called "spread spectrum" communications and is a well developed
> > field. It offers advantages in noise reduction as well as privacy.
> > The form you seem to have in mind is called "frequency hopping", and
> > is used in many radios, including current combat gear. If you know
> > the terms to search for, given in quotes above, you should be able
> > to find numerous references on the Web.
>
> It is the 'efficiency' of such measures 'in practice' that I suppose
> could be interesting. If the efficiency is indeed very high, then the
> 'value' of encryption (in the narrow sense) would be correspondingly
> somewhat lower in my humber view.
Spread-spectrum radio is VERY common, and reasonably efficient for
what it does. There are a few military systems, that use it for
privacy, but the VAST majority of spread-spectrum systems use it
simply to improve transmission quality. Probably the most widely
used example of the latter is PCS telephones. This does make
interception of such transmissions substantially more difficult but
only raises the price from, say, 3 to 5 digits or so (in US dollars)
so by itself, the spread-spectrum transmission of PCS doesn't provide
a lot of protection.
OTOH, there is a fundamental difference between PCS and the way I'd
guess most military systems work. Part of what a PCS base-station
transmits is a time-signal, which is basically the current seed to
use in the random-number generator that picks what frequencies to use
at what times. If you want security, you use a generator with a
longer period, and you don't transmit the time-base. The handset has
to be coordinated ahead of time, or it simply doesn't work.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Sun, 5 Mar 2000 23:40:54 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> See Recommended USA Standard Code for Information Interchange (USASCII)
> X.34-1967 (and predecessors) which define encoding some characters and control
> codes into 7 (yes, only seven). I know of no standard encoding into eight bits,
> other than adding parity.
There are quite a few of them. If you want to find out about them, a
search for "ISO 8859" should probably turn up a number of references.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Andrzej Nowak" <[EMAIL PROTECTED]>
Subject: ask
Date: Mon, 06 Mar 2000 07:15:28 GMT
do you have FAQ ?
If yes please send me
thank you.
------------------------------
From: "seifried" <[EMAIL PROTECTED]>
Subject: Re: Database Cryptography?????
Date: Mon, 06 Mar 2000 08:52:16 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"David A Molnar" <[EMAIL PROTECTED]> wrote in message
news:89v50i$9gn$[EMAIL PROTECTED]...
> Jonathan Katz <[EMAIL PROTECTED]> wrote:
> >>I am looking for references of the use of Cryptography in
> >>Databases. Thanks for any help,
> >> Jerry
>
> > This question is not very specific, but you might want to check
> > out work on "Private Information Retrieval", which allows a user
> > to query a database but does not let the database know what query
> > the user made.
>
> That's a nice research area -- does anyone use it for anything yet?
> where would you implement private info retreival in the real world?
Medical databases come to mind. Any database with really sensitive
information that even asking for gives hints to people you might not
neccesarily trust (hey, he's looking for information about
psychiatric treatments for pedophiles....).
- --
Kurt Seifried - Senior Analyst
http://www.securityportal.com/
http://www.cryptoarchive.net/
http://www.seifried.org/
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.3
iQA/AwUBOMNyY4b9cm7tpZo3EQJmLACg+5FqMVI301Fw81eGzQD7Yb6s/osAoMu0
/pP2nuQrVfJtMwd9lVXISkaL
=47un
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 6 Mar 2000 08:35:10 GMT
Just to avoid any possible further misunderstandings: My suggestion should be
viewed in context of [EMAIL PROTECTED]'s suggestion to use an 8-bit
substitution cipher in combination with the stream cipher.
I was consequently suggesting using a PCFB protocol in combination with a
stream cipher. It is possible that a PCBC protocol in combination with a
stream cipher would not do. A PCBC protocol alone would surely not.
In a previous article, <[EMAIL PROTECTED]> writes:
>In article <89up6c$h9l$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>> I would suggest an error propagating protocol. If you use e.g. WeakCipher
>> which based on a "P-CFB" mode (is it really called that?) you will neither
>> increase the bandwidth nor have to wait for a signature, and the entire
>> message after any altered bit will be complete gibberish. A "bit flipping
>> attack" won't work either.
>
>But mere error propagation is not enough.
>PCBC mode includes full error propagation, but is not secure
>in the contexts the poster was asking for.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Mon, 06 Mar 2000 11:01:00 +0100
[EMAIL PROTECTED] wrote:
>
> Unfortunately, I don't know enough about the relevant network statistics,
I suppose it helps to get some rough idea, if one could ask some
major provider like AOL for the daily e-mail volume. I find it
difficult to conceive though that a few centralized computing
devices could handle the entire e-mail traffic of the world. And,
besides, voice communications are also within the 'official' domain
of the interception networks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Mon, 06 Mar 2000 11:01:37 +0100
Jerry Coffin wrote:
>
> Over and over again, criminals have done all SORTS of stupid things
> to get themselves convicted. They've bragged about their crimes to
> people they'd never met before while they were in jail. One went to
> a bar and bought a round for the house, explaining to the guy sitting
> next to him exactly what crime he'd committed to have the money. It
> just so happened that not only was this a bar where quite a few off-
> duty policemen hung out, and this was a Policeman, but if the guy had
> been intelligent at all he'd have noticed that the Policeman in
> question was still IN UNIFORM!
>
> In short, you're simply giving the VAST majority of criminals credit
> for a GREAT deal more intelligence that they've ever had.
You are right. In crypto, we also know that one should not depend
on the secrecy of an algorithm but on the strength of the algorithm,
since through indiscretion the opponent may obtain the algorithm.
It is also commonly known that operator errors had non-trivially
contributed to the cracking of Enigma. Terrorists are less likely
to be careless than ordinary criminals. But, of course, even some
specially trained secret agents have known to be caught because of
very minor errors. Once I learned from someone of an 'excuse' of
the inevitable human errors: Even hardware has errors, cf. MTBF.
(My addition: not to mention software.)
M. K. Shen
------------------------------
From: Bo Lin <[EMAIL PROTECTED]>
Subject: Re: Database Cryptography?????
Date: Mon, 06 Mar 2000 10:35:29 +0000
E. B. Fernadez, R.C. Summers, C. Wood, "Database Security and Integrity"
Addison-Wesley, 1981.
An excellent book written by three IBM researchers nearly twenty years
ago. =
Bo Lin
Motorola
Geraldo Xex=E9o wrote:
> =
> I am looking for references of the use of Cryptography in Databases.
> Thanks for any help,
> Jerry
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: why xor?(look out,newbie question! :)
Date: Mon, 06 Mar 2000 11:15:23 GMT
On Sun, 05 Mar 2000 15:43:48 GMT, [EMAIL PROTECTED] wrote, in
part:
>Is it just for
>speed,or because you can use a single function for
>both encrypt and decrypt or there's something
>more to it?
No, addition modulo 256 is just as good.
XOR is to be preferred to addition modulo 65536, though, because some
computers are designed so that the "first" byte of two bytes is the
least significant part of a number instead of the most significant
part, so that using addition over a larger item than a byte creates
the need to define what one is doing more explicitly.
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Crypto Speeds...
Date: Mon, 06 Mar 2000 22:50:31 +1000
[EMAIL PROTECTED] wrote:
> In article <MPG.132479671d267e24989680@localhost>,
> Wei Dai <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > > Is there any place on the Internet where we can find specific
> > > information about speeds with specific processors and specific
> > > operations? (Benchmarks, etc...). Fr example, what is the time
> required
> > > by Processor 'X' at speed 'Y' MHz to perform an hashing of a (say)
> 10Mb
> > > document using (say) RIPEMD160?
> >
> > http://www.eskimo.com/~weidai/benchmarks.html
> >
> > It's for Intel Celeron running at 450 MHz, but you can download the
> > benchmark program (part of a free crypto library) and run your own
> > benchmarks on other processors.
> >
>
> Yes I looked at your site before..pretty good stuff....would be helpfull
> to know timmings comparisons in handcoded assembler... just a
> thuought...alot of work..
Some comments from my recent and past experience.
For most crypto using non-standard constructs, hand coding is a big win.
Most CPUs give a 2x speedup for RSA/DSA/DH etc because one can
access 32*32->64, while C does not (or it implements 64*64->64 etc).
For some CPUs like the PA-RISC, I've seen 5 times speedup for hand coded
ASM for bignum vs C code. This is basically because PA-RISC does 'unusual
things' like using the FP unit for integer multiplication. Trick with
keeping values in FP registers for multiple operations don't tend to
be performed by C compilers. I've also seen 3 times speedup because the
Compiler was stupid :-).
For General algorithms like RC4/SHA-1/MD5, for most modern OOO CPUs,
it is normal for good C code, loop unrolled, to be about %70-90 of
what the ASM programmer can get. Again, normally the extra performance
is achieved via savings in memory access etc.
For these CPUs the compiler often has an advantage of more embedded knowledge
of
the micro architecture than is publish for the general population (or to
keep in ones head).
eric
------------------------------
Subject: Re: Encryption product for IBM mainframes
From: [EMAIL PROTECTED] (Mark Currie)
Date: 06 Mar 2000 13:04:27 GMT
In article <89lg9o$12nq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>A new encryption product for IBM (OS/390) mainframes
>is being released. We seek betatesters for it (we'll grant them
>a right to use the product during 6 months).
>Contact us if you are interested.
>http://os390-mvs.hypermart.net/megaceng.htm
>
>
IBM OS/390 enterprise servers already have a built in crypto service. From the
G5 upwards, they have a FIPS140-1 level 4 certified hardware crypto processor.
I see from your web site that you do offer other features such as Blowfish and
being able to integrate with other apps, but I am curious as to why you do not
use the inherent crypto core ? Are you mainly intending to sell to users of old
mainframes ?
Mark Currie
------------------------------
From: "Stephen P." <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Mon, 06 Mar 2000 13:17:34 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
tell them to use some poem as the passphrase !? no, sorry, i'm left
muddled. but i do have a question about all this. how can i go about
generating a password that i can't remember but can easily produce if at my
machine? and .. please .. don't tell me to go ask alice.
my passphrase is a single stream of a mix of numeric and alphabetic
characters. it might be tough to guess but i'm a wimp and easily say
"Uncle" [not that anybody's interested, but..].
steve
jungle wrote:
>
> IMO you did get all this wrong ...
>
> my way is to never remember pass text ...
>
> you will not spit a dummy only when you don't know the dummy,
> is it clear now for you ?
>
> Guy Macon wrote:
> >
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (jungle)
> > wrote:
> > >there is one huge difference, this one I can tell you ...
> > >> > >you know your pass text all the time [ you did your pass text
> > >memorized very well ], therefore several methods that are child play
> > >simple to use & execute exist to get this pass text from you
> > >
> > >to get your "simple two sentence mnemonic", irrespectively of your
> > >resistance any time the AGENCY WOULD LIKE TO DO IT ... when agency
> > >will like to get your "simple two sentence mnemonic", you will spit it
> > >out on every request, like a baby spit a dummy
> > >
> >
> > Let me get this straight. You are advocating using a passphrase that
> > is hard to remember so as to avoid someone torturing it out of you?
> > Let me guess... you keep it on a post-it note on your monitor, right?
> >
> > I have this mental picture of them increasing the torture and you
> > REALLY, REALLY, *REALLY* wishing that you could remember your
> > passphrase...
=====BEGIN PGP SIGNATURE=====
Version: 6.5.1ckt http://irfaiad.virtualave.net/
iQA/AwUBOMOv8FMZCmMtHP6pEQLxxwCggOIbcid+2xZdo9okLL1GnE3WhGwAn2ut
HMupoYsG4w3P2Z95q6NxOdLQ
=mrdo
=====END PGP SIGNATURE=====
------------------------------
From: Marc Koch <[EMAIL PROTECTED]>
Subject: Re: online-Banking: 128-Bit SSL or Java-Applet ?
Date: Mon, 06 Mar 2000 14:27:02 +0100
Hi Phil,
please find below my suggestions:
Phil wrote:
>
> As developer of ecommerce-applications (online-banking related) I have to
> evaluate the best method of SECURE TRANSMISSION and USER AUTHENTIFICATION.
>
> The 2 most realistic Alternatives are:
>
> No 1: Java Applet solution with 128-Bit encryption (maybe with port-hopping
See below.
> No 2: 128-Bit Browsers (now available even outside of the US.)
When you are in a bank team, use SGC (Server Gated
Cryptography) Keys for the server from i.e. VeriSign
instead. Those keys switch even an international browser
(40 bit) to 128 bit.
>
> User Authentification in both cases with digital signatures (certificates),
> issued by official authorities or banks.
Especially when in a bank do not use internally generated
certificates. The reason is, that when a transaction comes
to court trial, the transaction can be brought in doubt.
Better is to work with a trusted third party company, i.e.
those, who make credit cards, eurocheque cards and so on.
That brings the bank out of the line of fire.
>
> The biggest advantage of No. 2 are costs: Programming large Java solutions
> is far more expensive than using SSL.
Well, actually SSL has only one halfway secure cipher left
which is RC4. There are some of the shelf solutions from
RSA Security, Inc. or Brokat AG. The costs of a compromised
e-banking solution can not be estimated.
>
> QUESTION:
> - What advantages / disadvantages does 1. / 2. have ?
>
> I appreciate your help,
>
> Phil
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Date: Mon, 06 Mar 2000 08:04:27 -0600
You raise a good point about how long the message must remain secure. Knowing your
security needs is a major requirement in designing a secure system. If you need to
keep messages secure for 1 hour, a system which will keep them secure for a millenium
may be overkill (if it costs the same as a system which will be secure for 1 hour,
and by costs, I mean money, CPU time, etc, then you might as well go for the gusto).
Personally, I'm just a bog-standard amature. I enjoy stuff that I can do in my head
(I find it relaxing and a good way to keep my memory sharp). I'm also involved in
telecommunications, so I find it useful to understand the various aspects of
security. If I had the time, and interest, to pick away at MJ's cipher, I'd base a
lot of my actions on feelings; do the patterns remind me of things I've seen before.
In debugging software, of ciphers, experience counts for a lot.
LL&P
Jeff
Daniel wrote:
> On Fri, 03 Mar 2000 15:47:28 -0600, Jeffrey Williams
> <[EMAIL PROTECTED]> wrote:
>
> >Daniel,
> >
> >There are several reasons for wanting the algorithm. A couple that come to mind
> >immediately are:
> >- it may take a lot of effort to break a single encryption and, other than the
> >intellectual glory, there really is no reward for the effort;
> >- the author may not have provided a long enough text to break the encryption.
> >
> >There are a variety of tools/directions which a professional might use. Much
> >would depend on what, if anything, you know about the ciphertext, the recipient,
> >the sender, the possible type of data being sent, the method of transmission,
> >etc. I suggest that you start by reading Bruce Schneier's tome (Applied
> >Cryptography).
> >
> >You might also want to read the FAQ. It talks about "can you break this"
> >challenges.
> >
> >Jeff
>
> Thank you for replying. I've started to read "The Code Book" by Simon
> Singh and "Decrypted Secrets" by F.L. Bauer. I've worked myself
> through "Initiation � la cryptographie" by Gilles Dubertret and read
> (most) of D. Kahn's gigantic/fantastic book.
>
> Of course, there's no reward for breaking someone's cipher other than
> intellectual glory - unless one works in a modern black chamber :-)
>
> But suppose that the cipher by Miss Stevens would contain text like
> "attack the nuclear site this day at that hour". Disaster would have
> striken *long* before the cipher is broken. If one would actually
> break the cipher even only 1 day after the disaster, the encryption
> would have served its purpose : make a text unreadable to others
> unless they put in a lot of human resources/time...
>
> I suppose the original text by Miss Stevens is in English and I also
> suppose she's done a Vig�n�re after a Caesar-like encryption on the
> clear text. Does double encryption make a cipher stronger? How can
> we find out what she has done to encrypt a message? What would a
> professional cryptographer do besides collecting messages and hope for
> some human error? In the books there's always hindsight on the facts.
> They used this approach for this and that reason and hey, bingo!
> That's always easy;-) Besides frequency analysis, what would you do
> on an unkown cipher (like the one from Miss Stevens)? I have tried
> several approaches, but all in vain...
>
> Daniel
------------------------------
** 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
******************************
