Re: questions about RNGs and FIPS 140
Hello. Am Donnerstag 26 August 2010 12:25:55 schrieb Jerry Leichter: [...] 4) What about VMs? Rolling back a deterministic RNG on those systems gives the same values unless/until you re-seed with something new to this iteration I'm not sure what you mean by rolling back. Yes, if you restart any deterministic RNG with a previously-used internal state, it will generate the same stream it did before. This is true whether you are in a VM or not. That is true. Luckily /dev/random is re-seeded during run-time. So even if you do a roll-back of a system and the new input it non-deterministic it will generate different output immediately. RNG's in VM's are a big problem because the unpredictable values used in the non-deterministic parts of the algorithms - whether you use them just for seeding or during updating as well - are often much more predictable in a VM than a real machine. (For example, disk timings on real hardware have some real entropy, but in a VM with an emulated disk, that's open to question.) I really doubt it. Are there papers about it? It does not matter if there is one physical disk that is shared between 1000 processes or between 10 VMs each running 100 processes (assuming a shared random pool). The entropy is not generated by the disk but by the processes accessing it in a (hopefully) non-deterministic way. The HDD interrupts are just the sampling point. Therefore gaining entropy depends on the level of abstraction where the sampling point is placed. It can be assumed that the buffered HDD writing and reading on the host of a VM produce less entropy than the real read(2) and write(2) calls within the VM itself. Bye Thomas - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: /dev/random and virtual systems
Hi, we are using haveged in our VMs to feed the random pool and it seems to work good (means: statistical verification of the output looks good, nearly 0 entropy overestimation, but we never correlated output from cloned VMs). I assume feeding the VMs from the host system can be problematic because the host system itself often doesn't have enough entropy. Much entropy is needed today for protocolls, session IDs and the elf_loader(!). Cheerio Thomas Am Montag 02 August 2010, 21:38:10 schrieb Yaron Sheffer: Hi, the interesting thread on seeding and reseeding /dev/random did not mention that many of the most problematic systems in this respect are virtual machines. Such machines (when used for cloud computing) are not only servers, so have few sources of true and hard-to-observe entropy. Often the are cloned from snapshots of a single virtual machine, i.e. many VMs start life with one common RNG state, that doesn't even know that it's a clone. In addition to the mitigations that were discussed on the list, such machines could benefit from seeding /dev/random (or periodically reseeding it) from the *host machine's* RNG. This is one thing that's guaranteed to be different between VM instances. So my question to the list: is this useful? Is this doable with popular systems (e.g. Linux running on VMWare or VirtualBox)? Is this actually being done? Thanks, Yaron - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Persisting /dev/random state across reboots
Am Donnerstag 29 Juli 2010, 21:47:01 schrieb Richard Salz: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? Indeed. The boot process of a machine is very deterministic and if you do not have any Hardware RNG you need to seed /dev/random. At least old Linux kernels (2.4) also overestimate the entropy in the pool by about 30% which is especially a problem when you generate ssh host keys during system installation. Bye Thomas -- Thomas Biege tho...@suse.de, SUSE LINUX, Security Support Auditing SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- Wer aufhoert besser werden zu wollen, hoert auf gut zu sein. -- Marie von Ebner-Eschenbach - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Wikileaks video crypto.
On Fri, Apr 9, 2010 at 13:06, Perry E. Metzger pe...@piermont.com wrote: The video was apparently intentionally given to Wikileaks, so one can't imagine that the releasing parties would have wanted it to be unreadable by them (or that any reasonable modern cryptosystem would have be crackable). What, then, does the decryption claim mean here. Does anyone know? majord...@metzdowd.com This site http://leaks.telecomix.org/ claims to have the original, unencrypted video. It appears to have been encrypted with OpenSSL given the Salted__ prefix. -- Thomas Coppi - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Client Certificate UI for Chrome?
From: James A. Donald [jam...@echeque.com] Sent: Sunday, August 09, 2009 1:21 AM To: Thomas Hardjono Cc: Ben Laurie; Cryptography Subject: Re: Client Certificate UI for Chrome? Thomas Hardjono wrote: In this UI discussion, I think its less relevant whether trust is hierarchical or flat/p2p. The hard part is always certificate management, which has to be launched off existing trust and connections. So the question is, do we have certificate management that assumes that everyone has boundless trust in Verisign, and no trust in existing connections and existing shared knowledge, or do we have certificate management designed make use of any existing connections, trust, and shared knowledge, wherever it is to be found? [bottom-posted] Agree. Unfortunately (or fortunately) some browsers have shipped with root CA certs for a number of years now, which does force the end-user to trust the CA. This has been great for sales of SSL certs for VeriSign and other CAs but there is still that fundamental problem of educating the average user (Mom/Dad) about equating trust with certs (or root CA certs).=20 I'm not sure if the Chrome folks would be prepared to ship their browser without any CA certs loaded, but that would be an interesting and perhaps even revolutionary idea. Assuming the Chrome UI had a nice and easy way for users to download and install certs (trust anchors), this approach could level the playing field and allows other modes of trust to be played-out. Both LinkedIn and FaceBook could in fact be CAs that issue certs based on the number of verified connections that a person had. /thomas/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Client Certificate UI for Chrome?
Ben, Having worked at a large CA for along time (trying to push for client-side certs with little luck), here are some thoughts on what Chrome could provide: (a) Association with net identities: Provide some way for the user to associate his/her X.509 cert with an internet identity string (eg. OpenID, email address, etc etc) in the browser. (Yes, we could add such an identity in the SubjAltName, but that's outside the control of the end-user). This would allow the user to choose which cert to deliver to the server when the user is engaging the server using one of his/her identities. (PS. being able to associate with a small image/icon/photo of the user would also be nice). The UI should be a simple as click cert and click identity, and then click associate. (b) Export of certs: Provide an easy way to export client-certs to other apps. Currently some CAs use the browser as the primary means for cert enrollment. Currently in IE this is somewhat a lengthy process and the response (ie. export of cert successful or not) is also not very clear to the end-user. The UI should not even talk about export. It should say something along the lines of Do you want to make your certificate available to the following Apps. (c) Lock showing which cert/identity used: It would be useful if in addition to the Lock symbol (ie. SSL session established) there is a string (next to the Lock symbol) showing which client-side cert the browser is using for that SSL session. This is related to item (a) above, where a human-readable net identity is associate with the cert. This helps the user in distinguishing which identity he/she is using when connecting to a Bank versus a Blog versus a corporate web-mail (all of which could be using distinct cert/identity). If there is a mismatch, the user can see this visually. (d) Notification of expired certs: It would be good if the browser could somehow notify the user if there are some expired certs (belonging to the user) in the browser. I'm finding that some browsers deliver the first cert in the list even when it has expired (thus causing the server to reject). (e) Better notification/alerts of errors regarding server-certs: This is a hard one as the average user (eg. my Mom) does not understand about certs to begin with. Since one of the main aims of SSL server-certs today is to prevent phishing, perhaps those messages should be phishing-oriented. This one need further thought, but perhaps a third button/option could be provided (in addition to the Cancel and Continue buttons). This third button could provide the user with some alternate sites with similar sounding domain names but with proven/valid server-certs. (f) Better graphical representation of cert hierarchy: Perhaps not crucial, but a nice graphical representation of the cert hierarchy/tree might help educate the average user (my Mom/Dad) about what a CA is and where the user is located in the hierarchy. This would even help the average employee when his/her company is using a subordinate CA off a public CA. When the user clicks on a node in the tree, it should show the organization name and other human friendly details. (g) Easy check button for server-certs: It would be great if I could right-click the Lock symbol on the browser and be able to choose an action along the lines of Validate Server Certificate. The browser would then hit the corresponding OCSP Responder (as denoted in the server-cert) and report the status to the user using some graphical notation (eg. icon of server with a big X if the server-cert is invalid or status unknown). That's all for now. Will send more thoughts if any come up :) /thomas/ -Original Message- From: owner-cryptogra...@metzdowd.com [mailto:owner- cryptogra...@metzdowd.com] On Behalf Of Ben Laurie Sent: Wednesday, August 05, 2009 9:59 AM To: Cryptography Subject: Client Certificate UI for Chrome? So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. I imagine I may well hear what about the UI around server certificates? - fair enough, feel free, and I'll see what I can do. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] SHA-1 broken!
On Sun, May 3, 2009 at 4:35 PM, Christian Rechberger christian.rechber...@tugraz.at wrote: The design of DES facilitates this kind of throughput/cost gains on FPGAs. Remember that the MD4 family (incl. SHA-1) was designed to be efficient on 32-bit CPUs. For these hash functions, it is much harder to get a throughput/cost gain on FPGAs compared to off-the-shelf CPUs. At least, this was my conclusion when I quickly looked into this a few years ago. The n...@home project(http://nsa.unaligned.org/) seems to do it pretty well. He even provides the optimized SHA-1 and MD5 Verilog code used. This only works because straight-up bruteforce requires little memory, though. If the new SHA-1 break requires significant memory usage I don't think something like the COPACOBANA can help. Regards, -- Thomas Coppi - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Proof of Work - atmospheric carbon
On Wed, Jan 28, 2009 at 2:19 PM, John Levine jo...@iecc.com wrote: Indeed. And don't forget that through the magic of botnets, the bad guys have vastly more compute power available than the good guys. Just out of curiosity, does anyone happen to know of any documented examples of a botnet being used for something more interesting than just sending spam or DDoS? -- Thomas Coppi - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Decimal encryption
Hello, Actually, block ciphers encrypting blocks of *decimal* numbers exist: - TOY100 [1] encrypts blocks of 32 decimal digits - DEAN18 [2] encrypts blocks of 18 decimal digits - DEAN27 [3] encrypts blocks of 27 decimal digits TOY100 is (almost) broken by the generalized linear cryptanalysis described in [2]. Both versions of DEAN are based on a substitution permutation network very close to that of the AES and are provably secure against linear cryptanalysis. These ciphers are only toy ciphers. Consequently, there is no official implementation (no test- vector, etc.). Here are the references: [1] Granboulan, Levieil, Piret: Pseudorandom Permutation Families over Abelian Groups. FSE 2006: 57-77 [2] Baignères, Stern, Vaudenay: Linear Cryptanalysis of Non Binary Ciphers. Selected Areas in Cryptography 2007: 184-211 (available here: http://lasecwww.epfl.ch/~tbaigner/papers/groupLC.pdf ) [3] Baignères (PhD Thesis): Quantitative Security of Block Ciphers: Designs and Security Tools (to be published) I hope this helps. I'm of course available for any question regarding DEANxx. Best regards, Thomas Baignères -- http://lasecwww.epfl.ch/~tbaigner On Aug 27, 2008, at 5:05 PM, Philipp Gühring wrote: Hi, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: deriving multiple keys from one passphrase
Am Dienstag 10 Oktober 2006 01:35 schrieb Travis H.: What is the accepted way to derive several keys from a user-supplied input? Maybe RFC289. AFAIK it also describes the reason why it protects against dictionary attacks. Bye, Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: deriving multiple keys from one passphrase
Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.: On 10/13/06, Thomas [EMAIL PROTECTED] wrote: Maybe RFC289. I assume you mean 2289, which appears to describe the OTP scheme used by S/key. sorry, it was too early for an copy-n-paste ;) i meant: B. Kaliski; PKCS #5: Password-Based Cryptography Specification Version 2.0; RFC289 Bye, Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: deriving multiple keys from one passphrase
Am Freitag 13 Oktober 2006 12:26 schrieb Thomas: Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.: On 10/13/06, Thomas [EMAIL PROTECTED] wrote: Maybe RFC289. I assume you mean 2289, which appears to describe the OTP scheme used by S/key. sorry, it was too early for an copy-n-paste ;) i meant: B. Kaliski; PKCS #5: Password-Based Cryptography Specification Version 2.0; RFC289 hm, the last 8 is missing again. rfc2898 t. -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Did Hezbollah use SIGINT against Israel?
(I regard it as more likely that they were doing traffic analysis and direction-finding than actually cracking the ciphers.) IIUC, spread-spectrum communication is not much stronger than the background noise, and thus the traffic analysis is not that easy either. We can just speculate here, a practice I dislike, but for fun (hey today is Friday :) ) I'll add my 2 cent here too. My first thought while reading this article was: the seed! One thing I assume is that they did not break a cipher, even if the radio equipment uses DES with 56-bit keys I doubt they had broken it and can break it in real-time on the battle field. All they say is that they can now coordinate their anti-tank forces better because they know where Israeli tanks will appear on the battle field. This can be done with traffic monitoring and some simple math. formulas to calculate the directions the tanks drive, plus their distance, and a lower bound of the number of tanks (at least all communicating peers). But today military radio eq. use frequency hoping based on a PRNG. This PRNG is the same in every device and needs the same seed to hop to the right frequency at the right time. In the last few weeks during the fights the Hezbollah must be able to capture zillions of messages which all use the same freq. at the same time. Maybe they did some statistical magic and were able to guess the seed of the PRNG based on their observations. Or maybe they get access to a radio device and were able to reverse engineer the PRNG (or just connect the radio device to a capture device that uses the freq. the radio device will use). Or maybe it is just the usual war hoax blah blah, who knows. :) Whatever... Freq. hoping should protect against jamming only if I remember correctly. So if I were able to reproduce the PRNG's seed I would use it to disable the communication between troops during an attack and don't just do traffic analysis with it. The same result can be accomplished by let some guys sit in the trees with a spyglass, a compas, and a CB radio device. ;) Have a nice weekend, Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
James A. Donald wrote: Attacks on DNS are common, though less common than other attacks, but they are by scammers, not TLA agencies, perhaps because they are so easily detected. All logons should move to SRP to avoid the phishing problem, as this is the most direct and strongest solution for phishing for shared secrets, and phishing for shared secrets is the biggest problem we now have. Encrypting DNS is unacceptable, because the very large number of very short messages make public key encryption an intolerable overhead. A DNS message also has to fit in a single datagram. IIRC, from following the development of SPF (which uses rather lengthy DNS data records). A DNS message that fits inside of a single datagram can be sent via UDP, but if it spills over, the DNS server has to setup a TCP connection. So longer DNS messages are allowed, but they are either expensive (TCP vs UDP) or not supported by all implementations? (Did I get that right?) I do suspect at some point that the lightweight nature of DNS will give way to a heavier, encrypted or signed protocol. Economic factors will probably be the driving force (online banking). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gonzo cryptography; how would you improve existing cryptosystems?
On Tue, Nov 08, 2005 at 05:58:04AM -0600, Travis H. wrote: The only thing close that I've seen is Bestcrypt, which is commercial and has a Linux and Windows port. I don't recall if the Linux port came with source or not. http://www.truecrypt.org/ TrueCrypt Free open-source disk encryption software for Windows XP/2000/2003 and Linux Main Features: * It can create a virtual encrypted disk within a file and mount it as a real disk. * It can encrypt an entire hard disk partition or a device, such as USB memory stick, floppy disk, etc. * Provides two levels of plausible deniability, in case an adversary forces you to reveal the password: 1) Hidden volume (more information may be found here). 2) No TrueCrypt volume can be identified (TrueCrypt volumes cannot be distinguished from random data). * Encryption algorithms: AES-256, Blowfish (448-bit key), CAST5, Serpent (256-bit key), Triple DES, and Twofish (256-bit key). Supports cascading (e.g., AES-Twofish-Serpent). * Based on Encryption for the Masses (E4M) 2.02a, which was conceived in 1997. Further information regarding the features of the software may be found in the documentation. Complete source code (in C) of the latest stable version of TrueCrypt for all supported operating systems and all supported hardware platforms are available from http://www.truecrypt.org/downloads.php /Thomas -- signature.asc Description: Digital signature
Re: Bluetooth cracked further
Perry E. Metzger wrote: Matt Crawford [EMAIL PROTECTED] writes: On Jun 3, 2005, at 11:55, Perry E. Metzger wrote: 2) They also have a way of forcing pairing to happen, by impersonating one of the devices and saying oops! I need to pair again! to the other. Do the devices then pair again without user intervention, re-using the PIN that paired them initially? That is my understanding. Ugly, isn't it? The paper addresses countermeasures; it would appear that the original PIN is not stored for reuse in most (any?) implementations, but that there is an option to use a PIN every time the devices are connected, which would expose this risk: 6 Countermeasures This section details the countermeasures one should consider when using a Bluetooth device. These countermeasures will reduce the probability of being subjected to both attacks and the vulnerability to these attacks. Since Bluetooth is a wireless technology, it is very difficult to avoid Bluetooth signals from leaking outside the desired boundaries. Therefore, one should follow the recommendation in the Bluetooth standard and refrain from entering the PIN into the Bluetooth device for pairing as much as possible. This reduces the risk of an attacker eavesdropping on the pairing process and finding the PIN used. Most Bluetooth devices save the link key (Kab) in non-volatile memory for future use. This way, when the same Bluetooth devices wish to communicate again, they use the stored link key. However, there is another mode of work, which requires entering the PIN into both devices every time they wish to communicate, even if they have already been paired before. This mode gives a false sense of security! Starting the pairing process every time increases the probability of an attacker eavesdropping on the messages transferred. We suggest not to use this mode of work. Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers use a 4 digit PIN and supply it with the device. Obviously, customers should demand the ability to use longer PINs. -thomas -- Thomas Lakofski +44 70 9228 8229 'Reality is that which, when you stop believing in it, doesn't go away' --PKD gpg: 1024D/81FD4B43 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Bluetooth cracked further
Olle Mulmo wrote: On Jun 4, 2005, at 14:12, Thomas Lakofski wrote: Wrote? Well, quoted... Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers use a 4 digit PIN and supply it with the device. Obviously, customers should demand the ability to use longer PINs. Correction: Most manufacturers hardcode the 4-digit PIN to . It has been known for some time that those gadgets need to be paired in an Faradayic environment: if I recall correctly, a paper being presented on this at the RSA conference ~2001 or so. For some values of 'most.' This would cover mice, keyboards and wireless headsets. My MS Bluetooth mouse doesn't need any PIN or even encryption to connect... I've yet to see a Bluetooth-capable telephone with a fixed PIN; I would doubt that the number of shipped BT mice, keyboards and headsets exceeds the number of BT-capable telephones in existence. The forced re-pairing vulnerability is news to me. It makes me very concerned about Bluetooth keyboards... Your attacker would need to keep a device live and in the neighbourhood of your Bluetooth keyboard to perform a mitm attack; I'd be more worried about the non-Bluetooth wireless keyboards out there. -thomas ps, it's a little ironic that a post to a cryptography list has its digital signature stripped before reaching the list, no? -- Thomas Lakofski +44 70 9228 8229 'Reality is that which, when you stop believing in it, doesn't go away' --PKD gpg: 1024D/81FD4B43 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
