Cryptography-Digest Digest #436, Volume #12 Mon, 14 Aug 00 08:13:01 EDT
Contents:
PGP Algorithm ("Herry Koh")
Re: Copyright isue - SERPENT (Runu Knips)
Re: PGP Algorithm (fvw)
Re: PGP Algorithm (Runu Knips)
Playfair-Analyze ? (Ronny Burow)
Re: Crypto Related Professional Attitude (Runu Knips)
Re: PGP Algorithm ([EMAIL PROTECTED])
Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ? (Mark Currie)
verification (haifeng)
Re: OTP using BBS generator? (Tim Tyler)
Re: 1-time pad is not secure... (Mok-Kong Shen)
Re: 1-time pad is not secure... (Mok-Kong Shen)
Re: 1-time pad is not secure... (Mok-Kong Shen)
Re: Playfair-Analyze ? (Mok-Kong Shen)
Re: OTP using BBS generator? (Tim Tyler)
Re: Random Number Generator (Tim Tyler)
Re: Random Number Generator (Tim Tyler)
Re: Random Number Generator (Tim Tyler)
Re: BBS and the lack of proof (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Herry Koh" <[EMAIL PROTECTED]>
Subject: PGP Algorithm
Date: Mon, 14 Aug 2000 17:29:58 +0800
Hi, being new to this field I am currently trying to understand some of the
crypto algorithms around. So can anybody tell me where I can get a
description of the PGP algorithm. I don't really want any software, just the
algorithm.
Thank
Herry.
--
=====================================================
Click here for Free Video!!
http://www.gohip.com/free_video/
------------------------------
Date: Mon, 14 Aug 2000 11:23:47 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Copyright isue - SERPENT
Tor Rustad wrote:
> "tomstd" <[EMAIL PROTECTED]> wrote in message
> > Runu Knips <[EMAIL PROTECTED]> wrote:
> > > No, the only AES algorithm with a license problem is RC6, which
> > > will only be free if it becomes AES, which is unlikely because
> > > it doesn't offer key agility.
> >
> > But's it is far simpler to implement, it's from RSA and it's
> > yankee material. Seems like enough for a technical round nose.
>
> RC6 is not simple to implement. What matters is HW
> implementations, not SW implementations. Why? Mony!
Well, in fact, both HW and SW implementations matter.
> US know what is good business, RC6 simply isn't it.
> However, I guess they have a problem now, because
> as far as I can see, the two best candidates are
> Serpent and Rijndael.
Hmm.
May I ask why you favor Rijndael over Twofish ?
AFAIK 2fish substantly more secure, but not
much slower.
> So if RC6 is choosen anyway, they have to choose another
> winner aswell.
IMHO the main advantage of RC6 over the other
algorithms is that it is that easy to implement
in SW on ordinary PC hardware.
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: PGP Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2000 09:35:48 GMT
<8n8doe$ht2$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>Hi, being new to this field I am currently trying to understand some of the
>crypto algorithms around. So can anybody tell me where I can get a
>description of the PGP algorithm. I don't really want any software, just the
>algorithm.
There is no 'the pgp algorithm'. Pgp uses several well-known algorithms.
For more info, have a look at pgp.com, pgpi.org
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
Date: Mon, 14 Aug 2000 11:37:33 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: PGP Algorithm
Herry Koh wrote:
> Hi, being new to this field I am currently trying to understand some of the
> crypto algorithms around. So can anybody tell me where I can get a
> description of the PGP algorithm. I don't really want any software, just the
> algorithm.
Sorry, I don't understand this. PGP isn't an algorithm, it is a
cryptographic
program, or collection of programs. Just like its GNU variant GnuPG. It
contains masses of algorithms, such as RSA, ElGamal, IDEA (only in the
older
versions), Blowfish, Cast5(?), Twofish, SHA-1, RIPE MD160, Tiger, plus a
mass
of file formats for the different kinds of data.
PGP Homepage: http://www.pgpi.org/
GPG Homepage: http://www.gnupg.org/
------------------------------
From: [EMAIL PROTECTED] (Ronny Burow)
Subject: Playfair-Analyze ?
Date: 14 Aug 2000 09:51:13 GMT
Hello all,
please excuse me. I'm a newbie. I like the classical Chiffre-Systems and we
use some for our RPGs. Now i need some help with Playfair. Where can i get
a simple description how to analyze a playfair-chiffre ? Please help.
TIA
Ronny Burow
PS: Please excuse my terrible english. I'm a german and 10 years out of
school. ;-)
--
Wenn man diese CD rückwärts spielt, hört man satanische Verse,
schlimmer noch, wenn man sie vorwärts abspielt, installiert sie Windows 98
------------------------------
Date: Mon, 14 Aug 2000 11:52:06 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Crypto Related Professional Attitude
tomstd wrote:
> Actually I apologize since Silverman (Bob) and Wagner do
> participate in the group. Sorry for generalizing there.
Yep, and Schneier posts sometimes here, too.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Algorithm
Date: 14 Aug 2000 06:39:23 -0400
Herry Koh <[EMAIL PROTECTED]> wrote:
> Hi, being new to this field I am currently trying to understand some of the
> crypto algorithms around. So can anybody tell me where I can get a
> description of the PGP algorithm. I don't really want any software, just the
> algorithm.
It used to be that one could answer that question. Back when PGP was at
version 2.3 and use RSA for the public key encryption (for the session
key) and IDEA (to encrypt with the session key).
Now, however, PGP can use various algorithms for both the public key and
symmetric encryption.
So ... check for info on public key encryption (and various algorithms,
e.g. RSA) as well as symmetric encryption (e.g. IDEA, DES and triple_DES).
------------------------------
Subject: Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 14 Aug 2000 10:41:34 GMT
In article <XU8l5.1087$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
< snip >
>
>The WAP GW is a true man-in-the-middle, but this is not the most difficult
>sucurity problem for me. Today many transactions go trough GW and routers
>without being a major security risk, we already have secure means/protocols of
>doing this.
Yes, if you add extra crypto on top of WTLS and SSL you can defeat the "gap"
but then you don't need WTLS and SSL. This will probably happen with banking
apps but for normal e-commerce as it is now done on the web using SSL, the
industry needs a standard and that is what WTLS is supposed to provide but as
yet it doesn't provide e2e.
>The problem starts with the chip (SIM/WIM), as long as the banks
>have no control over this security, we simply can't design a system with
>end-to-end security. It doesn't matter how secure the WAP GW is, if we can't
>trust the chip card used the mobile phone, there is no way to trust the
>transaction.
This may not always be true, it depends on what type of transaction you want to
do. If you are doing transactions that you can already do with SSL, then
ignoring the problems with this method, I see no extra imposed problem using
the Telco's SIM to store your ID/credit card number. However, if you want to
use the SIM as a cash card or wallet then I agree, cash cards will always have
to meet with bank's approval.
>
>There is a chain of trust, and it begins even before the chip is produced.
>However, it doesn't help much that the A3, A5/1,A5/2 and A8 has been reversed
>engineered, and some major design flaws where discovered during the proccess.
>Even if these algorithms had been cryptographic strong, there are many other
>important security issues like key management, card production, card issuance
>etc.for which there are lessons yet to be learned for the mobile community.
Perhaps if the Telco's were to get ITSEC-E4-high approval for their SIM's, this
would go some way to acceptance in the banking community. However, I realise
that this would not be enough since the bank's want to see the whole
manufacturing and delivery process (as you say - the chain of trust). The
German banks have their own approval system for cash card's called ZKA. Perhaps
there needs to be an industry-wide standard like this. However, I think that
one of the main problems here is that of billing. The Telco want their cut and
the bank want theirs.
>We don't need to go into difficult areas at all, how can we view the mobile as
a
>secure PIN entering device, when it is not designed as such? ATM and POS PIN
>entring devices has encrypted keyboard controllers, my personal mobile bip a
>different tone for each PIN digit I enter!
This is a very valid point. I once posted something in alt.privacy about the
problem of normal PC keyboard sounds, but this is much worse. With a bit of
practise, you could even learn to recognise the tones yourself and not need a
recorder of sorts. Of course the tones can probably be switched off, but the
default is on and how many users switch it off ?
>We have already seen some results of the two world problem, I know one mobile
>phone which have internally two chip slots, one for the SIM and the other for
a
>bank ICC. In many pilots, the mobile has a built in smartcard reader, where
you
>can insert your bank card. Given the small size of a modern wireless phone,
and
>the size of a bankcard, this seem to lead into some practical difficulties. I
>don't know yet any pilots where telecom and banks uses the same chip, I guess
>there is a reason for this.
There is also something that I would like to see changed - the mechanical
format of a SIM or smart card. I can can understand some of the original
motivation for the format of a hand-held smart card, i.e. wallet size etc. but
I can't understand the motivation for the SIM card following the smart card
route. If the SIM were to be a just a bit thicker, we could put much more
processing power/memory onto it. Then we could implement strong and fast
cryptography on the SIM and develop substantial apps on the SIM.
On a separate note - does anyone know of a discussion group specifically for
wireless or WAP security? I tried one at http://news.wapunderground.com but it
doesn't seem to be very dynamic. I also tried the WAP Forum list server but I
had problems with registration, I will try this one again.
Mark
------------------------------
From: haifeng <[EMAIL PROTECTED]>
Subject: verification
Date: Mon, 14 Aug 2000 13:51:22 +0300
Hello,
How can I do verification for x509v3 certificate??
Thanks.
Haifeng:)
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2000 11:00:47 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Many times on sci.crypt people have objected to the proof of
: perfect secrecy for the OTP based on the fact that the zero
: vector is one of the possible keys. The false logic goes
: something like: since the OTP is provably secure, and zero
: is a legal key, then encrypting with the zero key must be
: secure, and since it obviously isn't the proof must be
: wrong.
: The OTP theorem doesn't say that encrypting with a
: particular key will maintain secrecy. It says choosing a
: one-time key uniformly at random and exposing the resulting
: ciphertext does not increase the chance of the attacker
: determining the plaintext.
This case still seems totally different from the case of using BBS with
short cycles.
Using the all-0 key in an OTP doesn't help the attacker get the message,
since he has no way of knowing it has been used.
Using a short cycle in a BBS generator, by contrast provides the attacker
with information about the message he did not previously posess.
One problem appears to be whether an attacker can identify a short cycle.
If he sees "123412341234..." in the low bits is he safe to assume the
generator is in a cycle? It seems unlikely - since the next digits
/might/ be 8, 5, 9 and 4. It appears that if the observed pattern is
longer than the langth of the key, the possibility of mis-identifying
a cycle diminishes rapidly.
If Terry Ritter is correct - and detecting short cycles is possible - it
appears that any analogy between "weak keys" in an OTP and "weak seeds"
in a BBS generator absolutely breaks down.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Mon, 14 Aug 2000 13:49:09 +0200
Guy Macon wrote:
>
> Mok-Kong Shen wrote:
>
> >A truly random process, as is well-known, can produce a
> >finite sequence of all 0'sk, which certainly fails all tests.)
>
> Any test for randomness that says that such a sequence is nonrandom
> is wrong and should be discarded. A true test for randomness would
> only say that such a sequence is very likely to be nonrandom.
Oh, I meant it fails in the normal statistical sense, that
is, with respect to a certain chosen confidence level.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Mon, 14 Aug 2000 13:49:04 +0200
Simon Johnson wrote:
>
> Saying there isn't 'real' randomness is rubbish. Quantum physics
> says there is and i'm not gonna argue with that. At the end of
> the day, the security of the OTP is based on trust that the
> source is perfectly random. Wether it truely is or isn't is
> irrelevent; its the belief that the cipher-text was enciphered
> under the OTP construction that determines its security.
I agree with you on a large part of the above. Practical
security evaluation is more or less involved with
subjectivity, since we don't have an apparatus, like a
voltmeter, to measure that. On the other hand, trust and
belief constitute the sources of potential problems. If
these happen to be not well founded, including the
opponent's having exceptional luck, then we lose,
sometimes terribly. We play 'games' all our life,
don't we?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Mon, 14 Aug 2000 13:48:47 +0200
Guy Macon wrote:
>
> Mok-Kong Shen wrote:
>
> >I suppose that most physical measurements, after doing
> >sophisticated error analysis, give only values that are
> >intervals (in which the correct values should be) that are
> >considered acceptable at certain confidence levels. A more
> >accurate measument gives a smaller interval, but not the
> >'exact' value. That kind of accuracy may be o.k. or even be
> >big over-kill for some purposes. But I think that one can't
> >claim that one gets 'absolutely' perfect measurements,
> >at least in most cases of practical interest.
>
> Correct. The flaw in the arguments posted by those who are infected
> with the "no randomness" meme is in postulating that such perfection
> is required. If a measured RNG output is so close to being a perfect
> measurement of perfect randomness that it would take more resources
> than exist (assuming the entire universe is turned into the most
> powerful computer realizable with that many atoms) to prove otherwise
> then we can say that it is indistinguishable from perfection.
I like to add that we need only have a sufficient degree
of indistinguishability from perfection in all practical
applications (though certainly not for cases considered by
the theoreticians). What's sufficient and what's not
sufficient depends on individual applications and inevitably
also on subjective evaluations/opinions of the user.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Playfair-Analyze ?
Date: Mon, 14 Aug 2000 13:48:55 +0200
Ronny Burow wrote:
>
> use some for our RPGs. Now i need some help with Playfair. Where can i get
> a simple description how to analyze a playfair-chiffre ? Please help.
See H. F. Gaines, Cryptanalysis. Dover.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2000 11:14:43 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
[snip far too much]
: If I understand this correctly it amounts to a claim that a rational attacker
: will not test for short cycles because the effort expended, when discounted by
: the odds of success, does not get him any closer to cracking the system than
: an equivalent amount of effort invested in a QR search. [...]
*If* so, the argument does not appear very convincing. What if the
attacker has a dedicated, parallel, short-cycle testing machine - built
for some other purpose - but only a general purpose serial computer
for use in factoring?
It appears that such an asymmetry could skew his best strategy
significantly in favour of looking for short cycles rather than
factoring - in which case eliminating short cycles might
genuinely help.
This is what I believe Ritter calls an "additional" weakness.
: If so, it is similar to the reasons why one need not check for long stretches
: of zeros in an OTP key. [...]
I don't like this analogy. I think it has great potential to mislead :-/
: Are all opponents sane?
Perhaps not - but its probably not sane to concern yourself overly much
with any insane ones ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2000 11:28:41 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
[Re: The probability to find in random sequence 0/1 value bits is exactly 50%]
: The algorithm outputs 256 bit blocks. Each 256 bit block consists of
: precisely 128 zeros and 128 ones.
: As others have noted, this is not a really desirable property in something
: that's supposed to look like a random sequence...
Exact bit balance isn't necessarily bad - but exact bit balance over each
256-bit block is dreadful.
You leak at least a single bit every 256 bits - and an attacker can
distinguish the generator's output from a random stream - even given a
small volume of output - with a few lines of code.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2000 11:36:14 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
: Scott Fluhrer wrote:
:> I looked at the algorithm, and it's dreadful. It basicly works by having 32
:> bytes of internal states, and going through these steps: [snip]
:>
:> - A "reflection operation", which throws away half the state, and replaces
:> it with the complement of the other half.
: Iterating a sequence containing this step should produce a strange attractor
: cycle. [...]
A disaster. Discard half of the entropy present in your seed at
regular intervals, why don't you?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2000 11:32:46 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
:> > >- The probability to find in random sequence 0/1
:> > > value bits is exactly 50%
:> >
:> > Gosh really?
:>
:> Yes!Gosh.
: Whoops. That's a shame. This is a distinguisher!
Not in itself it isn't. The probability of finding a 0 (or a 1) in a
genuinely random sequence should also be eactly 50%.
However, apparently there are other problems in this area...
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BBS and the lack of proof
Date: Mon, 14 Aug 2000 14:11:16 +0200
Bryan Olson wrote:
>
> And I can reference messages that clearly respond to this
> issue. Of course I'm most familiar with mine, such as:
>
> http://www.deja.com/getdoc.xp?AN=655556392
>
> In no secrecy system does an individual key, without regard
> to its keyspace, bestow any protection. The proof does not
> say that an individual choice of parameters is strong.
> What we can say is that if we choose a random starting
> point, the chance of the attacker predicting the output is
> no greater than the chance he could factor the modulus
> (given the modulus and not the output).
>
> Saying it's not a proof is nonsense; it is a proof. Saying
> it's not a proof of security is right, but only because we
> cannot prove that in the vast majority of cases factoring is
> intractable.
But isn't it that the phrase 'we cannot prove ....' is at
the very root of insecurity for the user in all issues
about proofs connected with factoring (for the practical
purposes of the user)?
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
******************************
