Cryptography-Digest Digest #562, Volume #12 Tue, 29 Aug 00 04:13:01 EDT
Contents:
Re: secrets and lies in stores (S. T. L.)
Re: New algorithm for the cipher contest (David Hopwood)
Re: encryption scheme output - samples table? (David Hopwood)
Re: Asymmetric Encryption Algorithms (David Hopwood)
Re: "Warn when encrypting to keys with an ADK" (David Hopwood)
Re: UNIX Passwords (David Hopwood)
Re: Future computing power (Anders Thulin)
Re: could someone post public key that is tempered ? (jungle)
Re: Steganography vs. Security through Obscurity (Benjamin Goldberg)
Re: On pseudo-random permutation (Bryan Olson)
Re: On pseudo-random permutation (Markku-Juhani Saarinen)
Re: Looking for Book Recommendations ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 29 Aug 2000 05:15:15 GMT
Subject: Re: secrets and lies in stores
<<Because it doesn't deny the above. It points this out. Then notes
that having a perfect lock is not enough. There is a lot more to security,
and the way people think about it, and act in a society which has
certain kinds of locks, than the lock itself. So much else that often
focusing on the lock alone leads us to miss much larger points.
That's what I meant by "hardly relevant.>>
Hmmm. I still don't like the idea of calling any field of mathematics or
science hardly relevant, no matter how it fits into society. You could call
supersymmetry in particle physics completely irrelevant because it'll never
affect society. But that doesn't say anything about how important it is to
investigate this area. Same with cryptography.
Of course, now I'll have to read this danged book to see what it's all about.
Heh. Too little time, too many books. If there's such a thing as too many
books, that is. :-P
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
Date: Tue, 29 Aug 2000 06:38:48 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: New algorithm for the cipher contest
=====BEGIN PGP SIGNED MESSAGE=====
Scott Fluhrer wrote:
> I believe I have a way that, given K[3] (which is the fourth multiplicative
> key), distinguishes it from randomness with a relatively few amount of
> chosen plaintexts and effort, and the actual chosen plaintexts do not depend
> on K[3]. This immediately leads to a method of rederiving K[3] with about
> O(2**64) effort and circa 100-1000 chosen plaintexts.
Drat, beat me to it :-) I was working on exactly the same attack; I'd done
the second case for the distinguisher, and was close to working out the first
one.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOasmtTkCAxeYt5gVAQG4Mgf9Hgnap4TeE8+IhK4yTGYnENF5sRbp52ox
Ynrod5UkcDm/3YDcflsFnwo92uHtNrYumCTqUpuPwx9R5Igr4ZcB5of2aoLHcBRB
vtA8iNz2mXMdsFo7PkBdZDQLd/1RYk+Su3NdIZBm19g60OUvhThPGJf1ASoXpCy/
MxL/ggwaG2oRpFEqwa4mEfEihQmMAHWUsu7MGXX21+kwHADHfjVJ4gOijYTMUDI8
dqXzpdbMamIFmHM0cD0zZALukn9Zx+96B5U54iRflzQzeKiPc5xNSSQMr+xa570O
Qd/uuhloDCLdgD9ZXtE9Jw4/PV5oioWl6LrknzrAJYye1rz99fRBXw==
=Y3LY
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 29 Aug 2000 06:38:55 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: encryption scheme output - samples table?
=====BEGIN PGP SIGNED MESSAGE=====
kihdip wrote:
>
> Most encryption schemes result in a bitstream.
To be more precise, most modern encryption schemes treat plaintext and
ciphertext as streams of octets (8-bit bytes), or occasionally as streams
of larger words (e.g. 32 bits). The order of bits within an octet or word
is usually not defined.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOasxBjkCAxeYt5gVAQGRQwgAk0DXNEeFse75HCp5GyVRCXhmAlCMi57p
Qw75mKHyP2LeK0FccuN+okTRyn0JzKSFVYY63wKK7UUHhySdzdjqkjo6WjCwn6XQ
lGlBap2WB4TXVB7Pwm9XDWPC2UVOtqmO+1n90vNSEiBqIeRClf1Ovq7x58cQ0Rb1
cTQ0U8AdId1QeTvZrSzw0TgJEdGsTSeym1RtpcMmet/qhVKBg+XMqanQRTPAmdAx
7sEcAz4Oj6mnAQP3UVctJQQHO+MpPDLNk23ZJk3iSUHo6DxOPRx19lPXDU4/UMUb
SpB3Gt2t2ZrxYZgoIsOEBEP5z1lsBUOHLY+xec8JM0w2e9s2mPUtKw==
=/MkC
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 29 Aug 2000 06:39:03 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Asymmetric Encryption Algorithms
=====BEGIN PGP SIGNED MESSAGE=====
DJohn37050 wrote:
>
> NIST in DSA-2 draft said that to protect an AES 256-bit key it was
> appropriate to use a 15,360 bit p and 512-bit q in DSA-2.
In that case NIST are using an oversimplified model for making parameter
length choices. In the case of AES there is no speed penalty for using a
longer key [*], and so choosing a 256-bit key doesn't necessarily mean that
a 2^256 security level was required. It might simply be a convenient default
when using SHA-2/256 to derive keys, or whoever chose the key size might
have done so on the basis of attacks other than brute force (e.g. they might
believe that the key scheduling algorithm is more conservative for that
length, for instance).
For DSA, OTOH, the time for both signing and verification is roughly
O((lg p)^2 * lg q), so there is a definite trade-off between this time and
the security level.
Actually, it doesn't make a lot of sense to base parameter choices for
DSA on matching the security of block ciphers with 256-bit keys. Presumably,
if you want security against generic attacks on block ciphers with that key
size, it is because you think quantum cryptanalysis using something like
Grover's algorithm might become practical - but a practical quantum computer
could break DSA in polynomial time.
[*] Unless Rijndael is chosen, and that's only the difference between
10 and 14 rounds.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOas9HjkCAxeYt5gVAQEiCQgAs46yJzz8gCfCkDqamc8yxcNzALCvDiv6
WLlEsk1LHr69FXgj1CF9jQdoGAWpSvziQ2JLavoJcvj7jIWwCqth5/Pqpil/OD9a
MmVDQPSSYqehyp6LQjHcel8HOR03RmyJ5dLPaFr1LPooRH1wTTouZ0zq4EFkAMYf
JnxmtPVtFG054eYmGHc5WTxsa9ykH3Tm1wEYyaczmRaNsc04Udj/06ufxXMemCsR
IjCndiJPfH/gB3Efz/+Y9QfI0VdyfFPSXabDooH1rczzFTyRa9GFM6us2h3H/Edk
TxWGkoGV9LspOUIbFE24ZS5mNlZEI/n/p79Yd9KBqrrNWoec7vCzag==
=XJiF
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 29 Aug 2000 06:39:10 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
=====BEGIN PGP SIGNED MESSAGE=====
"S.R. Heller" wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> On Fri, 25 Aug 2000 13:58:56 GMT, Ron B. <[EMAIL PROTECTED]> wrote:
> =
> >I followed through on your suggestion and verified that you are
> >correct. The warn label seems to apply to the enforced AAR only.
> >However, from the pgpwinusersguide.pdf documentation:
> >
> >=95 Warn when encrypting to an ADK. Use this checkbox to specify
> >whether to issue a warning whenever an encrypt-to key has an
> >associated Additional Decryption Key.
> >
> >Is this an error in the documentation or a deliberately misleading
> >statement?
> =
> I'm sure this is only an ambiguous statement, trying to encapsulate a
> complex process. If you are encrypting to a public key with
> Additional Recipient Request (ADK) and you are using a plugin which
> doesn't normally present the recipients dialog, selecting the "Warn"
> option will force the recipients dialog to appear, thereby giving you
> the chance to see that an ADK has been added to the recipients list.
It would be better if that were *always* the case; having a warning
option to set seems to have misled people into thinking that there
would be an additional explicit warning message-box (which is certainly
what I would have expected).
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOatFUzkCAxeYt5gVAQE5YAgAlADkIZ2KruEu/FPsokUl4ma0ExM2UM2R
w7h6fKJOEwDkO6j7YsSeZZOsd1+tz5KmbbZQGaq7ZlsrRlx+POm85et84w2FJCRW
zFvD442T6ZIFcif8mLIo93NXfNj5hl2+7nBOx6y1zdTJq2NG3l3V8DMl1BGK0WdP
KS7iXwvy6HTjGIFeo6JBFcTXY9YVh+GV/B4NE7FckWx3W98tSd0J3JazQA+hZDgQ
4b2cgmzUM/feOUKlKTRTROXH21c06eW17HpoagVbCY0bywCOEdQNDBoKejaszJyX
M9LWyyUENCP//m/kBxq+u/Ume0Zs61VUZPE6spY8STjSnqdJN5LYZQ=3D=3D
=3DZ8U8
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 29 Aug 2000 06:55:38 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: UNIX Passwords
=====BEGIN PGP SIGNED MESSAGE=====
Paul Montgomery wrote:
> > Is there a description available, how UNIX encrypts (or hashes) its
> > Passwords?
> =
> I can't speak for all Unix "brands" but OpenBSD uses Blowfish
> (default) or MD5 hashing (on my vesion at least which is 2.4).
There are at least four password hashes in common use in various versions=
of Unix: "traditional crypt(3)", "extended crypt(3)", "MD5-crypt", and
"bcrypt".
For the specification of bcrypt, which is the OpenBSD scheme based on
Blowfish, see
Niels Provos, David Mazi=E8res,
"A Future-Adaptable Password Scheme,"
Presented at USENIX '99.
http://www.usenix.org/events/usenix99/provos.html
This paper also has some brief analysis of traditional crypt(3) and
MD5-crypt. "extended crypt(3)" is seriously broken; it is less secure
than the traditional version.
Despite much searching, I have been unable to find any unambiguous
specification of the traditional crypt(3) algorithm. It's fairly
difficult to reverse-engineer from the source code, because typically
optimised versions of DES are used (e.g. Eric Young's libdes), where
the mapping to FIPS 46 is distinctly non-obvious. If anyone does have
a reference for exactly how the salt is used to modify the output of
the expansion permutation (or can explain it here), I'd appreciate
seeing that. Note that it is *not* described in any of the Unix manual
pages, or in Morris and Thomson's "Password Security: A Case History"
paper.
> It also might be useful to check out SHA-1, it is a powerful hashing
> algorithm that can be used for storing passwords.
bcrypt is more suitable as a password hashing algorithm than SHA-1; see t=
he
Provos/Mazi=E8res paper for why.
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOatQGTkCAxeYt5gVAQFDgQf9FRdrA6cALDWntTMYsh1nufjXOYeaWcLc
WM3lxl+RwC1m+v3T6H+0Mqj6HchGTnY28IHpnMTYPkHtJoTzzL7DBSMmwVjil3kY
RiqWOk/BTmriT3mkGTGXzQVPux0aQSLXs6pdW/wHUMlJSul9C4SHDMwx9BwdUZet
qIkjHHUQhna0gJ1AF3LH4Cf7HnVyrhdpEQTvwH22jU7v0L1Ym9AIIvkD2zzauvGS
wFVe7PX+aWolp6Am0OTm7mLd0sMFAbSex73q9xXAPYl+x4vXwJKgqIgSQcc8lQ+s
1wYEb4ZAvCICqf6nuPdwrJFyBrxZJvsX8JT/5CqQt5AwBSPh0BjjOQ=3D=3D
=3DlWpY
=====END PGP SIGNATURE=====
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 06:45:14 GMT
[EMAIL PROTECTED] wrote:
> Your comment displays your lack of knowledge of how modern MPUs work.
> Cycles per opcode, pipeline depth, cache hit rates, and branch
> prediction success are only a very small part of the information needed
> to model a contemporary deeply pipelined, out-of-order, superscalar
> processor.
That first measure 'cycle per opcodes' seems to be one that decides
whether or not the one you mention are relevant. If you have only one
or a few cycle per opcodes, there won't be much reason to have a deeply
pipleined architecture.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Box 85, S-201 20 Malmö, Sweden
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: could someone post public key that is tempered ?
Date: Tue, 29 Aug 2000 03:08:31 -0400
the rule from the time of introduction ADK was simple ...
don't use it, when key has ADK, don't use key ...
this is the rule that everyone should follow ...
Nick Andriash wrote:
> [EMAIL PROTECTED] (jungle) wrote in <[EMAIL PROTECTED]>:
>
> >thanks doug ... but it is wrong ...
> >
> >PGP has no problem to indicate to me that Bill Clinton key has ADK in
> >it ...
> >
> >the question is open : could someone post public key that is tempered
> >& pgp will not detect it ?
>
> What version of PGP are you using?
the version that is affected according to the report list [ v5.x, v6.x ] ...
for the tests I used v651 ...
> If you are using 6.5.8,
v658 is the fix to the buggy versions ...
I did not use v658 for tests ...
> PGP will not
> detect the ADK... thus not detect a hacked Public Key.
wrong, PGP is detecting ADK on hacked [ forged ] key ...
> But, perhaps I do
> not fully understand what you are after, and if that is the case, I
> apologise.
no need to ...
the question is open : could someone post public key that is tempered
& pgp will not detect added ADK to it ?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: Tue, 29 Aug 2000 07:45:27 GMT
zapzing wrote:
>
> In article <8o3g28$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Guy Macon) wrote:
> > [EMAIL PROTECTED] wrote:
> > >
> > >
> > >In article <[EMAIL PROTECTED]>,
> > > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > >
> > >> In fact there are steganographic systems that meet that
> > >> requirement -- even if the enemy is looking for your
> > >> message and knows how you're hiding it, he cannot prove
> > >> that it is present.
> > >
> > >Great! Can you list a reference?
> >
> > Not needed - the solution is trivial.
> >
> > Get a good hardware RNG and send me a maeesage every day consisting
> > of random data from the RNG.
> >
> > Every so often, use the OTP encrypt a message with a pad from the
> > same RNG and send that.
> >
> > No attacker can tell whether you sent a message or not.
>
> Don't you think it will look somewhat suspicious,
> all this random data being sent around ?
Possibly. On the other hand, if you encrypt *all* of your messages, and
send a few messages every single day, you get a similar effect...
Especially if there's no known distinguishing attack. The low
importance messages which use normal encryption like exaclty random (one
hopes), and the high importance messages, which use the OTP followed by
normal encryption, also look random. You could even have a program on
your machine which monitors message traffic, and if you haven't sent
many messages, will make up a few random ones to hide that fact.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Tue, 29 Aug 2000 07:48:43 GMT
David A. Wagner wrote:
> Bryan Olson wrote:
> > Given a generator
> > of perfect random bits as the one and only source of
> > randomness, can you find any procedure for generating
> > perfectly uniform random permutations (of more than two
> > elements) that strictly terminates?
> Sure, no problem. It suffices to pick an integer in
> the range 1 .. n!. The latter can be done by treating
> the random bits as the binary expansion of a random real
> number R in the interval [0,1). A simple strategy is to
> say that we output the integer i (where 1 <= i <= n!)
> if (i-1)/n! <= R < i/n!. Note that we don't need all the
> binary digits of R to determine which bucket R falls into;
> it suffices to know a finite prefix of the binary
> expansion of R, since (i-1)/n! and i/n! must differ at
> some bit position of finite index.
But that only means the smallest and largest real values
that map to the same i must differ at a finite index. The
issue is the largest value that maps to i and smallest that
maps to i+1.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Markku-Juhani Saarinen <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Tue, 29 Aug 2000 07:57:03 +0000 (UTC)
In sci.crypt David A. Wagner <[EMAIL PROTECTED]> wrote:
(on finding random permutations)
: Sure, no problem. It suffices to pick an integer in the range 1 .. n!.
: The latter can be done by treating the random bits as the binary expansion
: of a random real number R in the interval [0,1). A simple strategy is to
: say that we output the integer i (where 1 <= i <= n!)
: if (i-1)/n! <= R < i/n!.
: Note that we don't need all the binary digits of R to determine which bucket
: R falls into; it suffices to know a finite prefix of the binary expansion of
: R, since (i-1)/n! and i/n! must differ at some bit position of finite index.
Hi,
The "bucket" can be easily determined from floor(n! R) + 1, but the
given procedure that uses only binary digits of R may never terminate.
Having b bits tells us that R satisfies
(a - 1) / 2^b <= R < a / 2^b
for some integer a, 0 < a <= 2^b.
Now pick, say, R = 1/3 and n = 3. We basically wish to decide which
integer i satisfies
(i - 1) / 6 <= R < i / 6
This can't be decided from the binary sequence since a / 2^b never
exactly divides 1/3, as can be seen using Fermat's little theorem.
Bits What is known R <= 1/3 ?
1 0.000000000 <= R < 0.500000000 Unknown
2 0.250000000 <= R < 0.500000000 Unknown
3 0.250000000 <= R < 0.375000000 Unknown
4 0.312500000 <= R < 0.375000000 Unknown
5 0.312500000 <= R < 0.343750000 Unknown
(..)
This procedure would work better if R is represented in mixed-radix
format.
- mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyväskylä, Finland
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Looking for Book Recommendations
Date: Tue, 29 Aug 2000 07:50:16 GMT
In article <7Hsq5.2440$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Charles Blair) wrote:
> Knuth's CONCRETE MATHEMATICS has a chapter on number theory, but
> it may not cover all the material you need.
>
> I think Herstein is considered one of the more advanced books.
> ABSTRACT ALGEBRA is intended to be easier than TOPICS. An alternative
> (possibly out of print but check libraries) is Birkhoff and Maclane,
> SURVEY OF MODERN ALGEBRA.
>
Thanks for the SURVEY OF MODERN ALGEBRA suggestion. It looks
interesting and according to Amazon, it has been reprinted. Compared
to ABSTRACT ALGEBRA, which book is more advanced?
Anthony Mulcahy
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
