3-rotor enigma on ebay: $5200
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2162414185
i saw this on the boing-boing blog.
- don davis, boston
-
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Columbia crypto box
Bill Frantz writes: >>> * Fast key setup (Forget tossing the 256 bytes of key >>>stream. The designers weren't crypto engineers. >>>Personally, I'd toss the first 1024.) Steven M. Bellovin wrote: >> There may be a cryptographically sound reason to >> discard that much, but it's not without cost. Bill Frantz wrote: > The reason I would discard so much is that when I did some > statistics on RC4 output, I kept getting distribution lumps > out to about 1024. They made me worry about what someone > who knew what were doing could do. See: Ilya Mironov (Stanford), (Not So) Random Shuffles of RC4 Advances in Cryptology - CRYPTO 2002 Proceedings, ed. by Moti Yung. Springer LNCS 2242, 2002. pp. 304-319. http://crypto.stanford.edu/~mironov/papers/rc4full.pdf Abstract. Most guidelines for implementation of the RC4 stream cipher recommend discarding the first 256 bytes of its output. This recommendation is based on the empirical fact that known attacks can either cryptanalyze RC4 starting at any point, or become harmless after these initial bytes are dumped. The motivation for this paper is to find a conservative estimate for the number of bytes that should be discarded in order to be safe. To this end we propose an idealized model of RC4 and analyze it apply- ing the theory of random shuffes. Based on our analysis of the model we recommend dumping at least 512 bytes. ... 7 Conclusion We identified a weakness in RC4 stemming from an imperfect shuffing algorithm used in the key scheduling phase and the pseudo-random number generator. The weakness is noticeable in the first byte but does not disappear until at least the third or the fourth pass (512 or 768 bytes away from the beginning of the output). ... Our most conservative recommendation ... means that discarding the initial 12 * 256 bytes most likely eliminates the possibility of a strong attack. Dumping several times more than 256 bytes from the output stream (twice or three times this number) appears to be just as reasonable a precaution. We recommend doing so in most applications. - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Did you *really* zeroize that key?
At 3:07 PM +1300 11/7/02, Peter Gutmann wrote: >> [Moderator's note: FYI: no "pragma" is needed. >> This is what C's "volatile" keyword is for. > > No it isn't. This was done to death on vuln-dev, > see the list archives for the discussion. > > [Moderator's note: I'd be curious to hear a summary -- > it appears to work fine on the compilers I've tested. > --Perry] i include below two parts: a summary of the vuln-dev thread, and a compiler jock's explanation of why peter's #pragma is the _only_ solution that reliably will work. - don davis, boston vuln-dev thread: http://online.securityfocus.com/archive/82/298061/2002-10-28/2002-11-03/1 (thanks to tim fredenburg sending this URL to me.) summary: programmers can obstruct dead-code elimination in various ways: - use the volatile attribute (but correctly); o introduce dynamic dependency; + do the memset with an external call. punchline: the subtler or newer the obstruction, the less likely we are to see that _all_ compilers treat the obstruction correctly. the safest route is to code with obstructions that have long been known to obstruct dead-code elimination. hence, wrapping memset() in an external routine is most likely to work with various buggy compilers. synopsis: * peter posted the same message as he posted to the cryptography list, appealing for new support from the compilers; * syzop said, "didn't happen w/ gcc 2.95.4"; * michael wojcik suggested: define an external call that does memset's job, so as to defeat dead-code elimination * dan kaminsky suggested: introduce dynamic [runtime] dependencies; * dom de vitto said, "use the volatile attribute"; * kaminsky replied: compilers are more likely to reliably respect dynamic dependency, than to correctly support the volatile attribute; * pavel kankovsky replied, "volatile" is mandatory in the standard, so it's ok to trust it; * peter also replied to kaminsky: the dead-code elimination problem seems specific to gcc 3.x . the underlying problem is unreliable support for standard features and for standards compliance. * michael wojcik explains (to peter, pavel, and kaminsky) why "volatile" isn't as good as his external call: - "passing a volatile object to memset invokes undefined behavior" - "access to volatile objects may be significantly slowed" - "volatile seems like the sort of thing broken implementations may get wrong" michael also argues that more compiler support isn't necessary, since the standard provides effective features. since i used to build compilers long ago, before i got into security work, i asked an expert friend (32 yrs of compiler development) about what he thought of this problem, and of the proposed solutions. this guy, btw, was the lead engineer for digital/compaq's fx32! runtime binary translator for the alpha workstations, & he knows a lot about optimizers. he says that of the four proposed solutions - * #pragma dont_remove_this_code_you_bastard; * use the volatile attribute (but correctly); * introduce dynamic dependency; * do the memset with an external call; - only peter's pragma can be expected to work reliably: * the c99 standard and its predecessors don't at all intend "volatile" to mean what we naively think it means. specifically, in the hands of a high-end compiler developer, the spec's statement: "any expression referring to [a volatile] object shall be evaluated strictly according to the rules of the abstract machine" is really talking about what the compiler can infer about the program's intended semantics. a c99-compliant compiler _can_ legitimately remove a volatile access, as long as the compiler can deduce that the removal won't affect the "program's result." here, "the program's result" is defined by the compiler's sense of what the "abstract machine" is: the abstract machine is mostly defined by the language features, but can also take into account whether a debugger or specialized hardware are running during compilation & or runtime execution. for example, such a savvy compiler might leave our volatile-memory memset() call in place when the debugger is running (knowing that the debug- ger might want to view the zeroed key). but then, when the debugger is turned off, the same compiler could decide
new attack on des
does anyone know of an on-line copy of this paper? - don davis, boston http://www.ece.wpi.edu/research/crypt/seminar/ A New Class of Side-Channel Attacks on DES, Prof. Christof Paar, Chair for Communication Security, Ruhr-University Bochum, Germany Thursday, August 8, 2002, 1:30 PM, Atwater Kent, WPI, Room 218 [Joint work with Jan Pelzl, Thomas Wollinger and Hans Dobbertin] Abstract- About 5 years ago, a new approach for attacking cryptographic hardware was proposed. This approach is referred to as side-channel attack. It exploits information such as power consumption, timing behavior, or electro magnetic radiation to extract a secret key from a piece of cryptographic hardware. These attacks have been proved to be especially powerfull for reading "hidden" keys from smart cards. This presentation introduces a new class of side-channel attacks against the popular block cipher DES. Power analysis is used to detect collisions within the DES algorithm thus combining a cryptanalytic approach with side channel evaluation. A step-by-step optimization of the attack is presented in order to increase the probability of a collision. It is shown that a collision within three adjacent S-boxes of DES can be found with as few as 135 encryptions (averaged over 10,000 simulated attacks with random keys) exposing detailed information about 18 key bits. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Constructing "capability" URLs
At 1:53 PM +0800 9/4/02, Ng Pheng Siong wrote: > I'm building a web app which... constructs URLs on the fly. ... > I'm creating the capability thusly: > cap = hmac-sha1(key, "/object?action=something&expiry=timeval") > My questions: ... > 2. The key is created from /dev/random. How long should it > be? In my threat model, the key changes every few hours. > > 3. Any other thoughts? use /dev/urandom (the psudorandomly-amplified version of /dev/random), and you can change the key more frequently, without emptying /dev/random's entropy buffer. unless i'm missing something, /dev/urandom is secure enough for your application. - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Montgomery Multiplication
> I was just wondering if anyone knew where to get
> a good explanation of Montgomery multiplication
> for the non-mathematician?
here's an explanation i wrote a couple of years ago:
- don davis, boston
what's going on with montgomery reduction:
do you remember in your first digital-hardware class, how they taught
you that you don't need AND, OR, and NOT gates, to build full-function
logic circuits, because you can do everything with just NAND gates?
montgomery's algorithm is kind of like that; it shows that you don't
need the multiply, divide, and remainder operations to do bignum modular
exponentiations, because you can use this montgomery-multiplication
operation over-and-over, instead. the advantage of montgomery-mult'n
is that it avoids the remaindering operation, and so avoids expensive
divisions, but nevertheless manages to keep an exponentiation's
intermediate products small, in a very cheap & easy way.
it works rather like logarithms, and the performance trade-offs are
similar: to multiply two numbers, you have to transform them to the
montgomery representation, montgomery-multiply the transformed numbers,
then transform the product's montgomery-representation back to the
normal representation. for two factors, this takes longer than a
normal multiply-and-take-remainder step would, even though montgomery-
multiplication is just as cheap as normal multiplication, because the
final transformation takes longer than doing a remainder in the usual
way. but, for exponentiation, where we would montgomery-multiply many
times, we only have to do the representation-change twice, at the
beginning and end. to do a modular exponentiation in the normal way,
we'd have to take the remainder after every multiplication. so, that's
how montgomery saves time: convert the operand to a representation in
which the remaindering operation disappears, multiply that representation
by itself as much as the exponent indicates, then change the repre-
sentation back. this is like the advantage of logarithms: if you're
multiplying many numbers together, then you convert all the operands
once to their logs, and you convert the final result back, but you
don't have to convert any of the intermediate results, so the cost
of converting to & from logarithm format is more than offset by
the cheapness of adding instead of multiplying.
now, how does montgomery representation make remaindering go away?
the basic idea is that when we're doing a long chain of modular
multiplications, we need to keep the intermediate products from
getting too big, but taking their remainders mod N isn't the only
way to keep them small. montgomery's conversion just multiplies
each operand by the maximum operand-size, say 2^1024, modulo the
crypto-system's modulus N. now, when we multiply two such trans-
formed operands, the product gets bigger than we want to keep around,
just as in normal modular arithmetic, but it's much easier to make
the montgomery representation's excess go away at each step. the
heart of montgomery's theorem is the trick of adding a certain
simple multiple of the modulus N to this intermediate product,
making a modulus-N equivalent that happens to be a multiple of
2^1024 . now, recall that this intermediate product is not a good
montgomery representation; it's too big by just this factor of 2^1024.
so, by throwing away the least-significant 1024 bits, we kill two birds
with one stone: we keep the intermediate product's size manageable,
and we keep the intermediate product in montgomery representation,
so it's ready for another round of montgomery-multiplication. it's
very slick, but none of the explanations i've read, treat this
intermediate-size issue at all.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Proving security protocols
> I have been trying to read about formally proving security > protocols. ... I was wondering if anyone here has seen a > comparison between these approaches to evaluate things like > ease of use and effectiveness. 5 years ago, i saw meadows give an interesting talk, comparing the various state-of-the-art verification tools, with caveats about each one's blind spots, and with some attention to how easy/hard it is to make mistakes while using such tools. i suspect that the talk i saw was from this paper: Catherine Meadows, "Formal Verification of Cryptographic Protocols: A Survey," Advances in Cryptology - Asiacrypt '94, LNSC 917, Springer-Verlag, 1995, pp. 133-150. http://chacs.nrl.navy.mil/publications/CHACS/1995/1995meadows-asiacrypt94.ps In this paper we give a survey of the state of the art in the application of formal methods to the analysis of cryptographic protocols. We attempt to outline some of the major threads of research in this area, and also to document some emerging trends. a more recent meadows paper surveys open problems in the field: Meadows, Catherine, "Open Issues in Formal Methods for Cryptographic Protocol Analysis," Proc DISCEX 2000, IEEE Computer Society Press, pp. 237-250, January, 2000. http://chacs.nrl.navy.mil/publications/CHACS/2000/2000meadows-discex.ps The history of the application of formal methods to cryptographic protocol analysis spans nearly twenty years, and recently has been showing signs of new maturity and consolidation. A number of specialized tools have been developed, and others have effectively demonstrated that existing general- purpose tools can also be applied to these problems with good results. However, with this better understanding of the field comes new problems that strain against the limits of the existing tools. In this paper we will outline some of these new problem areas, and describe what new research needs to be done to to meet the challenges posed. i found these papers on her group's publications page: http://chacs.nrl.navy.mil/publications/CHACS/CRYPTOindex.html - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
>> Hans Dobbertin found some weaknesses in MD5 in 1996.
> Also note that RFC 2104 on the HMAC construction used in IPSEC
> explicitly cites Dobbertin and says the attack does not apply:
this is because dobbertin's attack works only
against message-digest applications of md5;
his attack doesn't work against md5 MACs, ie,
when md5 is used to hash a symmetric key with
the plaintext.
but, i generally tell clients to use sha-1 even
for MACs, just to avoid confusing their customers.
- don davis, boston
-
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
blocking chinese domains?
does anyone know whether china has recently shut
down its citizens' outgoing network access?
in looking over the hits on my web-page recently,
i noticed a bizarre factoid: of 7000 hits, none
came from the .cn domain; there were hits from
armenia, fiji, niue, korea, and other equally-
small venues, but none at all from the PRC. is
there any known reason for this consistent disparity?
- don davis, boston
-
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: crypto flaw in secure mail standards
At 10:15 AM -0500 6/22/01, Don Davis wrote: > All current secure-mail standards specify, as their > "high-security" option, a weak use of the public-key > sign and encrypt operations. please forgive my failure to reply to the list members' comments individually, but my paper has attracted so much mail, that i can't fulfill my obligation to answer each of you courteously. your critiques fall into a few categories: * old news; there's no new crypto problem here; * not a crypto problem, but a foolish-user problem; * not a crypto problem; the attacks work even without encryption, and even with surface mail; * not a crypto problem, because the problem is easily fixed with signed header-info, or with signed salutations. * this problem is one of a large class that's too hard to fix in full generality. my paper raises almost all of these points, and i agree with all of them, except with their common theme: "it's not really a crypto problem." in my paper, i argue that there _is_ a clear-cut lapse of good crypto-protocol design here. the most basic difference between my claim and the critiques, is about usability. i believe today's secure-mail protocols should fulfill today's users' rather naïve and inarticulate expectations about security and ease-of-use. unfortunately, today's secure-mail protocols were designed before these naïve newbie users flooded into the net. this isn't the fault of the diligent and brilliant engineers who contri- buted to the various secure-mail standards. but, i suggest that it's more realistic to revisit their work, and to change the secure-mail protocols and products, than it is to try to change all of the net's naïve users into crypto-aware users who can wield the current secure-mail products effectively. - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
crypto flaw in secure mail standards
> All current secure-mail standards specify, as their
> "high-security" option, a weak use of the public-key
> sign and encrypt operations. ...
i've received permission from usenix to release the
paper on saturday (6/23):
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
- don davis, boston
http://world.std.com/~dtd
-
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
crypto flaw in secure mail standards
All current secure-mail standards specify, as their "high- security" option, a weak use of the public-key sign and encrypt operations. On Thursday the 28th of this month, I'll present my findings and my proposed repairs of the protocols, at the Usenix Technical Conference here in Boston: http://www.usenix.org/events/usenix01/usenix01.pdf Citation: Don Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML." To appear in Proc. Usenix Tech. Conf. 2001, Boston. June 25-30, 2001. A short summary: All current secure-mail standards have a significant cryptographic flaw. There are several standard ways to send and read secure e-mail. The most well-known secure mail systems are PGP and S/MIME. All current public- key-based secure-mail standards have this flaw. Here are some examples of the flaw in action: Suppose Alice and Bob are business partners, and are setting up a deal together. Suppose Alice decides to call off the deal, so she sends Bob a secure-mail message: "The deal is off." Then Bob can get even with Alice: * Bob waits until Alice has a new deal in the works with Charlle; * Bob can abuse the secure e-mail protocol to re-encrypt and resend Alice's message to Charlie; * When Charlie receives Alice's message, he'll believe that the mail-security features guarantee that Alice sent the message to Charlie. * Charlie abandons his deal with Alice. Suppose instead that Alice & Bob are coworkers. Alice uses secure e-mail to send Bob her sensitive company-internal sales plan. Bob decides to get his rival Alice fired: * Bob abuses the secure e-mail protocol to re-encrypt and resend Alice's sales-plan, with her digital signature, to a rival company's salesman Charlie. * Charlie brags openly about getting the sales plan from Alice. When he's accused in court of stealing the plan, Charlie presents Alice's secure e-mail as evidence of his innocence. Surprisingly, standards-compliant secure-mail clients will not detect these attacks. -- Abstract Simple Sign & Encrypt, by itself, is not very secure. Cryptographers know this well, but application programmers and standards authors still tend to put too much trust in simple Sign-and-Encrypt. In fact, every secure e-mail protocol, old and new, has codified naïve Sign & Encrypt as acceptable security practice. S/MIME, PKCS#7, PGP, OpenPGP, PEM, and MOSS all suffer from this flaw. Similarly, the secure document protocols PKCS#7, XML- Signature, and XML-Encryption suffer from the same flaw. Naïve Sign & Encrypt appears only in file-security and mail-security applications, but this narrow scope is becoming more important to the rapidly-growing class of commercial users. With file- and mail-encryption seeing widespread use, and with flawed encryption in play, we can expect widespread exposures. In this paper, we analyze the naïve Sign & Encrypt flaw, we review the defective sign/encrypt standards, and we describe a comprehensive set of simple repairs. The various repairs all have a common feature: when signing and encryption are combined, the inner crypto layer must somehow depend on the outer layer, so as to reveal any tampering with the outer layer. Once I've presented the paper, I'll make this link live: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps - don davis, boston http://world.std.com/~dtd - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
article: german secure phone
http://www.newscientist.com/dailynews/news.jsp?id=ns819 Portable privacy A mobile phone that protects transmissions from sophisticated eavesdropping is launched in Germany A mobile phone that protects transmissions from sophisticated eavesdropping has been launched in Germany. Communications company Rohde Schwarz created the TopSec GSM phone by fitting military grade encryption hardware into an ordinary S35i Siemens mobile phone. The company expects the device to appeal to businessmen who want to protect themselves against industrial espionage and government representatives concerned about spying. "In both cases communications have to be secure," says a company representative. Ex-Nato technical expert Brian Gladman told New Scientist: "If done correctly, the encryption would be effectively attack-proof." Although the GSM standard does protect transmissions by encoding them, a number of weaknesses have been discovered with the system. These could allow sophisticated eavesdroppers to listen in. The TopSec GSM phone is designed to provide an extra, robust layer of security. The phone may not be for everyone, however. Each device costs £1800 and so far only 500 handsets have been created. These must also be bought directly from Rohde Schwarz. Private keys The handset works like any normal GSM mobile phone. But users can establish a secure communications channel when "Crypto" is selected from the customised display menu. When a number is dialled and the Crypto function selected, the phone checks to see if the device at the other end is compatible. Currently, the phone works only with other TopSec mobile phones and ISDN phones produced by Rohde Schwarz. If the device at the other end is compatible, each phone opens a data channel and exchanges its public encryption key. Using mathematically-linked private keys, the phones then establish a shared code for securing voice communications at speed. It is theoretically possible to decipher messages encrypted in this way by trying all possible keys in succession. But in practice this would require a formidable amount of computational power. Rohde Schwarz estimates that it would take 100 average desktop computers 10 years to decrypt a 10-minute phone call. Attack-proof Although the encryption itself may be secure, Gladman says it might be possible to trick the phones into giving up their secrets using a "man in the middle" attack. This would involve carrying out a dummy key exchange with both parties and creating two secure channels. Each party would be communicating securely, but only through a third eavesdropper. This technique would be beyond most industrial spies. Gladman says it might be within the capabilities of some government intelligence agencies, however. Devices that work along similar lines are already used by the US military. And this is not the first attempt to make a commercial encryption phone. US company Starium has created a device that can be attached to standard phone lines in order to secure voice communications with encryption. Web link: Rohde Schwarz http://www.rohde-schwarz.com/ 1630 GMT, 31 May 2001 - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: use of digital signatures and PKI
Gócza Zoltán wrote:
> I wonder if you could make any comments whether digital signatures are
> really NOT used worldwide as the paper states! Unfortunately I could not
> find any research or survey. Any reference would be greatly appreciated.
i have one potent, anecdotal data point: a friend of
mine is a 3-letter executive at one of the older/bigger
PKI vendors. he surprised me in a recent conversation,
by mentioning that essentially none of his company's
customers are using PKI for signatures. actually, he
may have said, "_no-one_ is using PKI for signatures."
he says that practically all of the certs are being
used for negotiating symmetric session-keys.
- don davis, boston
-
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Alcatel ADSL Modem vulnerabilities
Summary: Researchers associated with the San Diego Supercomputer Center at the University of California, San Diego have identified multiple implementation flaws in the Alcatel Speed Touch ADSL "modem" (actually an ADSL-Ethernet router/bridge). These flaws can allow an intruder to take complete control of the device, including changing its configuration, uploading new firmware, and disrupting the communications between the telephone central office providing ADSL service and the device. These flaws allow the following malicious actions: * changing the device's configuration such that the device can no longer be accessed; * disabling the device, either temporarily or permanently (requiring return of the device to the manufacturer); and * installation of malicious code, such as a network sniffer to gather local LAN traffic (that is not being bridged) and making the box more easily/covertly remotely accessible. One of the more interesting discoveries was a cryptographic challenge-response back door that completely bypasses any password that a user may have set on the device. All testing to date has been done in LLC/SNAP bridge mode. Routing mode was not tested. There may be other flaws that are easier to exploit in that mode. (Speed Touch is a trademark of Alcatel.) http://security.sdsc.edu/self-help/alcatel/alcatel-bugs.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
