Cryptography-Digest Digest #304, Volume #12 Fri, 28 Jul 00 11:13:00 EDT
Contents:
Encrypted Message Exchange - a variant of the interlock protocol (John Savard)
Re: Seeking simple, free crypto app (Pegwit?) ([EMAIL PROTECTED])
Re: Seeking simple, free crypto app (Pegwit?) ([EMAIL PROTECTED])
Re: What is DES3mCBCMACi64pPKCS5? (Daniel James)
Re: JavaCard vs Multos security (Daniel James)
security from m composite. ("Sergio Arrojo")
Software to implement elliptic curves? ("Sergio Arrojo")
Re: Crypto Export Controls (Kent Briggs)
Re: JavaCard vs Multos security ([EMAIL PROTECTED])
Re: What is DES3mCBCMACi64pPKCS5? (Mark Wooding)
Re: Another PURPLE Question (Charles Petersen)
Re: Encrypted Message Exchange - a variant of the interlock protocol (John Myre)
Re: PGP US Versions Broken,no good?? (Mark Wooding)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Encrypted Message Exchange - a variant of the interlock protocol
Date: Fri, 28 Jul 2000 12:16:10 GMT
The following idea, while 'obvious' enough that I may just have missed
seeing it somewhere before, seems like a way to frustrate
man-in-the-middle attacks. Perhaps it is just a trivial variant of the
interlock protocol, and has heretofore been thought unworthy of
mention.
Step 1:
Parties A and B exchange Diffie-Hellman public keys X^a and X^b.
Step 2:
A sends B a message, first encrypted with a key derived from X^ab,
then encrypted with a secret key.
At this point, we can stop, and have A give B his secret key later
over an authenticated channel. Perhaps the secret key is much shorter
than a Diffie-Hellman key, so it can be exchanged over the telephone
while a D-H public key cannot. Hence the name, reminiscent of EKE, but
here one isn't enciphering any Diffie-Hellman parameters, merely a
conventionally-encrypted message.
But the benefits aren't the same as EKE: although the secret key is
shorter than a public key, and only it needs to be authenticated, it
still, unlike the key in EKE, has to be fully long enought to provide
the desired level of security: no privacy amplification is provided.
However, if one wants to continue to obtain something like the
interlock protocol (and with the same limitations: the messages
involved can't be important, just something that verifies identity),
we can continue:
Step 3:
B sends A an acknowledgement of the message, first encrypted with a
key derived from the checksum of A's encrypted message, then encrypted
with a key derived from X^ab, then encrypted with a secret key.
Step 4:
A sends B, encrypted under a key derived from X^ab, his secret key.
Step 5:
After reading A's message, B sends A, encrypted under a key derived
from X^ab, his secret key.
Step 6:
A reads B's message, and is convinced both that it came from B by its
content, and that B had the opportunity to read A's authentic message
by the checksum-derived key.
Essentially, we have the interlock protocol, but instead of splitting
a message into halves, we are splitting it into message and key.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
Crossposted-To: alt.security.pgp
From: [EMAIL PROTECTED]
Subject: Re: Seeking simple, free crypto app (Pegwit?)
Date: Fri, 28 Jul 2000 12:24:23 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Ed Suominen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I am looking for a simple, free crypto app. that I can send to
> clients. Initially, I am *very* impressed by Pegwit for windows
> (http://disastry.dhs.org/pegwit). It seems simple and effective, and
> I really like the fact that I could send it to clients as a single
> executable file (only 124KB)!
i also was *very* impressed by Pegwit, the command line encryption tool
made by George Barwood http://ds.dial.pipex.com/george.barwood/
but it was command line so i made a windows interface for it
> Specifically, I'm wondering how "computationally infeasable" it is
> for an attacker to obtain your private key (just your passphrase
> with Pegwit) from the 256-bit Pegwit public key.
i really can not comment this, i am not a crypto expert
all encryption routines are left unchanged from original Pegwit
you can read something here:
http://ds.dial.pipex.com/george.barwood/v8/
> (Isn't that kind of short?).
no, because it uses Elliptic Curves and so can get the same strength
with much shorter keys than RSA and DH
it should be as strong 3072bit RSA or 128 bit symmetric cypher
P.S. if anyone using pegwit older than 0.99, please get latest version 0.99
in previous versions key manager can handle only up to 10 keys because of stupid bug
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOYFfOzBaTVEuJQxkEQLrFACfYe0EkA2T0BT5+/kxoSYXDWVYki4AoOn4
ZBbjPZR0fWvzGe1IHZY1QP7K
=ARqY
=====END PGP SIGNATURE=====
------------------------------
Crossposted-To: alt.security.pgp
From: [EMAIL PROTECTED]
Subject: Re: Seeking simple, free crypto app (Pegwit?)
Date: Fri, 28 Jul 2000 12:30:05 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
jungle wrote:
> PeekBoo is about 45 kB ...
> 1/3 of pegwit ...
>
> Ed Suominen wrote:
> > I am looking for a simple, free crypto app
>
> with your requirements, nothing can overtake PeekBoo ...
sorry, I was not impressed by PeekBoo at all ...
(i cant comment it right now, it was some time ago when i tried it...
need to reinstall and look again)
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOYFgoTBaTVEuJQxkEQIzhQCgq3UOAQpB56ut/7JZdRPvBYIbDt8An3sr
fsldlRopk3gkPztdBWMLRQmF
=Se69
=====END PGP SIGNATURE=====
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: Fri, 28 Jul 2000 13:42:24 +0100
Reply-To: [EMAIL PROTECTED]
In article <8lqr2t$jah$[EMAIL PROTECTED]>, Paul Rubin wrote:
> So the following sounds reasonable, based on FIPS 81 and 113:
>
> - Take plaintext message and pad with PKCS5
> - Encrypt the padded plaintext in CBC mode with a random IV.
> Ciphertext is the IV followed by the CBC output.
> - Take the ciphertext and encrypt it *again*, in CBC mode with IV=0.
> The last block of the output is the MAC. Discard the rest of the output.
Reasonable, but may or may not be right. In particular the IV may or may not be
encrypted (somehow). A known plaintext IV adds *nothing* to the security so you
might as well use 0.
> Someone else said the mode is signature-only, i.e. there's no cipher
> output. I hope that's incorrect. I'd like to be able to get an encrypted
> and authenticated ciphertext from a plaintext in a single module operation.
I'm not familiar with anything that uses the name "Mech_DES3mCBCMACi64pPKCS5",
but it *looks* like the name of a MAC mechanism - if you want encryption as well
there may be another mechanism to do that, but it would be a separate operation.
There may also be a different mechanism that does both in one pass.
Just out of interest, what is the module you're using?
Cheers,
Daniel.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: JavaCard vs Multos security
Date: Fri, 28 Jul 2000 13:42:24 +0100
Reply-To: [EMAIL PROTECTED]
In article <8lpoik$p1o$[EMAIL PROTECTED]>, wrote:
> Can anyone comment on the security aspects of Javacard vs Multos.
The initiative behind MULTOS came from bankers with a vested in a secure
solution, the initiative behind JavaCard came from computer companies wanting
to sell products.
> Javacard uses standard Java security
> Multos is a special OS heavily based on ENcryption technology..
Javacard does specify security beyond that used for 'normal' Java. The actual
security implemented varies from vendor to vendor - nobody seems to have
caught up yet with what standards there are.
MULTOS defines a strong security model, and enforces it. MULTOS implements a
strong sandbox on the card so applications and cardlets are rigorously
policed at runtime and the security of the card can be guaranteed. In
contrast JavaCard security relies in part on an off-card validation process
to ensure that a program will not perform 'illegal' operations when it is run
on a card. This is done in the name of efficiency so that fewer runtime
checks need to be made, but opens up a number of possible attacks.
All MULTOS implementations are *required* to be certified to ITSEC level E6
(but be careful to read the certification documentation for any card you
consider using to see exactly what was certified, and remember that the
requirement applies to the MULTOS implementation and says nothing about the
security of the card hardware itself).
> The details of the security model are unkown ....
There is some information available online - see www.multos.com and
references therefrom.
Cheers,
Daniel.
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: security from m composite.
Date: Fri, 28 Jul 2000 16:24:03 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
Is it true that m an attack against elliptic curves over GF(2^m) with m
composite was recently discovered. Is GF(2^p) (p prime) to be implemented
in every curve in order to avoid weaknesses?
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Software to implement elliptic curves?
Date: Fri, 28 Jul 2000 16:28:26 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
Does anybody know where from could I download implementation of elliptic
curves over GF (2^p) (p prime) in C++. I just want a NO-COMPLICATED software
to be able to implement different curves without having to deal too much
with the contents of the program (I am not that much of a genius with C++).
Thanks
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Crypto Export Controls
Date: Fri, 28 Jul 2000 14:44:18 GMT
[EMAIL PROTECTED] wrote:
> Where can I find more resources that talk about the current state of
> crypto export controls?
Here's the official BXA site:
http://www.bxa.doc.gov/Encryption/Default.htm
The bottom line is that just about any strength encryption software product
is now exportable from the U.S. after a one-time review. Certain free
products or lower-strength products don't even require that.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: JavaCard vs Multos security
Date: Fri, 28 Jul 2000 14:44:43 GMT
I am somehwat surprised that Multos has so much to offer with only an 8
bit cpu...the new javacard cpu's are 32 bit risc, and that has
considerable more power to run all the Java bytecode...
What I would like to know, is any comparative benchmarks on these two
standards...that would at least shed some light on oranges for oranges
etc....
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8lpoik$p1o$[EMAIL PROTECTED]>, wrote:
> > Can anyone comment on the security aspects of Javacard vs Multos.
>
> The initiative behind MULTOS came from bankers with a vested in a
secure
> solution, the initiative behind JavaCard came from computer companies
wanting
> to sell products.
>
> > Javacard uses standard Java security
> > Multos is a special OS heavily based on ENcryption technology..
>
> Javacard does specify security beyond that used for 'normal' Java. The
actual
> security implemented varies from vendor to vendor - nobody seems to
have
> caught up yet with what standards there are.
>
> MULTOS defines a strong security model, and enforces it. MULTOS
implements a
> strong sandbox on the card so applications and cardlets are rigorously
> policed at runtime and the security of the card can be guaranteed. In
> contrast JavaCard security relies in part on an off-card validation
process
> to ensure that a program will not perform 'illegal' operations when it
is run
> on a card. This is done in the name of efficiency so that fewer
runtime
> checks need to be made, but opens up a number of possible attacks.
>
> All MULTOS implementations are *required* to be certified to ITSEC
level E6
> (but be careful to read the certification documentation for any card
you
> consider using to see exactly what was certified, and remember that
the
> requirement applies to the MULTOS implementation and says nothing
about the
> security of the card hardware itself).
>
> > The details of the security model are unkown ....
>
> There is some information available online - see www.multos.com and
> references therefrom.
>
> Cheers,
> Daniel.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 28 Jul 2000 14:51:17 GMT
Daniel James <[EMAIL PROTECTED]> wrote:
> In article <8lqr2t$jah$[EMAIL PROTECTED]>, Paul Rubin wrote:
> > So the following sounds reasonable, based on FIPS 81 and 113:
> >
> > - Take plaintext message and pad with PKCS5
> > - Encrypt the padded plaintext in CBC mode with a random IV.
> > Ciphertext is the IV followed by the CBC output.
> > - Take the ciphertext and encrypt it *again*, in CBC mode with IV=0.
> > The last block of the output is the MAC. Discard the rest of
> > the output.
Indeed. The first couple of steps can be done as one module operation:
send an Encrypt command specifying your key, omitting the IV, and giving
the mechanism DES3mCBCi64pPKCS5. The module will pad the plaintext,
invent a random IV, do the encryption and send you back the ciphertext
and the IV it invented. You can then glue the IV and ciphertext
together if you like. The final operation must be done as a separate
step, sending a Sign command with your key, an all-zero IV and the
mechanism DES3mCBCMACi64pPKCS5.
If you want to avoid gluing the IV on the front of the ciphertext for
the MAC stage, you could just submit the ciphertext to the Sign command
and specify the IV you were returned by the Encrypt command. This will
make playing with the command and reply structures slightly simpler, but
won't affect the result.
I'm not terribly keen on the idea of MACing the ciphertext: it violates
the `Horton principle' that you should validate the *meaning* of what's
being said as closely as possible. Personally, I'd prefer to use HMAC
with RIPEMD-160 as a MAC, and then encrypt the plaintext and MAC
together. If I'm stuck with DES3 CBC-MAC then I'd do the MAC first and
encryption afterwards, with *different* keys, but sharing the same IV.
> Reasonable, but may or may not be right. In particular the IV may or
> may not be encrypted (somehow). A known plaintext IV adds *nothing* to
> the security so you might as well use 0.
Err... If you're talking about the IV used to do the initial
encryption, rather than the MAC computation, then it's probably a bad
idea to fix the IV unless you're only going to be using the key for a
single message, or the redundancy of the first plaintext block is low.
Otherwise, an eavesdropper can identify common prefixes in plaintexts,
which may be undesirable. There's no particular point in keeping the IV
for a CBC encryption secret, unless the first plaintext block is *much*
more sensitive than the rest.
I agree that the IV for the MAC doesn't need to be chosen at random,
which is, I suspect, why Paul decided to fix it at zero.
> > Someone else said the mode is signature-only, i.e. there's no cipher
> > output. I hope that's incorrect. I'd like to be able to get an
> > encrypted and authenticated ciphertext from a plaintext in a single
> > module operation.
I'm afraid that you can't do this. I'm not sure that it would be of
particularly great benefit anyway, since you have to do the same number
of DES encryptions anyway. You'd reduce the amount of data transferred
between the host and the module by a third, though. Is that really a
major issue?
> Just out of interest, what is the module you're using?
It's an nCipher module with key management (either an nForce or an
nShield).
-- [mdw]
------------------------------
From: Charles Petersen <[EMAIL PROTECTED]>
Subject: Re: Another PURPLE Question
Date: Fri, 28 Jul 2000 07:55:05 -0700
I'm not quite sure I understand. So did the PURPLE work by using a table
of inverses? I don't really see this in the machine and thought perhaps it
was just one way that it could be done today. How did it actually work in
the first place?
Sorry if I'm being dense, but I really need to get a good answer to this...
>
>
> No, the PURPLE did just "send it back the other way", because it isn't
> made like the Enigma. (Constructing the permutations so as to be
> somehow symmetrical wouldn't help, unless you still had a
> 'deciphering' switch to reverse the carry order of the switch
> steppings.) Of course, that means you need to have tables of inverses
> of all the 75 permutations of 20 characters in the machine plus the 25
> permutations of 6 characters.
>
> The PURPLE did have a plugboard a bit like that of the Enigma.
>
> John Savard (teneerf <-)
> Now Available! The Secret of the Web's Most Overused Style of Frames!
> http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypted Message Exchange - a variant of the interlock protocol
Date: Fri, 28 Jul 2000 08:57:30 -0600
Let's see if the MITM can cause problems...
> Parties A and B exchange Diffie-Hellman public keys X^a and X^b.
The MITM interposes himself, as usual:
A -> M: X^a
M -> B: X^c
B -> M: X^b
M -> A: X^d
So now A and M communicate using X^ad, and M and B communicate
using X^bc.
> A sends B a message, first encrypted with a key derived from X^ab,
> then encrypted with a secret key.
Let Ka be A's secret key, and define Km and Kb similarly. Let E[k](p)
be the encryption of p using key k. Then:
A -> M: E[Ka]( E[x^ad]( msgA ))
where msgA is the plaintext that A generated.
> B sends A an acknowledgement of the message, first encrypted with a
> key derived from the checksum of A's encrypted message, then encrypted
> with a key derived from X^ab, then encrypted with a secret key.
Let chkA be the checksum of the message above, and define ackA as the
acknowledgement. Now M responds as if he is B:
M -> A: E[Km]( E[X^ad]( E[chkA]( ackA )))
> A sends B, encrypted under a key derived from X^ab, his secret key.
Actually:
A -> M: E[X^ad]( Ka )
So now M knows Ka and msgA. Now M continues with B:
M -> B: E[Km]( E[x^bc]( msgA ))
B -> M: E[Kb]( E[X^bc]( E[chkM]( ackM )))
M -> B: E[X^bc]( Km )
Note that the checksum and acknowledgement are different, but
the original msgA has been exchanged. At this point, M knows
Ka and Km, and B knows Km and Kb.
> After reading A's message, B sends A, encrypted under a key derived
> from X^ab, his secret key.
M continues to play both sides:
M -> A: E[X^ad]( Km )
B -> M: E[X^bc)( Kb )
And now A and M share X^ad, Ka, and Km; while M and B share
X^bc, Km and Kb. All three know msgA.
> A reads B's message, and is convinced both that it came from B by its
> content, and that B had the opportunity to read A's authentic message
> by the checksum-derived key.
A seems gullible, to me. He's only talking to M. And B is only
slightly less so: maybe msgA is actually something unique to A.
(Or rather, was.)
JM
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: 28 Jul 2000 15:06:38 GMT
Edward A. Falk <[EMAIL PROTECTED]> wrote:
[GnuPG]
> Thanx for the pointer. Using it would mean losing compatibility
> with PGP 2.6 though.
Not completely. There are contributed plug-ins which implement RSA and
IDEA. Encrypting messages using RSA and IDEA is a pain, but decrypting,
signing and verifying all work OK. The RSA plug-in unfortunately
doesn't support old-format PGP signatures, so some sigs in old keyrings
might not work. I've hacked my version of the RSA plug-in to support
verifying (but not creating) the old-format signatures properly.
-- [mdw]
------------------------------
** 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
******************************
