Cryptography-Digest Digest #810, Volume #8 Tue, 29 Dec 98 19:13:03 EST
Contents:
Re: DS5002FP Secure Micro Crypted Buses (Thomas Womack)
Re: On leaving the 56-bit key length limitation (wtshaw)
Re: Many Time Pad (MTP) Cryptosystem (wtshaw)
Re: On living with the 56-bit key length restriction (wtshaw)
Re: Security through obscurity in the smartcard world (Ian Goldberg)
Re: On leaving the 56-bit key length limitation (Terry Ritter)
Re: Opinions on S/MIME (Brad Aisa)
Re: On leaving the 56-bit key length limitation (wtshaw)
Re: On leaving the 56-bit key length limitation (wtshaw)
Re: [Q. newbie] Authentication/Digital Signatures (Thomas Harte)
Re: RSA-Broken!!! (Michael J. Fromberger)
----------------------------------------------------------------------------
From: Thomas Womack <[EMAIL PROTECTED]>
Crossposted-To:
alt.security,alt.technology.smartcards,comp.arch.embedded,comp.arch,comp.security.misc
Subject: Re: DS5002FP Secure Micro Crypted Buses
Date: 29 Dec 1998 21:16:22 GMT
In comp.arch Andy Glew <[EMAIL PROTECTED]> wrote:
: Markus Kuhn wrote:
: > The small block size of the data bus cipher was the critical feature
: > used in this attack.
: Q: does this imply that large cipher block sizes are advantageous
: for secure processors?
I think it's generally accepted that it's not wise to use a block cipher
in an application where an adversary can get hold of 2^(N/2) blocks where
blocks are N bits long ... hence, it would seem ideal to try never to
transfer less than 128 bits at a time.
The Dallas chip attack, IIRC, involved watching the IO ports and
submitting blocks that might or might not contain an encrypted IO
instruction; I'm not utterly sure of this, but I think making IO
instructions occupy a very small portion of the address space (ie
having only 1024 of the 2^32 instructions being IO, using the 10 data
bits to mean 'output register xxxxx to address space location stored
in register yyyyy', would have rendered that attack significantly
harder.
Tom
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 14:19:17 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
>
> > As a result of my studies of somewhat deficient ciphers I sometimes
> > implement with others, the obvious is that frequent key changes, working
> > within a unicity distance, can make them quite practical.
>
> A valuable remark. I missed such stuffs in the textbooks.
>
Not everything valuable is in a textbook, and what I said needs
qualification. If you yield ciphertext shorter than the length needed to
solve it, many algorithms can exhibit great strength. Naturally, some
algorithms are solvable in very few characters, not appropriate for such a
use. Somewhat deficient means have some useful qualities; just what is
the practical length that cannot be solved definitively for various
algorithms might be hard to identify. Needless to say, a block cipher
that can be solved from one block, given ample brute force effort, need
not apply.
--
New Year's Resolution: Strive to be accurate, even if it means telling a lie or
misrepresenting the whole truth; after all, this is how Congress does it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Many Time Pad (MTP) Cryptosystem
Date: Tue, 29 Dec 1998 14:50:47 -0600
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
> "Bo D�mstedt" wrote:
> >
> > But it is sufficient that the MTP-system resists cryptanalysis
> > when used only a limited number of times, a maximum of
> > three encryptions, for example. It is easy to avoid using
> > a MTP system multiple times, using administrative methods.
> >
>
> So that would be a few time pad (FTP)?
>
>
> > If you think this problem over again, I am sure that you will
> > figure out how to construct an MTP system that works.
>
> But why bother if it has no advantages over other methods?
>
The problem is with the protocol, which could be automated. I can surely
do such a system on the fly with functions I have online, but it is, as
you said, not worth it, except to show how it can be done. If you need to
go through this phase, more power to you to figure it out, but, go from
here to higher things before you rest.
--
New Year's Resolution: Strive to be accurate, even if it means telling a lie or
misrepresenting the whole truth; after all, this is how Congress does it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 29 Dec 1998 14:57:49 -0600
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
>
> The main aim of the regs, as far as I can see it, is to hold a
> gun to the head of major software houses. The internet makes it
> completely impractical for people like Microsoft to put encryption
> in their e-mail programs without commiting a serious crime. Until
> crypto is added to programs like Netscape as standard then there
> will be no mass encryption of e-mail. Mass encryption *inside the
> USA* is what the feds are really avoiding.
>
Let's not be so broad: it would be the dream of some to cork the crypto
bottle, however it could be done. And, those people are so used to using
lies to get their way that you cannot expect the whole truth out of them.
Surely Microsoft and Netscape are the big targets, but size is not
important if there is a break it the dam, and the crypto dam is just about
as solid as Swiss cheese, as well as Swiss crypto. Remember we are
dealing with people who had rather use force than reason, so subtile
truths are apt to be overlooked.
--
New Year's Resolution: Strive to be accurate, even if it means telling a lie or
misrepresenting the whole truth; after all, this is how Congress does it.
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: Security through obscurity in the smartcard world
Date: 29 Dec 1998 22:20:07 GMT
In article <76b57t$[EMAIL PROTECTED]>, Gary Howland <[EMAIL PROTECTED]> wrote:
>Admittedly, in the case of the GSM hack, early peer review of the
>system might have resulted in SIM cards that cannot be cloned at
>the present time, since they (the GSM designers) might have used
>a better algorithm due to the peer review. But who's to say that
>the pre-launch publication of the algorithms would have spotted
>it,
Well, it took Dave and me about 2 hours (over an Indian buffet lunch at
Rajah's in Berkeley) to break it; it stands to reason that others could
have done the same...
>and that the earlier publication of the algorithms wouldn't
>have allowed more sophisticated attacks by this time? But, while
>the GSM hack is to be applauded, it does not actually harm the GSM
>security model, and will no way be a repeat of the old analogue
>phone asttacks, since the security relies on much more than just
>the SIMs (there is a unique id in the phones themselves for starters).
?? I can copy a SIM, stick the copy into a brand-new phone, and voila!
Cloned GSM phone. (It really works!) It it certainly much _harder_ to
do than the trivial cloning of analogue phones, admittedly.
>But I don't want to get into the GSM debate.
Oops; sorry.
- Ian
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 21:38:20 GMT
On 29 Dec 1998 08:50:01 GMT, in <76a53p$sia$[EMAIL PROTECTED]>,
in sci.crypt David A Molnar <[EMAIL PROTECTED]> wrote:
>[...]
>Could you recommend a good treatment of the unicity distance?
One of the better sources is:
Meyer, C. and S. Matyas. 1982. Cryptography: A New
Dimension in Data Security.
at the back of the book.
>[...]
>Would such a system be on the lines of probabilistic systems, except that
>all possible decryptions "look valid" ?
Unicity distance is no panacea. We generally cannot compute that
value, but can only imply it in the context of the attacks we know and
understand.
We might say that a cipher with a given amount of internal state could
not be solved unless we have at least that amount of plaintext in
cipher. But, in practice, we set the cipher state from a far-smaller
key, and we might solve *that* with far less plaintext. In ciphers
with large internal keying states, there may be some advantage in
re-keying that state at random times, in no case longer than one might
think would be needed to analyze the cipher.
Or we might try to encipher only random messages: If each plaintext
really is an arbitrary selection among all possible plaintexts, there
are no statistics left to use. Obvious approaches include data
compression and multiple encryption. But since we normally measure
ciphers by known-plaintext attacks nowadays, data compression may not
be much help.
Yet another approach would be to include random keying or "nulls" in
the plaintext. At some point simply selecting the correct data bytes
becomes yet another ciphering level, making this yet another form of
multiple encryption. But I believe we will find that the governments
will want to make it difficult for most people to do multi-ciphering,
and they will not approve the export of multi-ciphering systems, even
if the ciphers do have 56-bit keys. They will say such systems have
an effectively larger key, and thus are controlled.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Re: Opinions on S/MIME
Date: Tue, 29 Dec 1998 17:42:46 -0500
This is a cryptographically signed message in MIME format.
==============ms5A3F6AF2D6C0228DB5F83825
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Roger Schlafly wrote:
>
> Sam Simpson wrote in message <[EMAIL PROTECTED]>...
> > --------------------------------------
> > Year Recommended Key Length
> > --------------------------------------
> > 1995 1280
> > 2000 1280
> > 2005 1536
> > 2010 1536
> > 2015 2048
> > --------------------------------------
>
> I don't know that reference, but these recommendations seem quite
> paranoid to me. No one has publicly broken a 512-bit RSA key yet.
> Breaking a 512-bit DSA key is significantly more difficult.
>
> By my estimates, breaking a 1280-bit key is about a billion times
> more work. This is way out range for anyone today.
Excuse my possible ignorance, but I am assuming that the association of
key lengths with dates is not supposed to mean that someone can
effectively break the messages on those dates, only that they may very
well be able to break the messages some fairly small number of years
*after* the date, if they were encrypted using the indicated key
lengths.
--
Brad Aisa
[EMAIL PROTECTED]
S/MIME signed using freemail ID from www.thawte.com
"Laissez faire."
==============ms5A3F6AF2D6C0228DB5F83825
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIWQYJKoZIhvcNAQcCoIIISjCCCEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BgYwggLFMIICLqADAgECAgJc1zANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk4MTIyNTIyNDk0M1oXDTk5MTIyNTIyNDk0M1owQDEfMB0GA1UEAxMWVGhh
d3RlIEZyZWVtYWlsIE1lbWJlcjEdMBsGCSqGSIb3DQEJARYOYmFpc2FAaXN0YXIuY2EwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALALier07xXR24pdrjirnceHsJyUOXwz/FUSMvJq
2rlWW8axn95Q/TQxP6g23b8vnWWmwJaF5Z9tDoXkHvwcdn/QEADlTSLZA59S9/huPjT5Busm
9yJNbSScatnmlSN+9yG+OSoTUzxjm+X1il0LkxQHVmJrLjh0etMfO5xs8MRLAgMBAAGjVDBS
MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAfBgNV
HSMEGDAWgBT+PmCca4wPsNgzxsrGHliwcTi14DANBgkqhkiG9w0BAQQFAAOBgQAcN95/wDDZ
vp2s5SA4GEw7zPwJKKEJbmJj3SH0dzXgHUbpinujkcrJ9bnJCBQ+EHDxW1gIRkpJT5rV9Azp
S5zXWUY0WPbjl564TjoyIFjefGKu6+GWQZ6jQ7DL9DNyeocSFjYCCyqFypAEcZiRL0x6HzfF
gSIIj5+9dEu+Xz0yWjCCAzkwggKioAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05ODA5MTYxNzU1
MzRaFw0wMDA5MTUxNzU1MzRaMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQDEy1U
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAMSl5dTU0F8IAu4HIX0kv6trjh7rIAcCFYRrj9CTJB8bne5o
srksT+mTZxcQFx6h+UNBI7kwqnaXu/Pn/YHAtTGL9qZQJlTylSjrGaQelx6w4ribwQSaMtA8
CWxP5DVP8Ha/ABMDT0UIYPP8tNCQAYoSyZy6f1LqKpM1Njw85DUvAgMBAAGjNzA1MBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZI
hvcNAQEEBQADgYEALMeCHwFDPgeP7mlcqWSC+MCWrZMry5tQ10CagcK6pnadPJVA3FXB4VWC
easKKabVDOFXKD6P+bvV3w2TWKpbLYuPM+TdWBU1dnIVKb1C9FqSC3dfnSfbmi1OG4IGjtKN
VruV3tsMZQXelZ4C3VMXvr78a8MaInoUK2G9wp9eeloxggIbMIICFwIBATCBwDCBuTELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUx
GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElL
IDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJT
QSBJc3N1ZXIgMTk5OC45LjE2AgJc1zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTIyOTIyNDI0NlowIwYJKoZIhvcNAQkEMRYE
FK/djsq/d3R4kl/GNosC5JvHbKDbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAni5hvuojXSpNU/jjar0vmSY3eBo8wA8dKQ+4+2uLGu9jpxVMlfAb
Mzbxn9/RN8oabjPPDATXx/BdFqMr7DLXmPWWexUcMoSxyq00fWD+hkJVLagNp2Mi6MXn+y2s
TY3+llgMN7i67lYKbcUZfUTLk92d9Zi23AowCap39808yig=
==============ms5A3F6AF2D6C0228DB5F83825==
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 14:43:59 -0600
In article <76a53p$sia$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> Right now I think of unicity distance as a measure of the number of
> encryptions which may be performed by a particular key and method before
> there are more ciphertexts than possible encryptions. In other words, a
> concept related to hash collisions; after so many encryptions, there must
> emerge some structure that differentiates the output from a one-time-pad.
>
> Although now, looking at the _Handbook_, I think I have it backwards;
> should be thinking about the choices for key instead. or both.
Honestly, I think Shannon considered that algorithms would use a
predictable amount of key material in each encryption, so a few
encryptions would assure all of it was used. Some algorithms almost
guarantee that all of the key will never be used, and variable amounts of
it are used at one pass.
>
>
> Would such a system be on the lines of probabilistic systems, except that
> all possible decryptions "look valid" ? The Rabin public-key scheme comes
> to mind, with the four possible decryptions per unit.
This might describe some systems, but, not meaning to hype one of my
algorithms, merely use it as a good example, the GVA answers this problem
by presenting a huge supply of outputs that would be hard to analyze, even
quanties which might be on a par with the 56 bit number for one plaintext;
as in one implication where 2^54 possible outputs are available for any
given block.
The GVA could be used at 56 bits or below, but that depends entirely on
key generation, and not the algorithm itself. The 56 bit limit seems to
require that algorithms not be scalable, something which might be hard to
do.
> Except I don't think
> it passes the "computationally unbounded" adversary test, since it's
> equivalent to factoring.
>
> [much snipping]
> [create multiple perfectly "valid" but not true decryptions]
> > -- which the user's system can choose based on some trusted
> > information provided out-of-band.
In the GVA, apologies again, there is nothing needed outside of the usual
key and ciphertext for decryption. I suppose it is an exception, where
other algorithms might need such an external crutch and the above tends to
suggest.
> ^^^^^^^^^^^^
>
> What kinds of systems would use such information without turning it into a
> secret key ? or is the point to reduce key exchange to a single larger,
> out of band transfer instead of doing all these in band, policeable
> exchanges ? does it make sense to ask how large such information would
> need to be, or do we need designs first?
It is possible to make a keysearch within limits so laborious that it is
not practical, then the 56 limit is an insufficient method to cripple
algorithms. But, I will not suggest something technical that would do the
job instead, for I don't think it wise in the first place. It should more
be in the realm of who retains the right to use encryption with loss of
that ability through due process for cause.
>
> Please feel free to give pointers to designs or lit - this sounds
> intriguing, but I think I'm missing the point. :\
>
> Thanks,
> -David Molnar
--
New Year's Resolution: Strive to be accurate, even if it means telling a lie or
misrepresenting the whole truth; after all, this is how Congress does it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 14:23:57 -0600
In article <76b0us$s6s$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> However, as I commented in the original posting, that concept must
> also be revisited and expanded in order to extract the full benefit
> from such approach to security -- besides what what it already gives us,
> with enough elbow room for theoretically unbreakable privacy even under
> 56-bit key length limitations.
>
One can walk on all fours, but it is hardly convenient.
--
New Year's Resolution: Strive to be accurate, even if it means telling a lie or
misrepresenting the whole truth; after all, this is how Congress does it.
------------------------------
From: Thomas Harte <[EMAIL PROTECTED]>
Subject: Re: [Q. newbie] Authentication/Digital Signatures
Date: 29 Dec 1998 21:40:16 GMT
In <[EMAIL PROTECTED]> Harpy-34 wrote:
> Mr. Tines wrote:
> This can be used for encryption. Alice wants to encrypt a file [etc.]
So, what's the answer to my question, please? :)
Is there a means of publicly verifying a signature such that the
signature protocol cannot be turned into an encryption algorithm?
Harpy-whatsit seems to be saying that there is _always_ a way to
encrypt if authentication is performed.
Even though I am a complete neophyte in cryptological terms,
I shouldn't have thought that I am the first person to have posed
this question. Perhaps it is thought to be of no consequence?
But I cannot see how it should be, given that authentication is
of such import, and that encryption is akin to arms dealing as
far as the US legislature is concerned.
Does anyone care whether or not an algorithm can potentially
be used for encryption? Rivest's chaffing and winnowing shows
that popular authentication mechanisms can be subverted to the
cause of encryption without actually altering/reversing/interfering
with the authentication algorithm itself: the mere fact that authentication
is performed is enough to form the basis of encryption.
But Rivest's approach is sufficiently indirect to render the
authentication algorithm innocent of any charge of encryption,
potential or otherwise.
Is there even an existence theorem as to possibility of having
signature-only algorithms (one-way signatures)?
Thanks, Thomas.
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: RSA-Broken!!!
Date: 29 Dec 1998 01:24:02 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Bruce
Schneier) writes:
>On 28 Dec 1998 20:28:49 GMT, [EMAIL PROTECTED] (STL137) wrote:
>
>>Uh HUH. And you've also done the following, I take it:
>>Solved the Riemann conjecture, and did it in an elementary proof.
>>Solved Goldbach's conjectures, again with elementary proofs.
>>Found a way to unify the four fundamental forces of nature.
>>And so on.
>Well if you're so smart.... How many licks DOES it take to get to
>the center of a Tootsie Pop?
See W. O. Owl's seminal paper on this subject, "Three Licks: Getting
to the Centre of the Tootsie Pop Controversy" in Journal of
Idisyncratic Cryptanalysis, v.II #5, Feb. 1992, pp. 324-335.
;)
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
CXbBKubsWdmJFUvC0k5CxWhLErvotT1Z5xVFRr+O934A42xeaSYrSXr4qJ0RngTN8oyre89f
Remove clothing if you would like to reply to this message via e-mail
------------------------------
** 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
******************************
