Cryptography-Digest Digest #914, Volume #10 Sun, 16 Jan 00 16:13:00 EST
Contents:
Re: Cryptanalysis of R.A.T (Jeff Lockwood)
NOTICE: Bug fix in RNG (Tom St Denis)
Implementing access controll in embeded controller ("Niels Erik Danielsen")
Re: Simon Sigh Enigm ("James Taylor")
German digraph frequencies ("John Lupton")
Need Volunteers T hekp fill in my Masters Degree Survey on (paul mckee)
Announce: CryptaPix 2.20 (Kent Briggs)
Re: UK Government challenge? (Angus Walker)
1on1lite (Was: Re: Echelon monitors this group) ("Thomas J. Boschloo")
Re: UK Government challenge? (Jim)
Re: Forward secrecy for public key encryption (lcs Mixmaster Remailer)
Re: Ciphers for Parallel Computers (Mok-Kong Shen)
Re: Cryptanalysis of R.A.T (David Wagner)
Beale ciphers ("Heath Smith")
Re: is signing a signature with RSA risky? (Tim Tyler)
Re: is signing a signature with RSA risky? (Tim Tyler)
----------------------------------------------------------------------------
From: Jeff Lockwood <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis of R.A.T
Date: Sun, 16 Jan 2000 23:13:15 +1100
Jeff Lockwood <[EMAIL PROTECTED]>
PGP public key:
homepages.ihug.com.au/~satan/pgpkey.asc
On 16 Jan 2000, Scott Contini wrote:
> Earlier this week, a cipher called "R.A.T." was posted on this newsgroup.
> This cipher is very weak, and I will show here how to cryptanalyze it.
> I remark that somebody else named Poncho gave an argument that it is
> weak, but my attack is simpler. The original positing of the R.A.T.
> cipher is at the end of this post.
>
> My attack is a known plaintext attack - I assume you know plaintexts
> and their corresponding ciphertexts. However, to simplify explanation,
> I will present it as a chosen plaintext attack, and I leave it to you
> as an exercise to convert it to known plaintext. The attack is
> essentially the same in both forms.
>
>
> This is the first attack that came to my mind. There may be simpler
> attacks, but this shows that R.A.T. is a very weak cipher and should
> not be used in any security application.
Thankyou for this reply.It was most helpfull.
All I need to fix this is check if A = B after B is written out, and
change either A or B if it does.
I would be pleased to learn if there are any other weaknesses in it
Jeff Lockwood <[EMAIL PROTECTED]>
PGP public key:
homepages.ihug.com.au/~satan/pgpkey.asc
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: NOTICE: Bug fix in RNG
Date: Sun, 16 Jan 2000 13:54:02 GMT
Ok guys, I made a booboo when I 'cleaned-up' the rng. I forgot to set
the rng_status flag before dumping the first outputs, as aresult the
first outputs were not dumped.
I double checked the rest of the source [hey the algorithms are copied
from Knuth...] so the corrected version is now available online at
http://www.dasoft.org/tom/rng.c
Email me at [EMAIL PROTECTED] if you have any comments/questions.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Niels Erik Danielsen" <[EMAIL PROTECTED]>
Subject: Implementing access controll in embeded controller
Date: Sun, 16 Jan 2000 15:25:03 +0100
Hello
I'm not sure his is the correct NG, but I will give it a try.
I have no experience of encryption technology etc.
I'm designing software for an embedded controller, controlling an industrial
process.
This controller has local and remote possibilities for operating the
machine, and the system has different access levels ranging from gathering
status, and operating the machine, to system configuration.
The system is not running on any PC hardware, and the operating system is
an RTOS.
We produce about 1000-2000 machines a year, and have about the same number
of users on the machines.
The machines is scattered around the world, and the 'users' is anything from
local operators, and third part service technicians, to experts from the
mother company.
Today the security is very weak since the 'password' is a simple 4 digit
number, valid for all machines, and known by everyone :-(
I would prefer a system with a possibility of issuing a login name, and
password to everyone, with optional time and serial number limitation of the
passwords.
And if a technician is having a problem that can't be solved by his present
access level, he can contact the Service Support department, and get a new
password, with a 'promotion' to 'superuser' on the machine with a particular
serial-number valid for one week.
This technique resembles a software license key system, where the software
distributed to all the customers is the same.
But in order to use the software on a machine with a given Network card MAC
address, you need a special license key in order to activate the software.
We have the following information in our equipment.
Serial number
Time and Date from a GPS receiver.
Name of the site where it's installed.
I imagine an algorithm like this.
1) User enters login-name and password.
2) By analyzing the password it's determined if it have any limitations,
e.g.. Year and Serial-number.
3) The login-name and password is string hashed.
4) The login-name, password, the year from the GPS receiver, and the serial
number is passed trough an algorithm (S-Box'es ?) and is verified against
the keys for the different access levels.
A PC program should then be able to generate a password to match any given
username, and limitations, and access level, and keep track of the issued
passwords.
Questions
I this the way to go ? I guess others have solved the same kind of problem.
What kind of algorithms can be used in this application ?
Is there any commercial products ? Freeware pieces of C code etc. ?
What worries me is how keys is distributed, is it always possible to
generate a password for a user with a given login name, limitations, and
access level ?
--
Kind regards
Niels Erik Danielsen
Herning, Denmark
------------------------------
From: "James Taylor" <[EMAIL PROTECTED]>
Crossposted-To: fido7.crypt,fr.misc.cryptologie
Subject: Re: Simon Sigh Enigm
Date: Sun, 16 Jan 2000 15:10:57 -0000
no, I think I didn't make myself clear. My version is English. One copy of
each code. Each code translates into a different language.
--
Emailed from James Taylor at [EMAIL PROTECTED]
It's a small world, so you've got to use your elbows a lot.
We are born naked, wet, and hungry. Then things get worse.
------------------------------
From: "John Lupton" <[EMAIL PROTECTED]>
Subject: German digraph frequencies
Date: Sun, 16 Jan 2000 16:01:13 -0000
Does anyone have a link to German digraph frequencies please
thx
------------------------------
From: paul mckee <[EMAIL PROTECTED]>
Subject: Need Volunteers T hekp fill in my Masters Degree Survey on
Date: Sun, 16 Jan 2000 16:16:04 +0000
Thanks for at least reading my posted message:
If you could just visit the site below and fill in the survey....
Theres no prizes or catches just the undying gratitude of a Scottish
student whodoes not want to send unsolicited mail
http://websites.ntl.com/~frances.mccormack/msc.htm
If there is any questions or you just want to bend my ear about any
errors
email me at [EMAIL PROTECTED]
Many Thanks
Paul McKee
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Announce: CryptaPix 2.20
Date: Sun, 16 Jan 2000 16:17:27 GMT
Due to the relaxation of export restrictions on January 14 by the U.S.
Government, my CryptaPix program is now available to non-U.S. residents
in its full strength version.
CryptaPix is a graphics viewer with secure 160-bit Blowfish encryption
that allows users to keep their image collections private. JPG, GIF,
TIF, PNG, PCX, and BMP formats are supported. The program includes
thumbnail, slideshow, and extensive file management routines.
The shareware version of CryptaPix is available here:
http://www.briggsoft.com/cpix.htm
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Angus Walker <[EMAIL PROTECTED]>
Subject: Re: UK Government challenge?
Date: Sat, 15 Jan 2000 19:45:18 +0000
Managed to find three so far, but then I'm no expert. Definitely
steganography - once you find them it takes 10 seconds to decode them
(so far).
--
Angus Walker
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To:
alt.anarchism,alt.computer.security,alt.security,alt.security.espionage,alt.security.pgp
Subject: 1on1lite (Was: Re: Echelon monitors this group)
Date: Sun, 16 Jan 2000 18:18:20 +0100
Christian Biesinger wrote:
>
> Andrew Kwiatkowski schrieb:
> >
> > Anyone worried about they mail being monitored.
> > Just use 1on1Lite, that will stop them.
> >
> > An Anarchist
> >
> > ps.Check out www.1on1Lite.com
>
> That Server does not exist.
Phew, I almost had to vomit when I visited their webpage at
<http://www.1on1mail.com/index.html>. Strange sensation, maybe this was
also due to the fact that I forgot to take my Efexor pills this morning,
that makes me vomit too after a few days (bleahg, interesting
subjects!).
Well, here are the qoutes we've all be waiting for directly from their
website (IE from now on, it is not Christian who is saying things!):
> Registration is the cornerstone of 1on1mail security.
> During registration you are asked to provide a password to protect
> the mail stored on your client. The password you choose is only used
> to protect the mail stored on your client. Every other password is
> selected by the server on your behalf. This prevents any user from
> compromising mail security by selecting a weak or obvious password.
Wow, this is great for your e-mail security. No weak passwords!! You'll
have to write them down of course, if I understand correctly.
> We have even bypassed the arguments about how random a
> random number generator can be. Passwords are derived from truly
> random and totally unpredictable sources such as stock market quotes,
> background noise from several university radio telescopes, and
> internet search times.
Wow, stock quotes. Now *THAT* is a good source of randomness. I'm
getting a warm fuzzy feeling. I wonder where they get their random
background noise BTW <grin> www.nasa.org?
> In addition to providing an initial password, the registration
> process also requires the user to generate a unique RSA key pair. RSA
> is far to cumbersome to use to protect individual messages, so it
> provides that backbone of the key management system. In layman's terms,
> it allows the server to exchange password information with the client.
What is a man-in-the-middle? Bye bye, password.
> 1on1Lite prevents any would-be Spammers by the simple expedient of
> requiring all correspondents to first make a contact request with the
> person they wish to correspond. If the request is denied then no
> communication can take place, and no further contact requests are permitted.
So now you get spammed with request messages?! Better filter them then,
right? Unfortunately that also blocks other users from sending you
messages. So now they found a way to kill killfilters?!
> I would like however, to extend my thanks to my Bruce Schneier,
> without whom may of the encryption technologies would not exist.
> Although he was not directly involved in the production of 1on1Lite,
> his excellent book "Applied Cryptography" provided the catalyst for
> the whole product.
That's nice to say. I bet he'll be pleased <grin>. They even have a
challenge. You can win USD 50000 if you can crack their 448 bit blowfish
encrypted message! <http://www.1on1mail.com/k50000.html> Or is it 2048
bit RSA, I'm not sure from what it says at their site, but we've just
broken 512 bits, so why not?!
> Complete security is more than encryption. Only
> 1ON1Lite incorporates anonymity and self-destruct
> capabilities to email.
If you call using only one hop anonymity yes. Self-destruct, that's just
great, really great. Like noone will ever be able store your message
somewhere, encrypted or non-encrypted. I wish they would put that
feature in Scramdisk 3.0 <http://www.scramdisk.clara.net/>.
Bruce, please visit this site. It will make you chuckle for at least a
whole week, they all seem so serious. And why not? They got in wired,
bbc news, news.com, this really _is it!_
I just know I'm going to laugh the whole week at random intervals, and
everybody will think I am wierd. [BTW My sister who is working in the
same room as where I am already thinks I am going insane, and she knows]
Haha,
Thomas
--
Boycot Intel Pentium III <http://www.bigbrotherinside.com/>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: UK Government challenge?
Date: Sun, 16 Jan 2000 17:58:22 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 15 Jan 2000 19:45:18 +0000, Angus Walker <[EMAIL PROTECTED]>
wrote:
>Managed to find three so far, but then I'm no expert. Definitely
>steganography - once you find them it takes 10 seconds to decode them
>(so far).
Any chance that you'll be helping then to run 'Echelon' in the near
future, then?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
Date: 16 Jan 2000 18:40:02 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Forward secrecy for public key encryption
David Wagner writes:
> But what if we choose n as the product of, say, four primes, n=pqrs?
> I *think* that known factoring algorithms aren't any better at factoring
> product-of-four-prime composites than they are at factoring RSA-composites
> of the same size. If I got that right, we'd only need to do discrete
> logs mod 256-bit primes to use a 1024-bit n, and that sounds a little
> more realistic.
This was one of the alternatives in the identity based crypto scheme of
Maurer & Yacobi, as discussed in the cypherpunks thread at
http://www.inet-one.com/cypherpunks/dir.1998.06.01-1998.06.07/msg00041.html:
: Maurer suggests as appropriate parameters a modulus n which is a product
: of three or four prime values each of 60-70 digits (200-230 bits). Each
: prime p should be such that (p-1)/2 is also prime. This will provide a
: modulus of up to about 920 bits.
:
: According to the paper's analysis, the best algorithm for attacking a
: number of this form is elliptic curve factoring, which is suitable for
: finding relatively small factors. As of 1991, the largest factor found
: using this method had 38 digits. Finding a 70 digit factor would take
: 270 times longer.
:
: Creating keys will require solving the discrete log problem modulo each
: of the primes. Maurer states that for primes of 65-70 digits the
: algorithm is feasible on a small to medium size computer, again as of
: 1991.
Based on the message here from Scott Contini the difference in difficulty
may not be sufficiently great.
The other idea from Maurer was to use n = pq, but to choose p and q
such that p-1 and q-1 are smooth, making it easy to compute discrete logs
mod p and q. The problem is that this lets the p-1 factoring algorithm
work. There is still a square-factor difference in difficulty, but given
that the maximum feasible work factor for the key creator is on the order
of 2^30, this is not quite enough for comfort.
The advantage of this system is that you can use Pohlig-Hellman to find
the discrete logs, which is very simple, just Pollard rho or equivalent,
plus Chinese Remainder. Using strong 256 bit primes you'll need some
kind of sieving code which is probably considerably more complex.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Date: Sun, 16 Jan 2000 20:08:23 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > ... I don't yet clearly see an advantage that pertains to only one
> > side of the antagonist pair user-analyst. Higher speed can be of
> > 'advantage' to both sides.
>
> I think the assumption is that the work factor for the cryptanalyst
> goes up at a higher rate (complexity-wise) than the work factor for
> the encryptor, implying that for some sufficiently large key size,
> the cryptanalyst can't afford the resources while the encryptot can.
> Whether or not this assumption is correct is debatable.
If one can arrange that brute-force is the only practically viable
approach of attack, then the analyst's effort is of the order
of the key space in terms of the effort of the encryptor. In that
case introducing a small multiplicator for the computing load
may render the analyst's work infeasible while the speed degradation
may still be tolerable to the communication partners in a large
category of practical situations.
The question of how to force the analyst to brute-force is certainly
an essential and interesting one. I am yet ignorant of a good answer.
In an admittedly very imprecise sense I suppose that the analyst is
generally forced to brute-force if the algorithm design is such that
the whole scheme cannot be formulated in terms of a small set of
mathematical equations of fairly simple nature with the key as
the variable. I should very much appreciate it, if experts would
like to give their opinions/recipes of enforcing brute-force.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Cryptanalysis of R.A.T
Date: 16 Jan 2000 11:04:25 -0800
In article <[EMAIL PROTECTED]>,
Jeff Lockwood <[EMAIL PROTECTED]> wrote:
> All I need to fix this is check if A = B after B is written out, and
> change either A or B if it does.
No. All you need to do to fix it is to use a strong cipher.
This one is weak, and IMHO cannot be easily repaired.
(Don't fall into the trap of thinking you will patch up every attack
found. That's a losing proposition -- when people find fundamental
flaws in a scheme, no patch-up job should be trusted.)
------------------------------
From: "Heath Smith" <[EMAIL PROTECTED]>
Subject: Beale ciphers
Date: Sun, 16 Jan 2000 14:09:46 -0800
Anyone out there working on the Beale Ciphers?
Has anyone ever found any proposed solutions?
Has anything been found beyond the Gillogy strings?
Thank you.
[EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is signing a signature with RSA risky?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 16 Jan 2000 20:07:29 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Pascal Scheffers <[EMAIL PROTECTED]> wrote:
:> : With RSA, there is the risk that if you encrypt before signing the
:> : other can fake a message. This is described on p473 of Applied
:> : Cryptography 2nd.Ed.
:>
:> BS says there that: "It makes sense to sign a message before encrypting
:> it".
:>
:> Any users who follow this advice should be aware that if the signature may
:> be publicly validated, this can provide a concrete halting criterion -
:> which allows keys to be automatically rejected on every signed message
:> sent.
: That's irrelevant in practice if the key space of the encryption is
: large enough.
This seems a frequent objection to points I try to make in this forum
along these lines.
My reply is that there are a larg number of ways in which the keyspace may
be compromised, from a bad RNG generating the keys, to recovering partial
documents, and from torturing operatives, to using cameras with partly
obscured vision of an important keyboard, from an attack on the cypher
to stupid errors on the part of the operatives.
: Typical messages will always have sufficient redundancy to
: be automatically verified or rejected.
The idea behid compression is to eliminate such redundancy. *If* you
compress your messages before encryption, your statement suddenly becomes
rather questionable.
:> I believe you should normally sign outside at least one layer of strong
:> encryption, because of this (with different key bits being used on "either
:> side" of the signature).
: This is adding significant complexity to your protocol, for little or no
: security gain, IMHO.
That depends on whather you're super-encyphering already.
If you're doing this, then there seems to be little difference in complexity.
If you're trusting a single algorithm; well, that's up to you ;-)
The security gain - as always - is difficult to quantify.
Your stated reason for believing it to be negligible seem to have not
taken into consideration some types of attack, though.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
All programmers want arrays.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is signing a signature with RSA risky?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 16 Jan 2000 20:52:22 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> No. If you're using a signing method with a publicly available key, and
:> you have the information that the message has been signed by a particular
:> party (who has perhaps been identified by traffic analysis), then
:> failure of signature verification allows you to systematically reject
:> keys used in the main encryption, without performing any other sort of
:> frequency analysis on the message at all.
:>
:> If the message's signature verification fails, you /know/ you are not
:> using the correct key to decrypt (assuming the message is not corrupt).
: O.k., I see. But then again, there are plenty of ways
: for you to found out if you are decrypting with the
: write key or not, simply by observing the message you
: get when you decrypt, depending on the system, you will
: probably be looking for something specific.
Perhaps your file will be compressed? If so - if the compression is good
enough - all your decrypts may resemble plausible messages - or they
may resemble them closely enough that rejecting them *automatically*
is a little bit tricky.
: One example would be a specific header like "From: ".
Normally, such a text is in a header, and isn't encrypted in the first
place.
: You can create your own little algo that searches for this, if it's there
: you accept, if it's not you reject. So I don't think that
: a use of "encrypt then sign" could be justified for that
: reason [...]
If the attaker has a "certain" halting criteria, outside the signature,
it makes no difference. If you can avoid it you should not be giving your
opponent's "certain" any halting criteria in the first place, though.
Signatures are just one example of such a thing you should try to avoid
providing inside a message, for fear of allowing automated rejection of
keys.
: "encrypt then sign" is a bad usage of crypto safe crypto protocols.
The Abadi and Needham reference you cited earlier is not a blanket
reason for signing before encryption. It is true that you should not
assume that the contents of a signed encrypted message are known to the
individual that signs it; however this may be avoided elsewhere in your
protocol. They also say: "signing before encrypting is not a bill of
health".
Allowing the possibility of faked messages is something to be avoided;
and as a result, signing on the outside of all encryption is questionable.
It seems to me that signing the message /anywhere/ beneath encryption
runs some risk of giving away the key required to decrypt up to that
point by a process of brute-force searching.
Signing inside /all/ encryption would be likely to result in such a search
eventually identifying the plaintext.
Signing inside /some/ encryption would be likely to result in such
a search eventually identifying part of the key - arguably a result
that's even worse, because of the smaller keyspace that requires
searching to decrypt as far as the signature.
I do not know how it's possible to publicly sign and authenticate a
message without causing either /some/ security problems, or signing
outside all encryption - and allowing some possibility of attackers
faking messages.
Short of using an OTP, anyway ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Computer engineers do it bit-by-bit.
------------------------------
** 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
******************************
