Cryptography-Digest Digest #369, Volume #13      Wed, 20 Dec 00 11:13:02 EST

Contents:
  Re: Q: Result of an old thread? (Walter Hofmann)
  Re: Q: Result of an old thread? (Walter Hofmann)
  Re: In =?ISO-8859-1?Q?today=B4s?= paper I read how Cuban (Tony L. Svanstrom)
  Re: Encrypting messages in images?? ([EMAIL PROTECTED])
  Re: Visual Basic Source Code ([EMAIL PROTECTED])
  Re: SMS security over various networks? (Robert Harley)
  Re: Homebrew Block Cipher: Moonshine (Tim Tyler)
  Re: does CA need the proof of acceptance of key binding ? ([EMAIL PROTECTED])
  Re: does CA need the proof of acceptance of key binding ? ([EMAIL PROTECTED])
  Re: hash function for public key digital signature : one way? ([EMAIL PROTECTED])
  Re: does CA need the proof of acceptance of key binding ? (Anne & Lynn Wheeler)
  Re: SMS security over various networks? (Mark Currie)
  Re: SMS security over various networks? (Mark Currie)
  looking for cipher algorithms' comparison ("maciek")
  cipher algorithms once again... ("maciek")

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Walter Hofmann)
Subject: Re: Q: Result of an old thread?
Date: Wed, 20 Dec 2000 12:16:02 +0100

On Mon, 18 Dec 2000 22:45:44 +0100, Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>Let me quote a previous follow-up of yours to be sure that 
>I understand you:
>
>   So you can change the coefficiants of AS by a sufficiently 
>   small epsilon>0 to get an invertible matrix, then you can 
>   calculate (AS')^-1. Go on to calculate B'=(AS')^-1.ASB 
>   then S(epsilon)=SB.B'^-1. In the limit epsilon->0 the 
>   matrix S(epsilon) will converge to S as all operations 
>   involved are continuous.
>
>You defined B'=(AS')^-1.ASB. But ASB is singular, so B'
>can't be inverted. Or do you want to apply the epsilon to
>ASB also?

Now I see what you mean: You cannot invert B' here because I put
another factor of S in it.

It's probably the best to compute things the other way round, otherwise
one would need two epsilons:

Change ASB to ASB' which is within an epsilon of ASB.

Then you can calculate

B'^-1 = ASB'^-1 . AS
S = SB . B'^-1

and do the limit process as described above.

Is this OK with you now?

Walter

------------------------------

From: [EMAIL PROTECTED] (Walter Hofmann)
Subject: Re: Q: Result of an old thread?
Date: Wed, 20 Dec 2000 12:18:21 +0100

On Tue, 19 Dec 2000 01:31:16 +0100, Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
>"Walter Hofmann"
>> You don't need p,q to do any of the computations above.
>>
>
>Alice needs p,q to compute A^-1, because (det A)^-1 mod N is needed.

This can easily be done without p and q. Use Euklid's algorithm.

Walter

------------------------------

Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: In =?ISO-8859-1?Q?today=B4s?= paper I read how Cuban
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 20 Dec 2000 12:29:22 GMT

Kirby Urner <[EMAIL PROTECTED]> wrote:

> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> 
> >"Markku J. Saarelainen" wrote:
> >> 
> 
> This guy, writing under the above pseudonym, floods newsgroups
> with crap.  Check the deja.com archives for alt.politics.cia.org
> to see what it's like to drown in a sea of garbage.  I've got 
> my filters on of course, but he keeps posting from places.

I thought about killfiling him a long time ago, but he's way too much
fun for that. I think I might print and frame this last posting of his.
*L*


     /Tony
-- 
     /\___/\ Who would you like to read your messages today? /\___/\
     \_@ @_/  Protect your privacy:  <http://www.pgpi.com/>  \_@ @_/
 --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
   on the verge of frenzy - i think my mask of sanity is about to slip
 ---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
    \O/   \O/  ©99-00 <http://www.svanstrom.com/?ref=news>  \O/   \O/

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,alt.2600.hacker,alt.security
Subject: Re: Encrypting messages in images??
Date: Wed, 20 Dec 2000 13:08:23 GMT

I actually had to do this.  Some things were sent to me via USPS to
a foreign post, and they got held up in Customs.  Customs wanted me
to list everything that was there in the local language (not English),
and so I had to translate the list.  But they gave me the 4th copy,
which had *no* visible writing on it.

Anyhow, I scanned the copy, then used Adobe PhotoXpress (or something...
don't remember the name) to increase the contrast to the point that
I could read it.

Anyhow, that clearly didn't work, so the next time they just never
announced that the shipment had come, and THAT worked.  They got my
stuff the next time.  (Moral:  don't ship things via USPS overseas.
USPS ships it *to* customs, not *through* customs.)



Sent via Deja.com
http://www.deja.com/

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Visual Basic Source Code
Date: Wed, 20 Dec 2000 13:26:02 GMT

Hi Chad,

I've made an implementation of DES in VB. I can send you the source
code, if you mail me your e-mail address.

Regards,

Michael
e-mail: [EMAIL PROTECTED]


In article <91b0mp$3gl$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> Does anyone know where i can get GOOD source code for MD4, MD5, SHA1,
> DES, IDEA, and CAST in VB??
>
> Thanks,
> Chad
>
> Sent via Deja.com
> http://www.deja.com/
>


Sent via Deja.com
http://www.deja.com/

------------------------------

From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: SMS security over various networks?
Date: 20 Dec 2000 15:01:57 +0100


[EMAIL PROTECTED] (Gregory G Rose) writes:
> In the GSM system, all frames (whether voice or
> signalling data or SMS) are encrypted equally
> using one of the A5s as negotiated.

I have read a claim to the contrary, namely that SMS messages are
transmitted unencrypted over a control channel.

Bye,
  Rob.
    .-.                                                               .-.
   /   \           .-.                                 .-.           /   \
  /     \         /   \       .-.     _     .-.       /   \         /     \
 /       \       /     \     /   \   / \   /   \     /     \       /       \
/         \     /       \   /     `-'   `-'     \   /       \     /         \
           \   /         `-'                     `-'         \   /
            `-'                                               `-'

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Homebrew Block Cipher: Moonshine
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Dec 2000 14:15:30 GMT

Simon Best <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:

:> : Why do you feel that a Feistel is bad?
:> 
:> Here's my (simplistic) perspective of what's wrong with Feistel networks:
:> 
:> Feistel networks keep half the round effectively unchanged.  This
:> means that half the round's output is a trivial linear function of
:> that round's inputs.

: But, of course, comparing ciphers by comparing what one round of each
: does isn't meaningful, as what a round is depends on what each cipher
: defines a round to be.

That doesn't appear to affect my point in any way.

:> Feistel networks are used with balanced s-boxes.  Balanced s-boxes
:> alone are sufficient to produce permutations.  The Feistel network is
:> another method of generating permutations.  As such it is unnecessary -
:> all you need are a collection of balanced s-boxes.
:> 
:> Keeping half the round unchanged is wasteful in terms of getting maximum
:> confision in hardware implementations.

: That depends on the requirements, and on what alternatives there are
: that also meet the requirements.

I'm considering that one relevant requirement is good, fast confusion and
diffusion in hardware.

The alternatives are many and various - but include would permutation
networks with no Feistel structure.

:> One half of the round is being fed through s-boxes - this takes time.
:> The other half of the round is just sitting around doing nothing while
:> this happens.  Instead it could usefully be subject to confusion.
:> [This objection is only true if there's some sort of diffusion applied
:> between rounds, which means that the outputs from the previous round
:> are all needed before processing of the next section can start].
:> 
:> If hardware speed is a significant factor, ISTM that use of a Feistel
:> network is not going to give you the greatest bangs for your buck.

: If hardware speed is a significant factor, a significant question is
: whether each application of the whole cipher needs to be performed
: quickly, or whether it's only the overall throughput that needs to be
: fast.

This is indeed an important consideration.

: If it's the latter, pipelining may be appropiate, and it becomes a
: question of circuit size more than speed (you can have lots of very
: short, quick segments). [...]

I believe overall throughput is not relevant when cyphers are used
for encrypting in common chaining modes e.g. (CBC/CFB), since the output
of each previous block is required for computing the next one.

However, if encryption speed is not a factor - and *decryption* speed
is all that matters [and this isn't that uncommon], then you can indeed
parallelise to good effect.

[I'm not convinced this completely removes the disadvantage I refer to,
 but it does indeed go a long way towards ameliorating it.]

I should mention an advantage of Feistel networks as well - they
can allow encryption and decryption to occur using essentially the
same machinery.

: If it's the former, it's a matter of comparing the whole cipher with
: alternatives (it's the quickest cipher you want, which may well not be
: the cipher with the quickest round).

The speed of individual rounds was *not* what I was addressing.

Overall speed was what I was talking about.  The basic idea is that
if your data is spending half its time sitting around idle, that's not
the best way of using the available time.
-- 
__________                  http://alife.co.uk/  http://mandala.co.uk/
 |im |yler  [EMAIL PROTECTED]  http://hex.org.uk/   http://atoms.org.uk/

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: does CA need the proof of acceptance of key binding ?
Date: Wed, 20 Dec 2000 14:39:38 GMT

In article <[EMAIL PROTECTED]>,
  Thierry Moreau <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > when someone applies a digital certificate from a certificate
authority
> > (CA), does the CA need the proof of acceptance for the key binding
from
> > the applicant?

> Yes, it does "need" such a proof ... but there is no practical way of
> providing it securely, so CAs do operate without a strong proof that
the
> certificate holder indeed agrees ... and they nonetheless claim to
provide
> state-of-the-art security (!)

  how's the law interpret this incomplete system?

vincent
[EMAIL PROTECTED]


Sent via Deja.com
http://www.deja.com/

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: does CA need the proof of acceptance of key binding ?
Date: Wed, 20 Dec 2000 14:50:23 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Timothy M. Metzinger) wrote:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> writes:
>
> >My poor knowledge does not allow me to answer your question
> >in concrete terms. But I believe that it is indispensable
> >for the CA to be able to well bind the a key to the physical
> >person once and with that to later verify communications from
> >him and for that there is apparently no other secure means
> >than the convential ones of proving identity. Of course one
> >CA could rely on another CA, but at least one CA must do the
> >work. One problem that is in my view not resolved (resolvable)
> >is that the CA must be trusted and that is a subjective matter.
>
> Typically in PKIs designed for high assurance, the binding between
the key
> pair(s) and the individual is accomplished by a Registration
Authority (RA).
> The RA performs a face-to-face validation of identity, and then the
individual
> generates the key pair(s) in the presence of the RA, and gives the
public
> portion to the RA.  The RA sends the public key with a request for a
digital
> certificate to the CA in a signed message.  The CA trusts the RA and
thus
> generates the certificate and signs it.
>
> There are variations on this, but in all cases there is a face-to-face
> verification of identity.

  I think besides verification and binding which could be done by the
CA or RA even without the acceptance of the applicants for the keys, we
need a proof of acceptance for that assigned key pair, so that are non-
repudiation of the assigned key.

> The CA is the root of trust for all the certificates it issues -
there's no way
> around the fact that the CA must be trusted.  Relying parties have to
look at
> the policies and procedures for the operation of the CA and decide
how much
> trust to place in it.

Vincent
[EMAIL PROTECTED]
Universiti Teknology Malaysia


Sent via Deja.com
http://www.deja.com/

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: hash function for public key digital signature : one way?
Date: Wed, 20 Dec 2000 14:52:23 GMT

In article <91lotk$88g$[EMAIL PROTECTED]>,
  "Simon Johnson" <[EMAIL PROTECTED]> wrote:
> After a bit of reading, i found who was correct. There has been a
slight
> misunderstaning on my part.
>
> Collision resistance is defined by the difficulty of generating TWO
> plain-texts that hash to the same value.

> A Hash is One-Way if the difficulty of finding the preimage from a
single
> hash.

 according to #, Preimage resistance is defined as for any pre-
specified output y, it is computationally infeasible to find the input
x such that h(x) = y.

 according to %, for one way hash function, it is easy to generate the
message digest, but hard to generate the preimage from the message
digest.

 therefore, I think both your definition of the one-wayness and my
assumption that preimage-resistant equals to one-way have to be
confirmed.

> With RSA, this more complicated. If i generate a hash, it is collision
> resistant in the sense that if i do not know 'd', it is near
impossible to
> get two different pre-images to create a collision, however with 'd'
this is
> trivial.

 I think RSA is not a hash function, because according %, hash function
should produce fixed length message digest. Length of RSA output is a
variable of the size n.

> The one-way property argument still stands.

  In current establish cryptographic hash algorithms like MD5, SHA-
1..., does their one-way property impose extra computational load
compared to their design that is only collision free?

  In my project, I use SHA-1 to hash a message to be signed, then send
the signed message digest and plaintext as digital signature. I think
the one-way property is not neccessary for the hash function in my
project. I use the following arguements to explain why I still choose a
one-way hash function like SHA-1:

 1. SHA-1 is a recognized secure cryptographic hash function.

 2. To be compatible with future work that wants to encrypt the
plaintext and to prevent the generation of the plaintext from the
message digest using the reversible hash.

 3. I couldn't get a standard hash function that is collision free but
reversible.(as Benjamin Goldberg said)

 Any other reasons that can support the necessarity of one-way property
in an application that don't need one-way property?

#http://paris.cs.berkeley.edu/~perrig/projects/validation/node3.html,
%page 30 of "Applied cryptography"(1996, Bruce Schneier)

vincent
[EMAIL PROTECTED]


Sent via Deja.com
http://www.deja.com/

------------------------------

Subject: Re: does CA need the proof of acceptance of key binding ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2000 15:04:41 GMT


[EMAIL PROTECTED] writes:
>   how's the law interpret this incomplete system?

current debit/atm magstripe card typically has a 4-digit shared-secret
PIN .... frequently mailed to the person separately by their bank when
the get a new card. in some of the digital signature laws with respect
to the retail & financial arena ... it has involved, in case of
dispute, attempting to change the burden of proof from the
merchant/bank to the consumer ... focusing on how secure the
mathematics are ... and somewhat ignoring problems in all the other
business processes (as far as i know, such provisions have yet to be
passed).

that is ignoring the previously mentioned issue, in the retail
transaction case, that real identity proofing represents a serious
invasion of privacy (i.e. any requirement to use a real consumer
identity certificate in consumer retail transaction)

-- 
Anne & Lynn Wheeler   | [EMAIL PROTECTED], finger for pgp key
 http://www.garlic.com/~lynn/

------------------------------

Subject: Re: SMS security over various networks?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 20 Dec 2000 15:10:44 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>
>[EMAIL PROTECTED] (Gregory G Rose) writes:
>> In the GSM system, all frames (whether voice or
>> signalling data or SMS) are encrypted equally
>> using one of the A5s as negotiated.
>
>I have read a claim to the contrary, namely that SMS messages are
>transmitted unencrypted over a control channel.
>

There is a GSM spec maintained by ETSI called GSM 03.48. This spec details how 
to encrypt and MAC signalling data such as SMS. It can use Triple DES as the 
encryption algorithm.

Mark


------------------------------

Subject: Re: SMS security over various networks?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 20 Dec 2000 15:15:07 GMT

In article <3a40cbf4$0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>>
>>
>>[EMAIL PROTECTED] (Gregory G Rose) writes:
>>> In the GSM system, all frames (whether voice or
>>> signalling data or SMS) are encrypted equally
>>> using one of the A5s as negotiated.
>>
>>I have read a claim to the contrary, namely that SMS messages are
>>transmitted unencrypted over a control channel.
>>
>
>There is a GSM spec maintained by ETSI called GSM 03.48. This spec details how 
>to encrypt and MAC signalling data such as SMS. It can use Triple DES as the 
>encryption algorithm.

However, this is only supported on GSM phase #2+ compliant handsets.


------------------------------

From: "maciek" <[EMAIL PROTECTED]>
Subject: looking for cipher algorithms' comparison
Date: Wed, 20 Dec 2000 16:47:23 +0100

I would appreciate if someone could point me a source where I could find
comparison of currently used algorithms (regarding their efficiency and
safety).

Thank you very much in advance

Maciek



------------------------------

From: "maciek" <[EMAIL PROTECTED]>
Subject: cipher algorithms once again...
Date: Wed, 20 Dec 2000 17:06:44 +0100

Actually, could you tell me the names of currently used ciphers? I need to
do some research and I even don't have anything to start with. I know that
there are DES, 3DES, Rijndael (AES). Are there any others?

Thank you very much for any answers.

Maciek



------------------------------


** 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 by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to