Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On Mon, 9 Sep 2013, Daniel wrote: Is there anyone on the lists qualified in ECC mathematics that can confirm that? NIST SP 800-90A, Rev 1 says: The Dual_EC_DRBG requires the specifications of an elliptic curve and two points on the elliptic curve. One of the following NIST approved curves with associated points shall be used in applications requiring certification under [FIPS 140]. More details about these curves may be found in [FIPS 186], the Digital Signature Standard. And what ramifications it has, if any.. No. They are widely used curves and thus a good way to reduce conspiracy theories that they were chosen in some malicious way to subvert DRBG. -- Regards, ASK ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES state of the art...
On Sun, 8 Sep 2013, Perry E. Metzger wrote: What's the current state of the art of attacks against AES? Is the advice that AES-128 is (slightly) more secure than AES-256, at least in theory, still current? I am not sure what is the exact attack you are talking about, but I guess you misunderstood the result that says: the attack works against AES-256, but not against AES-128 as meaning that AES-128 is more secure. It can be the case that to break AES-128 the attack needs 2^240 time, while to break AES-256 it needs 2^250 time. Here AES-128 is not technically broken, since 2^240 2^128, but AES-256 is broken, since 2^250 2^256, OTOH, AES-256 is still more secure against the attack. -- Regards, ASK ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] A Likely Story!
On Sun, 8 Sep 2013, Peter Fairbrother wrote: On the one hand, if they continued to recommend that government people use 1024-bit RSA they could be accused of failing their mission to protect government communications. On the other hand, if they told ordinary people not to use 1024-bit RSA, they could be accused of failing their mission to spy on people. What to do? NIST recommends at least RSA-2048 for a long time, for example NIST Special Publication 800-57, back in August, 2005 said: [...] for Federal Government unclassified applications. A minimum of eighty bits of security shall be provided until 2010. Between 2011 and 2030, a minimum of 112 bits of security shall be provided. Thereafter, at least 128 bits of security shall be provided. Note that RSA-1024 ~ 80 bits of security; RSA-2048 ~ 112 bits; RSA-3072 ~ 128 bits So if anyone to blame for using 1024-bit RSA, it is not NIST. BTW, once you realize that 256 bits of security requires RSA with 15360 bits, you will believe conspiracy theories about ECC much less. Here exponentiation with 15360 bits takes 15^3=3375 times more CPU time than a 1024-bit exponentiation, thus using RSA for 256-bit security is impractical. You can use any one of trillions of different elliptic curves,which should be chosen partly at random and partly so they are the right size and so on; but you can also start with some randomly-chosen numbers then work out a curve from those numbers. and you can use those random numbers to break the session key setup. Can you elaborate on how knowing the seed for curve generation can be used to break the encryption? (BTW, the seeds for randomly generated curves are actually published.) -- Regards, ASK ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Tue, 3 Sep 2013, radi...@gmail.com wrote: 1) Is there a NIST announce type list so I don't miss an entire standards update cycle or two again? That doesn't cover all the nitty gritty goings on during the journey to publication for FIPS updates? http://csrc.nist.gov/news_events/index.html 2) Is anyone aware of ITAR changes for SHA hashes in recent years that require more than the requisite notification email to NSA for download URL and authorship information? Figuring this one out last time around took ltttss of reading. I used to believe that hashing (unlike encryption) was not considered arms. -- Regards, ASK ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: questions about RNGs and FIPS 140
On Wed, 25 Aug 2010 travis+ml-cryptogra...@subspacefield.org wrote: No, because FIPS 140-2 does not allow TRNGs (what they call non-deterministic). I couldn't tell if FIPS 140-1 allowed it, but FIPS 140-2 supersedes FIPS 140-1. I assume they don't allow non-determinism because it makes the system harder to test/certify, not because it's less secure. I guess you misinterpret it. In no place 140-2 does not allow TRNG. It says that nondeterministic RNGs should be used *only* for IVs or to seed deterministic RNGs: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf: Until such time as an Approved nondeterministic RNG standard exists, nondeterministic RNGs approved for use in classified applications may be used for key generation or to seed Approved deterministic RNGs used in key generation. Commercially available nondeterministic RNGs may be used for the purpose of generating seeds for Approved deterministic RNGs. Nondeterministic RNGs shall comply with all applicable RNG requirements of this standard. An Approved RNG shall be used for the generation of cryptographic keys used by an Approved security function. The output from a non-Approved RNG may be used 1) as input (e.g., seed, and seed key) to an Approved deterministic RNG or 2) to generate initialization vectors (IVs) for Approved security function(s). The seed and seed key shall not have the same value. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Quantum Key Distribution: the bad idea that won't die...
http://arxiv.org/abs/1005.2376 Unconditional security proofs of various quantum key distribution (QKD) protocols are built on idealized assumptions. One key assumption is: the sender (Alice) can prepare the required quantum states without errors. However, such an assumption may be violated in a practical QKD system. In this paper, we experimentally demonstrate a technically feasible intercept-and-resend attack that exploits such a security loophole in a commercial plug play QKD system. The resulting quantum bit error rate is 19.7%, which is below the proven secure bound of 20.0% for the BB84 protocol. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Wed, 18 Nov 2009, Bill Frantz wrote: Perhaps I'm missing something, but my multiple banks will all accept my signature when made with the same pen. Why wouldn't they not accept my signature when made with the same, well protected, signing/user verifying device. I might have to take it to the bank to give them its public key in person, but that seems a minor inconvenience. The reasons can sound crazy from the technical person's point of view, like they may want to have a card with their name on it in your wallet. There are rumors that this is what ruined the idea that a single smartcard (e.g., JavaCard) can replace all cards in your wallet. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS man in the middle
On Sat, 7 Nov 2009, Sandy Harris wrote: I'm in China and use SSL/TLS for quite a few things. Proxy connections, Gmail set to always use https and so on. This is the main defense for me and many others against the Great Firewall. Should I be worrying about man-in-the-middle attacks from the Great Firewall servers? The attack does not directly allow to see any plaintext, it only prepends your data with attackers plaintext. IMO if the Great Firewall administrator wanted to intercept TLS traffic they would do the usual TLS MitM attack with replacement of certificates (as done by some corporate firewalls). Using the renegotiation attack for purposes allowed by law seems to be too round about. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto
On Fri, 30 Oct 2009, Darren J Moffat wrote: The SHA256 checksums are used even for blocks in the pool that aren't encrypted and are used for detecting and repairing (resilvering) block corruption. Each filesystem in the pool has its own wrapping key and data encryption keys. Due to some unchangeable constraints I have only 384 bits of space to fit in all of: IV, MAC (CCM or GCM Auth Tag), and the SHA256 checksum, which best case would need about 480 bits. Currently I have Option 1 below but I the truncation of SHA256 down to 128 bits makes me question if this is safe. Remember the SHA256 is of the ciphertext and is used for resilvering. If you use hash only to protect against non-malicious corruptions, when why you use SHA-2? Would not MD5 or even CRC be enough? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
QNAP backdoor
http://www.securityfocus.com/archive/1/506607 Overview: The premium and new line of QNAP network storage solutions allow for full hard disk encryption. When rebooting, the user has to unlock the hard disk by supplying the encryption passphrase via the web GUI. However, when the hard disk is encrypted, a secondary key is created, added to the keyring, and stored in the flash with minor obfuscation. Additional Weaknesses: The backdoor key is generated by rand() calls. As the rand() function produces random numbers unsuitable for cryptographic keys. The cryptographic strength of this generated key is approx 2^32, hence feasible for breaking. This would make access to the flash unnecessary. Original Vendor FUD: The functionality for encryption the hard disk does not include a crypto backdoor. (in response to a user question why two keyslots are allocated, and if this is because of a backdoor) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: brute force physics Was: cleversafe...
Jerry Leichter wrote: If current physical theories are even approximately correct, there are limits to how many bit flips (which would encompass all possible binary operations) can occur in a fixed volume of space-time. The physical arguments to which I was referring say *nothing* about how the computation is done. It can be a QM computation as well. Obvious assumptions are hardest to trace: they assume that the computation is done by bit flips which flip only constant number of bits. QM computation is done with the whole state, that is a flip in an N-qbit state simultaneously flips 2^N numbers describing this state (if it were simulated by a classical computer). I hope we agree that an exponential speed-up by QM computation *is* possible (unless factoring is in P). That is why if we hear that (1) a physical limit says that 2^N bit-flips cannot be done in a one-light-year computer in a year, and we know that (2) the best classical M-bit factoring requires 2^N bit-flips, and we know that (3) this factoring can be done in few minutes on a QM computer, then we must conclude that such physical limits are misleading. David Wagner wrote: for a more nuanced and deep treatment of these issues, http://www.scottaaronson.com/papers/npcomplete.pdf Thanks, it is great reading! Whether NP is physically computable is an interesting topic, but its applicability to our subject is quite limited: for cryptography it is important to know that none of the puzzles created by a user can be solved in some particular time given reasonable investment in hardware, and thus the fact that hard instances exist as size tends to infinity cannot console a practitioner. Jerry Leichter wrote: All the protocols and standards out there calling for AES-256 - it's obviously better than AES-128 because after all 256 is *twice as large* as 128! - were just a bunch of nonsense. And, perhaps, dangerous nonsense. I see the situation in the positive way: the recent AES attacks stress the fact that the key management should be done correctly, in particular, keys should be derived thru KDF (not a simple xor) and must be authenticated. With this attack in hand it is much easier for us now to say why one should not use K to encrypt messages of one type and K+1 for another type, or why it is a bad idea to encrypt a key in CTR mode and store the result without a MAC. I doubt it is possible to find any professionally designed protocol or standard that becomes weak due to the recent discovery. That's a ... bizarre point of view. :-) Should freedom from related- key attacks be part of the definition of a secure encryption algorithm? We should decide that on some rational basis, not on whether, with care, we can avoid such attacks. Clearly, a system that *is* secure against such attacks is more robust. Do we know how to build such a thing? What's the cost of doing so? But to say it's an *advantage* to have a weakness seems like some kind of odd moral argument: If you're hurt by this it's because you *deserve* to be. There is a set of rules in cryptographic design that are well known to practitioners and are ignored by kibitzers. In many cases it is much easier to do a normal design than to explain why some proposed improvements are bad. Consider a situation where some smart person comes to you and say that for some reason (say, to save space) they want to use CBC encryption, but keep IV constant; or they want to do CBC encryption and CBC-MAC with the same key (as a bonus they get encryption for free). What options you have once you manage to stop the laughter? In some cases it is enough to say: No, SP800-38a in Appendix C requires IV for CBC to be unpredictable, but in other cases you also need to show a plausible-looking attack against the improvement. In this situation it is clearly an advantage to have a known weakness of ignoring rules of sane key management. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
brute force physics Was: cleversafe...
On Sun, 9 Aug 2009, Jerry Leichter wrote: Since people do keep bringing up Moore's Law in an attempt to justify larger keys our systems stronger than cryptography, it's worth keeping in mind that we are approaching fairly deep physical limits. I wrote about this on this list quite a while back. If current physical theories are even approximately correct, there are limits to how many bit flips (which would encompass all possible binary operations) can occur in a fixed volume of space-time. A problem with this reasoning is that the physical world and the usual digital computers have exponential simulation gap (it is known at least in one direction: to simulate N entangled particles on a digital computer one needs computations exponential in N). This can be considered as a reason to suspect that physical world is non-polynomially faster than the usual computers (probably even to an extent that all NP computations can be simulated). While it is possible to use physical world to simulate usual computers in the straightforward way (namely by using voltage levels of a circuit to represent separate bits), it is not clear that doing computations in this way is the best way to do computations, for example, if the meaning of our computations are simulation of the physical world, then it can be better to use direct physical-to-physical mapping instead of physical-to-usual followed by usual-to-physical: analog computers, such as wind tunnels, are still in use. I am not aware of any plausible argument why a brute force search in general (a quintessence of NP class, by the way) or a key search against any particular algorithm cannot be implemented in a direct way significantly faster than in the indirect way, that is NP-to-physical instead of NP-to-usual followed by usual-to-physical. All the fuss about quantum computing is exactly because people believe that a different mapping (not thru usual computers) can be more efficient (if I understand correctly, right now neither the class of algorithms that can be sped up this way is understood, nor the quantum computers of practical capacity exist). All the protocols and standards out there calling for AES-256 - it's obviously better than AES-128 because after all 256 is *twice as large* as 128! - were just a bunch of nonsense. And, perhaps, dangerous nonsense. I see the situation in the positive way: the recent AES attacks stress the fact that the key management should be done correctly, in particular, keys should be derived thru KDF (not a simple xor) and must be authenticated. With this attack in hand it is much easier for us now to say why one should not use K to encrypt messages of one type and K+1 for another type, or why it is a bad idea to encrypt a key in CTR mode and store the result without a MAC. I doubt it is possible to find any professionally designed protocol or standard that becomes weak due to the recent discovery. Of course, if AES-256 was used (say for hashing) with input as the key, then nobody should be surprised that the version that takes 256 bits at a time is weaker than the version that spends comparable time for processing only 128 bits. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Attacks against GOST? Was: Protocol Construction
On Sun, 2 Aug 2009, Joseph Ashwood wrote: So far, evidence supports the idea that the stereotypical Soviet tendency to overdesign might have been a better plan after all, because the paranoia about future discoveries and breaks that motivated that overdesign is being regularly proven out. And that is why Kelsey found an attack on GOST Do you want to say that the GOST (28147-89) block cipher is broken? I have never heard of an attack against it that is faster than the exhaustive search. By the way, it was not overdesign (IMO it is simpler even than DES), nor it was an example of the stereotypical Soviet... According to an informed source [1], it was specifically made to be not like military ciphers: its only purpose was to make something for non-military cryptography that would not betray any Soviet cryptographic know-how (this is why they chose to do something very similar to DES). [1] Mikhail Maslennikov, Cryptography and freedom (in Russian) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
white-box crypto Was: consulting question....
On Tue, 26 May 2009, James Muir wrote: There is some academic work on how to protect crypto in software from reverse engineering. Look-up white-box cryptography. Disclosure: the company I work for does white-box crypto. Could you explain what is the point of white-box cryptography (even if it were possible)? If I understand correctly, the only plausible result is to be able to use the secret key cryptography as if it were the public-key one, for example, to have a program that can do (very slow, btw) AES encryption, but be unable to deduce the key (unable to decrypt). If this is the case, then why not use normal public-key crypto (baksheesh aside)? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
On Sun, 15 Feb 2009, Rene Veerman wrote: Recently, on both the jQuery(.com) and PHP mailinglists, a question has arisen on how to properly secure a login form for a non-ssl web-application. But the replies have been get ssl.. :( Unfortunately, they are right: get SSL. If you have a completely alternative way of securing a non-ssl login form, i'd like to hear about it too. I suspect what you have coded is a reinvention of RFC 2617 (implemented, e.g., by mod_auth_digest in Apache). Depending on your threat model, this can be all you need (plaintext password is not transmitted, but this does not prevent local dictionary attacks), but any such scheme fails miserable against active attacks. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
On Wed, 11 Feb 2009, Ben Laurie wrote: If I have data on my server that I would like to stay on my server and not get leaked to some third party, then this is exactly the same situation as DRMed content on an end user's machine, is it not? The treat model is completely different: for DRM the attacker is the user who supposedly has complete access to computer, while for server the attacker is someone who has only (limited) network connection to your server. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
AES HDD encryption was XOR
http://www.heise-online.co.uk/security/Encrypting-hard-disk-housing-cracked--/news/112141: With its Digittrade Security hard disk, the German vendor Digittrade has launched another hard disk housing based on the unsafe IM7206 controller by the Chinese manufacturer Innmax. The German vendor prominently advertises the product's strong 128-bit AES encryption on its packaging and web page. In practice, however, the hard disk data is only encrypted using a primitive XOR mechanism with an identical 512-Byte block for each sector. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Randomness testing Was: On the randomness of DNS
On Mon, 4 Aug 2008, Stephan Neuhaus wrote: Or better still, make many tests and see if your p-values are uniformly distributed in (0,1). [Hint: decide on a p-value for that last equidistribution test *before* you compute that p-value.] Of course, there are many tests for goodness of fit (Kolmogorov- Smirnov, chi-square, etc.) and also you can calculate for a given number of tests how many tests should have p-value below the significance level. And after making hundred tests you ask yourself what you gonna do once your test gives good uniformity, say p-value is 0.23, but the proportion is 0.95, while the minimum pass rate for 1% is 0.96. Only a bad statistician cannot justify any predefined answer :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Randomness testing Was: On the randomness of DNS
On Thu, 31 Jul 2008, Pierre-Evariste Dagand wrote: Just by curiosity, I ran the Diehard tests[...] Sum-up for /dev/random: Abnormally high value: 0.993189 [1] Abnormally low value: 0.010507 [1] Total: 2 Sum up for Sha1(n): Abnormally high values: 0.938376, 0.927501 [2] Abnormally low values: 0.087107, 0.091750, 0.060212, 0.050921 [4] Total: 6 So, I would say that Sha1(n) does not pass DieHard (while /dev/random does). But this would require further examination, in particular to understand why some tests failed. And, in fact, I have no clue why they failed... See http://en.wikipedia.org/wiki/P-value. Since p-value is supposed to be uniform on the interval [0,1] for a truly random source, it is no wonder that with so many p-values some of them are close to 0 and some are close to 1. If your p-value is smaller than the significance level (say, 1%) you should repeat the test with different data and see if the test persistently fails or it was just a fluke. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ransomware
On Mon, 9 Jun 2008, Leichter, Jerry wrote: Even worse, targeted malwared could attack your backups. If it encrypted the data on the way to the backup device, it could survive silently for months, by which time encrypting the live data and demanding the ransom would be a very credible threat. I suspect that home users are the main target of such viruses, and such users usually do not make backups at all (I guess the people who value their data enough to make backups, are also diligent enough to do backup validation). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Tue, 13 May 2008, Ben Laurie wrote: Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing I think we all should not miss this ROTFL experience: Original code (see ssleay_rand_add) http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=140view=markup, the patch http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141view=diffr1=141r2=140p1=openssl/trunk/rand/md_rand.cp2=/openssl/trunk/rand/md_rand.c and the end result http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141view=markup -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSparc -- the open source chip (except for the crypto parts)
On Thu, 1 May 2008, zooko wrote: I would think that it also helps if a company publishes the source code and complete verification tools for their chips, such as Sun has done with the Ultrasparc T2 under the GPL. To be sure that implementation does not contain back-doors, one needs not only some source code but also a proof that the source code one has is the source of the implementation. With open-source software one can get such a proof by compiling the source themself (as far as they trust their compiler toolchain), but I don't see any way to get such a proof for non-FPGA hardware. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
privacy expectations Was: SSL and Malicious Hardware/Software
On Tue, 29 Apr 2008, Jack Lloyd wrote: Expectations of privacy at work vary by jurisdiction and industry. In the US, and say in the financial services industry, any such expectations are groundless (IANAL). Most places I have worked (all in the US) explicitly required consent to more or less arbitrary amounts of monitoring as a condition of employment. Even if you sign a contract that you do not have any expectations of privacy, it does not mean that you do not have them: honestly, you do expect that your coworkers are not going to read you personal emails, right? http://www.securityfocus.com/columnists/421/2: Lance Corporal Jennifer Long was issued a government computer to use on a government military network. When she was suspected of violations of the military drug use policies (and of criminal laws related to drug use), Marine Corps criminal investigators reviewed the contents of email messages she sent to another military employee who was likewise using a government issued computer over the same government network. The messages were retrieved from the government mail server and later used against Long. On September 27, 2006, the United States Court of Appeals for the Armed forces had to decide whether Long had any expectation of privacy in these e-mails. The starting point for any analysis is, of course, the DoD policy expressed on its warning banner, which stated quite explicitly: [...] All information, including personal information, placed on or sent over this system may be monitored. Use of this DoD computer system, authorized or unauthorized, constitutes consent to monitoring of this system. [...] However, the military court, [...] found that Long did, in fact have some privacy interests in the contents of her communications. It noted that while the government said it could monitor, it rarely did. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
no possible brute force Was: Cruising the stacks and finding stuff
On Tue, 22 Apr 2008, Leichter, Jerry wrote:
Interestingly, if you add physics to the picture, you can convert
no practical brute force attack into no possible brute force
attack given known physics. Current physical theories all place a
granularity on space and time: There is a smallest unit of space
beyond which you can't subdivide things, and a smallest unit of
time.
I guess you are talking about Planck units, so let's make the
calculations:
Planck length is L = \sqrt{hbar G / c^3} ~ 1.6E-35 m,
Planck time T = L/c ~ 5.4E-44 s,
so a cubic-meter-computer can have
N = (1/L)^3 ~ 2.4E104 elements
and thus
N/T ~ 4.5E147 operations per second
that is approximately 2^{490} operations per second in a cubic meter
of Planck computer. Given a year (3.15E7 s) on a Earth-size
(1.08E21 m^3) Planck computer we can make approximately 2^{585}
operations.
OK, it was amusing to do these calculations, but does it mean
anything? I think it is more like garbage-in-garbage-out process.
If I understand correctly, L and T are not non-divisible units of
space-time, but rather boundaries for which we understand that our
current theories do not work, because this scale requires unification
of general relativity and quantum mechanics.
Even more bizarre is to think about the above processing element as
representing a single bit: according to quantum mechanics, states of a
system are represented by unit vectors in associated Hilbert space of
the system and each observable is represented by a linear operator
acting on the state space. Even if we have only two qubits they are
not described by two complex numbers, but rather by 4:
a_0|00 + a_1|01 + a_2|10 + a_3|11
and thus description of the state of quantum registers requires
exponential number of complex numbers a_i and each operation
simultaneously process all those a_i. Since we cannot measure
them all, it is an open question whether quantum computations
provide exponential speed-up and all we know right now is that
they give at least quadratic one.
By the way, if you have a computer with the processing power larger
than that of all the cryptanalysts in the world, it makes sense to use
your computer to think to find a better attack than a brute-force
search :-)
One place this shows up, as an example: It turns out give a volume
of space, the configuration with the maximum entropy for that volume
of is exactly a black hole with that volume
[OT] This is a strange thesis because all black hole solutions in
general relativity can be completely characterized by only three
externally observable parameters: mass, electric charge, and angular
momentum (the no-hair theorem) and thus in some sense they have zero
entropy (it is not necessary a contradiction with something, because
it takes an infinite time for matter to reach the event horizon).
and its entropy turns out to be the area of the black hole, in units
of square Planck lengths.
[OT] Although Hawking showed that the total area of the event horizons
of a collection of black holes can never decrease, which is *similar*
to the second law of thermodynamics (with entropy replaced by area),
it is not clear that it allows to conclude that area *is* entropy.
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Toshiba shows 2Mbps hardware RNG
On Wed, 13 Feb 2008, Dave Korn wrote: On 11 February 2008 17:37, Crawford Nathan-HMGT87 wrote: I'm wondering if they've considered the possibility of EMI skewing the operation of the device, or other means of causing the device to genearate less than completely random numbers. Not necessarily a problem, although it does depend on their design. Even if by saturating the chip in an intense EM field you can skew the result almost all the way to 1 or 0, won't the standard debiassing trick of examining successive pairs of bits handle that? It depends on the attack: Consider John von Neumann's algorithm that, say, outputs the first bit in each pair if bits are different. If you apply EM attack and get 0s almost everywhere 00 00 00 01 00 00 00 10 00 00 10 00 00 but cannot control where 1s are exactly, then JvN corrector helps, but if your EM attack is such that it makes long runs of 0s and 1s 00 00 00 11 11 11 10 00 00 00 01 11 11 and you can detect when the bits are produced then you know exactly what bits are produced (if a bit produced on transition from 0s to 1s then it is 0). Considering speed of nondeterministic RNG, it seems pointless at least for those who go thru FIPS certification. FIPS 140-2 says Commercially available nondeterministic RNGs may be used for the purpose of generating seeds for Approved deterministic RNGs. [...] An Approved RNG shall be used for the generation of cryptographic keys used by an Approved security function. The output from a non-Approved RNG may be used 1) as input (e.g., seed, and seed key) to an Approved deterministic RNG or 2) to generate initialization vectors (IVs) for Approved security function(s). and currently there is no Approved nondeterministic RNG, so the only option is to use nondeterministic RNG to generate seeds for the deterministic one and one does not need MBps speed to generate a seed. But again, comparing a useful feature and a check mark on marketing slides, the latter is doomed to be implemented. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Changes in Russian licensing of cryptraghical tools
On Thu, 17 Jan 2008, Gleb Paharenko wrote: Russian government accepted a changes in laws about licensing cryptographic algorithms and devices. The statement in Russian language: http://www.garant.ru/hotlaw/doc/109485.htm Essential in English: You do not need to license staff which uses: * symmetric ciphers with key length less 56 bits; * assymetric ciphers with key length less 128 bits based on factoring or discrete logarithms; In my opinion such a summary is very confusing, I suspect that for ordinary people item 1.b is more important. The document says (my translation): 1. This document is not applicable to distribution of: [...] b) cryptographic means which are available without limit for retail distribution, or thru mail orders, or electronic deals, or deals by telephone software operating systems, cryptographic capabilities of which cannot be changed by customers, which are developed for installation by customers without additional significant support by supplier and which have technical documentation (description of algorithms of cryptographic transformations, communication protocols, interface descriptions, etc.) which is available for audits. That is, if I understand correctly, this document is not applicable to GnuPG or other such tools. Given what is required to get a license (for example, 4.b in the first document, says that one must have people trained in information security), I guess the new law is not supposed to limit use of cryptography by ordinary people, but to limit distribution of snake-oil by self-proclaimed professionals. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, 19 Sep 2007, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. Not a single IKE implementation [...] were validating the Diffie-Hellman public keys that I sent. There are many ways to use DH key-agreement. The one described on the page is as follows: both A and B generate random values, exponentiate, exchange results, and derive the same value. In this case there is no point validating the `public key' A receives from B: if B colludes with an attacker (and generates the key belonging to a small subgroup), then B can as well tell the final secret to the attacker. The attack would make sense if it allows B to learn a long-term secret of A, but if the `private keys' are randomly generated on each exchange, then this problem does not exist. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: using SRAM state as a source of randomness
Hi. On Sun, 16 Sep 2007, Joachim Strmbergson wrote: One could add test functionality that checks the randomness of the initial SRAM state after power on. But somehow I don't think a good test suite and extremely low cost devices (for example RFID chips) are very compatible concepts. One can test a source of randomness by checking statistics of its few samples, but if I understand the article correctly, in case of SRAM each cell behaves as an independent source of randomness: some bits are almost always stuck at fixed values while others have some freedom. In this case it is pointless to do tests using initial SRAM state after a single power on, because to gather a few samples from each source one needs to repeatedly reset the device. Applying statistical tests to a hash of the whole SRAM does not make much sense either -- a good hash function will give statistically good results even if you give it a counter. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
I suspect there are two reasons for QKD to be still alive. First of all, the cost difference between quantum and normal approaches is so enormous that a lot of ignorant decision makers actually believe that they get something extra for this money. If you tell a lie big enough and keep repeating it, people will eventually come to believe it. The second reason is ``rollback'' (is it right term?): you pay $10 from your company funds to a QKD vendor, and they covertly give $5 back to you. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
On Mon, 25 Jun 2007, Hal Finney wrote: The idea of putting a TPM on a smart card or other removable device is even more questionable from this perspective. A TPM which communicates via an easily accessible and tamperable bus is almost useless for the security concepts behind the Trusted Computing Group architecture. Even if a TPM is soldered to the motherboard it does not mean that unsoldering is an esoteric art. There is a difference between what media hypes about TPM and what TCG technical documents say [1]: It is not expected that a TPM will be able to defeat sophisticated physical attacks. The exception might be if there were additional hardware to encrypt the bus, but that is not part of the standard spec. Encrypted bus requires encryption cores on both ends and key distribution resistant to MitM attacks. I suspect that if you system already has so many crypto blocks in it, it would be cheaper to implement TPM inside. So this would allow a removable TPM but it has to be logically bound to the motherboard via cryptography, presumably something like an encrypted bus. To logically bound TPM to the motherboard it is enough for BIOS `loader' that hashes the rest of the BIOS, to include unique ID of the motherboard into the hash. [1] https://www.trustedcomputinggroup.org/groups/tpm/TPM_1_2_Changes_final.pdf -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: luks disk encryption benchmarks
On Tue, 5 Jun 2007, Travis H. wrote: 1048576000 bytes (1.0 GB) copied, 3.08291 seconds, 340 MB/s [...] That seems to reflect that it isn't really going to disk. I'm surprised the controller has that much RAM on it, I guess it is not the controller, but the kernel. Encryption reduces bandwidth by about a factor of 2 with write-caching enabled. To be useful, benchmark should be similar to normal workload. Maybe you should try to compile a kernel, or install/remove some package. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: wrt Network Endpoint Assessment
Hi. On Wed, 20 Jun 2007 [EMAIL PROTECTED] wrote: Network Endpoint Assessment (NEA): Overview and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt [...] NEA technology may be used for several purposes. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. I wonder what stops a trojan to disable an antivirus, but screw the reporting system up so that it pretends that the antivirus is still active? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
On Fri, 22 Jun 2007, Peter Gutmann wrote: It's available as part of other products (e.g. nCipher do it for keying their HSMs), but I don't know of any product that just does... secret sharing. What would be the user interface for such an application? What would be the target audience? (I mean a real target audience, not some hypothesised scenario). http://monolith.sourceforge.net/: Monolith is a simple tool that takes two arbitrary binary files (called a Basis file and an Element file) and munges them together to produce a Mono binary file (with a .mono extension). Monolith can also reconstruct an Element file from a Basis file and a Mono file. So if one xors a Linux iso image and some movie, it is quite hard to claim that the result is copyright-protected. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Enterprise Right Management vs. Traditional Encryption Tools
On Fri, 11 May 2007, Jon Callas wrote: What about DRM/ERM that uses TPM? With TPM the content is pretty much tied to a machine (barring screen captures etc) Will ERM/DRM be ineffective even with the use of TPM? There are two different features of TPM: it can work as an embedded smartcard (to identify computer), and it can be used to vouch for integrity of booted software. The first feature does not add much to DRM, because the attacker has the computer. The second feature can be bypassed if OS or DRM software has exploitable bugs (or with relatively simple hardware techniques, but let someone build a bug-free DRM software first :-) ). If someone is so impolite that they'll put the TPM chip under a scanning electron microscope, they can probably just read the bits off. Actually there is no need for any TPM intrusive methods to bypass the second feature mentioned above (the first one does not need to be bypassed since attacker has the computer). Let us see how TPM works: after reset, CPU sends a sequence of messages that report hashes of the booted software; TPM changes its internal registers (PCRs -- platform configuration registers) as a result; CPU sends a key to be encrypted and a description of PCR values required to decrypt it; TPM returns encrypted blob (it stores PCR requirements inside the blob). Once the blob is saved outside, it can be used to make sure that only required software can access the key: after reset CPU reports hashes of booted software and TPM changes PCRs; CPU send a blob to be decrypted; TPM decrypts it, checks PCR requirements, and return the key stored inside. The crucial assumptions here are that (1) TPM cannot be reset independently of CPU; (2) CPU's boot ROM cannot be changed (note that in many cases the ROM used for boot is actually flash); (3) the bus between CPU and TPM cannot be tampered with. Now, to decrypt any blob there is no need to have a FIB (focused ion beam) or a scanning electron microscope, because the only thing an attacker needs is to break one of the above assumptions, for example, boot Linux, reset TPM by some hardware manipulation, write a program to send to TPM the needed set of PCR change requests, send the blob, get the decrypted key, and print it out. Note once again that TPM works exactly as expected, the only problem is that the assumptions do not hold. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: open source disk crypto update
On Thu, 26 Apr 2007, Simon Josefsson wrote: Are you afraid of attackers secretly changing your software (to monitor you?) while your computer is off? I believe this is a not completely unreasonable threat. Modifying files on the /boot partition to install a keylogger is not rocket science, and (more importantly) can be done remotely, if you gain unauthorized access to the machine. It is almost impossible to modify computer remotely once it is off. It is possible to destruct computer physically (or by EM pulse), it is possible to interact with computer remotely if `off' is actually some kind of stand-by with lamps off. But once you disconnect your computer from the power supply it should be immune from remote attackers. ``The truly secure system is one that is powered of, ... and even then I have my doubts.'' :-) In most cases once computer can be compromised remotely, it is already booted, and since disk encryption is transparent once the computer is booted, it cannot change how easy it is to install a root-kit remotely. If you boot from a trusted USB stick instead, and check the integrity of the hard disk, the attacker needs to modify BIOS in order to install the keylogger. This may be sufficient difficult to do on a large scale (there are many different ways to update BIOS software), so that the attacker goes away to try some other weakness instead. In this case you ensure integrity using a tamper resistant hardware (assuming you always carry your USB stick with you). By the way, a non-rewritable CD should be even better. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On Wed, 25 Apr 2007, Travis H. wrote: If the IV chained across continguous messages as in SSHv2 then you have a problem (see above). I don't fully understand what it means to have IVs chained across contiguous (?) messages, as in CBC mode each ciphertext block forms the IV of the block after it, effectively; basically an IV is just C_0 for some stream. The order of events is important. Consider a chosen plaintext attack: a secret message was sent other a CBC-encrypted channel. For example, it was a single block with padded yes or no and the encryption is x0||x1, where x0 is a random IV and x1 = E(x0 xor yes), the attacker can now submit their message to find the secret one. If the attacker knows that x1 is going to be used as the next IV, they can try to submit m = x0 xor yes xor x1 it will be encrypted as x2 = E(m xor x1) = E(x0 xor yes) = x1 so if x2 = x1 the attacker knows that yes was sent, otherwise it was no. If the new IV is randomly selected *after* the attacker has made his choice the attack is impossible. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On Wed, 25 Apr 2007, Hagai Bar-El wrote:
It seems as Aram uses a different IV for each message encrypted with
CBC. I am not sure I see a requirement for randomness here. As far
as I can tell, this IV can be a simple index number or something as
predictable, as long as it does not repeat within the same key
scope.
For CBC mode the IV should be random because it is added
directly to plaintext. For example, if one sends `010' with IV
`001' the result of the xor will be the same as if they
subsequently send `101' with IV `110' and thus an attacker will
be able to learn something about the plaintext. If the IV is
random then we expect a collision after 2^{n/2} messages, but if
IV has some structure (or if an attacker knows the next IV
before they insert their own plaintext to be encrypted) the
probability of collision may become too high.
For some other modes (e.g., CFB, OFB, or CTR) the IV only needs
to be fresh, since the IV is first processed by the cipher. But
even in this case it is a good idea to use random IVs to protect
against state roll-back attacks.
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: open source disk crypto update
On Wed, 25 Apr 2007, Travis H. wrote: Just recently I discovered Debian default installs now support encrypted root (/boot still needs to be decrypted). Presumably we are moving back the end of the attack surface; with encrypted root, one must attack /boot or the BIOS. What is the limit? The real question is what attacks you are talking about. For example, protecting confidentiality of /boot and /usr that contains software that everybody can find on millions of other computers makes little sense. (OK, your kernel configuration may be unique, but do you really consider it confidential?) Do you want encryption to ensure integrity of you software? (Of course, that would be contrary to common crypto wisdom.) Are you afraid of attackers secretly changing your software (to monitor you?) while your computer is off? If so, are you sure that there is no hardware keylogger in your keyboard and there is no camera inside a ceiling mounted smoke detector [1]? In any case, it is a good idea to always start with definition of the problem and then check if the solution really solves it. (For example, eve if the problem is that your computer is too fast, you cannot solve it with encryption :-) ) [1] http://www.tentacle.franken.de/papers/hiddencams.pdf -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intuitive cryptography that's also practical and secure.
On Tue, 30 Jan 2007, Leichter, Jerry wrote: This is a common misconception. The legal system does not rely on lawyers, judges, members of Congress, and so on understanding how technology or science works. It doesn't rely on them coming to accept the trustworthiness of the technology on any basis a technologist would consider reasonable. All it requires is that they accept the authority of experts in the subject area, and that those experts agree strongly enough that the mechanism is sound. Right, this is the theory, and in theory there is no difference between practice and theory, unfortunately, in practice it exists: http://www.norwichbulletin.com/apps/pbcs.dll/article?AID=/20070106/NEWS01/701060312/1002/NEWS17 Oct. 19, 2004, while substituting for a seventh-grade language class at Kelly Middle School, Amero claimed she could not control the graphic images appearing in an endless cycle on her computer. The pop-ups never went away, Amero testified. They were continuous. Computer expert W. Herbert Horner, testifying in Amero's defense, said he found spyware on the computer and an innocent hair styling Web site that led to this pornographic loop that was out of control. [Jury] convicted Amero, 40, of Windham of four counts of risk of injury to a minor, or impairing the morals of a child. She faces a sentence of up to 40 years in prison. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Private Key Generation from Passwords/phrases
On Sun, 28 Jan 2007, Steven M. Bellovin wrote: Beyond that, 60K doesn't make that much of a difference even with a traditional /etc/passwd file -- it's only an average factor of 15 reduction in the attacker's workload. While that's not trivial, it's also less than, say, a one-character increase in average password length. That said, the NetBSD HMAC-SHA1 password hash, where I had some input into the design, uses a 32-bit salt, because it's free. In many cases the real goal is not to find all (or many) passwords, but to find at least one, so one may concentrate on the most-oftenly used salt. (Of course, with 60K passwords there is almost for sure at least one password1 or Steven123 and thus the salts are irrelevant.) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis and implementation of LRW
On Tue, 23 Jan 2007, Peter Gutmann wrote: The IEEE P1619 standard group has dropped LRW mode. It has a vulnerability that that are collisions that will divulge the mixing key which will reduce the mode to ECB. Is there any more information on this anywhere? I haven't been able to find anything in the P1619 archives (or at least not under an obvious heading). Probably http://grouper.ieee.org/groups/1619/email/msg00962.html -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Sun, 3 Dec 2006, David Johnston wrote: Moreover, AES-256 is 20-ish percent slower than AES-128. Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much data. So when implemented in hardware, AES-256 is substantially faster. AES-256 means AES with 128-bit block and 256-bit key, so AES-256 encrypts the same amount of data as AES-128. As of hardware implementation, one can use several engines in parallel, although even a single one can be faster than needed, for example, with 280 MHz there are 2e7 blocks per second, that is 320 Mbyte per second. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Wed, 8 Nov 2006, Travis H. wrote: On Wed, Nov 08, 2006 at 05:58:41PM -0500, Leichter, Jerry wrote: Sorry, that doesn't make any sense. If your HWRNG leaks 64 bits, you might as well assume it leaks 256. When it comes to leaks of this sort, the only interesting numbers are 0 and all. I can cite numerous examples of such happening in real life. [...] Not having to rely on perfectly unpredictable numbers coming from your RNG is a valid design principle. Looks like you are doing a common mistake of using ``entropy source'' (or, probably, even``source of entropy input'') as output of your generator (see NIST SP 800-90 for details). With such attitude, the next step is to use identity mapping as a block cipher :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Tue, 7 Nov 2006, Peter Gutmann wrote: Saqib Ali [EMAIL PROTECTED] writes: I compile a lot of software on my laptop, and I *certainly notice* the difference between my office laptop (no encryption) and my travel laptop (with FDE). The laptops are exactly the same, with the same image loaded. The only difference is the FDE software that is installed on the travel laptop. That's because you're doing something that produces worst-case behaviour. The (obvious) solution is the standard don't do that, then. My main development machine builds to a RAM drive, and for some odd reason I don't notice any disk access latency at all. I am not sure that compilation is worst case for disk performance: once system compiled the first file, the compiler and most of .h files are in RAM and should not be fetched from disk. Note that RAM of modern computers is large enough to store all the source code of a project (except, maybe, openoffice.org). My guess is that slow compilation is a result of access time misconfiguration: if a filesystem has access time enabled, then each time a file is read, the file system updates access time on disk. A solution is to set noatime option on the filesystem used for compilation. A better approach is to mount tmpfs as /tmp, and build in /tmp (for openoffice.org compilation increase size and number of inodes with size and nr_inodes options). -- Regards, ASK P.S. Probably of interest for disk benchmarker: disk performance depends on which cylinders are used, so if one has two partitions (one near the center and another one near the outer edge of the disk) performance on these partitions can be different. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Wed, 1 Nov 2006, Saqib Ali wrote: Well for one thing, any software based FDE is extremely slow, doubles the file access times, and is a serious drain on the laptop battery. If a PC is used by an interactive user, it is irrelevant how much access time is increased, as far as the user cannot see a difference without a timer. Several times I have read that disk encryption is not noticeable. My own experience shows that I cannot notice any difference: emacs and pine respond immediately to every key-press if I use encrypted disk or not; firefox waits for data from network the same amount of time; mplayer does not drop frames with or without disk encryption; compilation of kernel takes some noticeable time with or without encryption, but I don't know how much exactly since I spend this time in some other program. I don't want to say that the difference is irrelevant for all uses, e.g., if one edits video with 2k resolution or hosts a busy database, they can see very real difference, but such use-cases are minority and they are not done on portable computers anyway. I guess many people here have tried full disk encryption for themselves, do you notice any difference in performance or not? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On Mon, 9 Oct 2006 kkursawe at esat.kuleuven.ac.be wrote: IIUC, TPM is pointless for disk crypto: if your laptop is stolen the attacker can reflash BIOS and bypass TPM. According to TCG Specification, the first part of the BIOS (called Core Root of Trust for Measurement) should be non-flashable; this part then checksums the rest of the BIOS, option ROMS etc. and reports those to the TPM. I don't know how this is done in devices currently sold, but at least it should not be trivial to reprogram that part of the BIOS. Even if BIOS is real ROM, but there are some inter-chip links between ROM, CPU, and TPM, it seems possible for an attacker with an iron and FPGAs to trick the TPM to reveal the secret. That is against highly-motivated attacker TPM does not give really more protection than truecrypt, but for a casual attacker (who is just curious what is on a stolen laptop) even truecrypt is enough. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On Mon, 9 Oct 2006, James A. Donald wrote: Well obviously I trust myself, and do not trust anyone else all that much, so if I am the user, what good is trusted computing? One use is that I can know that my operating system has not changed behind the scenes, perhaps by a rootkit, know that not only have I not changed the operating system, but no one else has changed the operating system. The argument that TPM can prevent trojans seems to imply that the trojans are installed by modification of raw storage while the OS is offline. Probably, this can be a case for malicious internet-cafes, but 99.9% of trojans on home PCs of normal people are installed when the OS is active (0.1% is for trojans installed by law enforcement). (Of course, an attacker with physical access can install physical trojans: hardware keylogger and camera.) Since a regular installation should not change ``reported OS hash,'' TPM will not be able to detect the difference. Am I missing something? Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On Fri, 6 Oct 2006, Erik Tews wrote: And the TPM knows that your BIOS has not lied about the checksum of grub how? The TPM does not know that the BIOS did not lie about the checksum of grub or any other bios component. What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) IIUC, TPM is pointless for disk crypto: if your laptop is stolen the attacker can reflash BIOS and bypass TPM. Moreover, TPM is actually bad for disk crypto: without it you lose your data only if your HDD dies, now you lose your data if your HDD dies *or* if you motherboard dies. If the user is not experienced in BIOS reflashing, they also lose their data if OS crashes and refuses to boot (not uncommon for some common OSes). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: interesting HMAC attack results
Forgery and Partial Key-Recovery Attacks on HMAC and NMAC Using Hash Collisions, by Scott Contini and Yiqun Lisa Yin (*) On Mon, 25 Sep 2006, Anton Stiglic wrote: Very interesting, I wonder how this integrates with the following paper http://citeseer.ist.psu.edu/bellare06new.html (**) According to Section 1.4 of (*), the new result on HMAC does not contradict the analysis in (**). That is the assumption used by Mihir Bellare do not hold for MD4, MD5, and SHA-1. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Did Hezbollah use SIGINT against Israel?
On Wed, 20 Sep 2006, Steven M. Bellovin wrote: http://www.newsday.com/news/printedition/stories/ny-wocode184896831sep18,0,7091966,print.story That isn't supposed to be possible these days... It is not clear that with modern technology interception is impossible, at least during Second Gulf War the reports about SIGINT against US were quite convincing: http://www.google.com/search?q=iraq+radio+intercept (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. My guess that at least some information was leaked due to cellular phones (the solders were routinely calling their families). Besides radio transmissions, the official said Hezbollah also monitored cell phone calls among Israeli troops. But cell phones are usually easier to intercept than military radio, and officials said Israeli forces were under strict orders not to divulge sensitive information over the phone. Even if one don't care what was said over the phone, a lot of information can be extracted from mere location of a phone (especially, if one knows the owner of each phone): Israeli officials said the base also had detailed maps of northern Israel, lists of Israeli patrols along the border and cell phone numbers for Israeli commanders. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Raw RSA
On Sun, 10 Sep 2006, James A. Donald wrote: Could you describe this attack in more detail. I do not see a scenario where it would be useful. Suppose that an attacker runs an activex control on the user's computer and the control is able to ask a smart card connected to the computer to perform raw RSA operations with user's private key. The goal of the attacker is to be able to sign some useful messages with the user's private key *after* the user disconnect his smart card. The attacker can encrypt a subset of numbers - those that encrypt to a B smooth number, but for this to be useful to him, he has to find a number in the subset set that corresponds to what he desires to encrypt, which looks like a very long brute force search. If the attacker needs to sign a message x, he needs to find a smooth number y = x + k n, where n is the RSA modulus and k is some arbitrary number. I forgot what was the algorithm to find such y (I am not even sure that it exists), IIRC, it was based on LLL. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Raw RSA
On Thu, 7 Sep 2006, Leichter, Jerry wrote: | If an attacker is given access to a raw RSA decryption oracle (the | oracle calculates c^d mod n for any c) is it possible to extract the | key (d)? If I hand you my public key, I have in effect handed you an oracle that will compute c^d mod n for any c. What you are asking is whether you can then extract my private key e - which is exactly what the security claims for RSA say you cannot do. (Note that I chose to call my public key d and by private key e - but since the two keys are completely equivalent in RSA, that's just naming.) I want to extract the exponent that is used by the oracle: this is the difference between the chosen-plaintext attack (it does not require an oracle, since it is a public key scheme) and the chosen-ciphertext attack (CCA1). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Raw RSA
Hi. If an attacker is given access to a raw RSA decryption oracle (the oracle calculates c^d mod n for any c) is it possible to extract the key (d)? It is known, that given such an oracle, the attacker can ask for decryption of all primes less than B, and then he will be able to sign PKCS-1 encoded messages if the representative number is B-smooth, but is there any way to actually recover d itself? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: compressing randomly-generated numbers
On Mon, 28 Aug 2006, Travis H. wrote: On 8/23/06, Alexander Klimov [EMAIL PROTECTED] wrote: A random bit stream should have two properties: no bias and no dependency between bits. If one has biased but independent bits he can use the von Neumann algorithm to remove the bias, but if there is a dependency no algorithm will be able to `strip' it. Interesting claim; Well, it not really a claim since there was no definition, here it is: A ``dependency stripping'' algorithm is a deterministic algorithm that gets a stream of unbiased (but not necessary independent bits) and produces a stream of several independent bits. what if I XOR it with a truly random stream, It is no a deterministic algorithm. or a computationally-pseudorandom stream, This requires a random key. Recall that the whole point was to extract random bits -- if we already have useful random bits we can simply output them and discard the input stream. or if I filter out every other bit? Consider ``x a x b x c x ...'', sampling every other bit throws away most of entropy. In general, there is no ``dependency stripping'' algorithm because an input x,x,x,..., where all x are the same (either all 0 or all 1), is possible. There is simply no enough entropy in the input to extract at least two bits. Interestingly, an additional requirement that the input stream has at least two bits of entropy does not change the situation: Consider the first two bits of the output. There are only four possibilities (00, 01, 10, and 11), so if the input is long enough then it is possible to find four different inputs that give the same bits, e.g., A(0001) = 00... A(0010) = 00... A(0100) = 00... A(1000) = 00... An input that contains 0001, 0010, 0100, and 1000 with the same probability has two bits of entropy, but it is always transformed by the algorithm into 00... and thus the first two bits are not independent. (Strictly speaking, if we recall a requirement that the input bits are unbiased we should also include into the set of inputs 1110, 1101, ..., but this does not change the result.) Seems like these would, if not eliminate the dependency, would weaken its effect. The last is equivalent to sampling at a slower rate. See above about ``sampling at a slower rate.'' -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Solving systems of multivariate polynomials modulo 2^32
On Mon, 14 Aug 2006, David Wagner wrote:
Here's an example. Suppose we have the equations:
x*y + z = 1
x^3 + y^2 * z = 1
x + y + z = 0
Step 1: Find all solutions modulo 2. This is easy: you just have to try
2^3 = 8 possible assignments and see which one satisfy the equations. In
this case, the only solution is x=0, y=1, z=1 (mod 2).
There is a small optimization: modulo 2, x^n = x and thus if ``the
degrees of the polynomials are high (say 32) and the number of terms
they have is also big (for example 833, 2825 and 4708)'' it is not
more difficult to solve than degree 3 (xyz) with up to 8 terms. In
particular, the example is equivalent modulo 2 to
x*y + z = 1
x + y*z = 1
x + y + z = 0
[[[ Btw, something is wrong in the example: the following program
N = 2
for x in range(N):
for y in range(N):
for z in range(N):
if (x*y+z)%N==1 and (x**3+y**2*z)%N==1 and (x+y+z)%N==0:
print x,y,z
outputs
0 1 1
1 0 1
1 1 0
and apparently 1,0,1 is indeed a solution mod 2:
1*0+1=1, 1+0*1=1, and 1+1+0=0
]]]
Trying all combinations is a reasonable strategy, but it is also
possible to use an iterative simplification (especially if there are,
say, 80 variables):
if y = 0 we get a linear system
z = 1
x = 1
x + z = 0
that is 1,0,1 is a solution
if y = 1 we get also a linear system
x + z = 1
x + z = 1
x + 1 + z = 0
that is 0,1,1 and 1,1,0 are also solutions.
Linearization (and relinearization) may also be an option.
Step 2: Find all solutions modulo 4. This is again easy: since we know
x=0 (mod 2), then the only two possibilities for x mod 4 are 0 or 2.
Likewise, there are only two possibilities for y mod 4 and z mod 4.
Trying all 2^3 = 8 possible assignments, we find that the only two
solutions are x=0, y=3, z=1 (mod 4) and x=2, y=1, z=1 (mod 4).
Once we solved the system modulo 2^k, doing so modulo 2^{k+1} is much
simpler than trying all possibilities for the next bit. A nice
property of multiplication is that it gives linear relation in the
non-zero bit-slice, that is if we know that
X = x 2^k + A
Y = y 2^k + B,
where A and B are known and k0, then modulo 2^{k+1} we have
X*Y = xy 2^{2k} + (Bx+Ay) 2^k + AB = (bx+ay) 2^k + AB,
where a and b are the least significant bits of A and B (A = 2A'+a).
Since A and B are known constants, the next bit of XY is a linear
function (bx + ay + AB/2^k) of the next unknown bits of X and Y.
For example, in our case once we have (0,1,1) we represent X=2x,
Y=2y+1, and Z=2z+1 and write
2x(2y + 1) + 1 = 1
(2x)^3 + (2y+1)^2(2z+1) = 1
2x+(2y+1)+(2z+1) = 0
remove everything divisible by 4
2x + 1 = 1
2z + 1 = 1
2x + 2y + 2z + 2 = 0
and divide each equation by 2 (this is possible becuase (0,1,1) was a
solution modulo 2)
x = 0
z = 0
x+y+z=1,
that is (x,y,z)=(0,1,0) and thus (X,Y,Z) = (0,3,1) modulo 4.
We see that this requires performing 32 of these steps. On average, we
expect about one feasible solution to remain possible after each step
(though this number may vary). Each step requires testing 8 possible
assignments, times the number of assignments from the prior step. Thus,
on the average case we can expect this to run very fast.
Btw, the matrix (and thus its rank) depends only on the LSB of the
current solution, thus for each solution modulo 2, there is either a
split on each new step (if the rank is not maximal and the system is
consistent on this step), or no splits at all (if it is maximal).
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
On Mon, 21 Aug 2006, Max A. wrote: Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html The text there looks to me rather obscure with a lot of unrelated stuff. The system works as follows: a random key K is used to encrypt all the data on the volume; the passphrase is used to encrypt the key K. This design allows to change the passphrase without reencrypting the whole drive (only K needs to be reencrypted). One well-known side-effect is that if one knows K he can decrypt the data. So, if an attaker knows the password and can read your volume image at some point at time, he can decrypt the volume even if you change the password (recall that you have not changed the key). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypto to defend chip IP: snake oil or good idea?
On Tue, 25 Jul 2006, Perry E. Metzger wrote: EE Times is carrying the following story: http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759 [...] I'd be interested in other people's thoughts on this. Can you use DRM to protect something worth not eight dollars but eight million? If I understand correctly, it is not similar to DRM, it is more like dongles used in some software http://en.wikipedia.org/wiki/Dongle, but intended to protect hardware instead of software. I guess it has the same problems as dongles: either you have to implement some major functionality on the dongle (and thus greatly complicate development), or you simply include something like ``dongle present?'' queries in several key points (and thus make it trivial to crack by anyone skilled in the art). Experience with the software dongles shows that this idea works in a limited number of cases, for example, it works if one wants to protect a game that has high value during its first month after the release (cracking a strong protection may take some time), but dongles are almost useless for protection of long-life programs (although it can be very hard to crack a protection if the dongle is not given to the cracker). I don't know what is easier to `fix': a software program given as a binary code or a hardware design given as a net-list, but you are absolutely right, it is very important to consider that software is routinely cracked by hobbyist, whereas hardware must withstand more organized efforts. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your secrets are safe with quasar encryption
On Wed, 29 Mar 2006, Sean McGrath wrote: He adds that the method does not require a large radio antenna or that the communicating parties be located in the same hemisphere, as radio signals can be broadcast over the internet at high speed. It sounds like encrypting $P$ by xoring it with random $K$ and sending both $P \Xor K$ and $K$ -- no very secure :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
square roots modulo a prime p
Hi.
I have checked several papers and software packages which implement
modular square root and it looks like there is no agreement about what
algorithm is the best except that everybody does the same for p=3(4).
Chapter 3 of HAC suggests special algorithms for p=3(4) and p=5(8); a
general algorithm (IIUC, Shanks-Tonelli algorithm) which has
complexity O(|p|^3 s), where s is such that t is odd in t 2^s = p-1;
and an algorithm based on polynomial modular exponentiation:
r = x^{(p+1)/2} mod (x^2 - bx + a)
where b^2-a is a quadratic non-residue modulo p for cases where s is
large.
Some standards, e.g., IEEE 1363-2000, X9-1.62, etc. use same approach
for 3(4) and 5(8) but propose an algorithm based on Lucas sequence in
general case.
Looks like GMP does not implement any algorithm.
Openssl uses Tonelli/Shanks algorithm (crypto/bn/bn_sqrt.c) checking
simple cases first.
Crypto++ (nbtheory.cpp) seems to do the same as openssl but does not
check 5(8).
NTL uses the smartest approach: it implements 3(4) and when for
s sqrt(|p|) it uses Tonelli/Shanks algorithm and for large s it uses
polynomial reduction.
So I wonder why no well-known programs implement what respectable
standards suggest? And the other way around: why standards suggest
what is not usually implemented?
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
On Wed, 11 Jan 2006, Ian G wrote:
Even though triple-DES is still considered to have avoided that
trap, its relatively small block size means you can now put the
entire decrypt table on a dvd (or somesuch, I forget the maths).
This would need 8 x 2^{64} bytes of storage which is approximately
2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
Probably, you are referring to the fact that during encryption of a
whole DVD, say, in CBC mode two blocks are likely to be the same
since there are an order of 2^{32} x 2^{32} pairs.
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG quality verification
On Thu, 22 Dec 2005, Philipp [iso-8859-1] G?hring wrote: I have been asked by to verify the quality of the random numbers which are used for certificate requests that are being sent to us, to make sure that they are good enough, and we don?t issue certificates for weak keys. Consider an implementation which uses x = time and when SHA1(hardcoded-string||x), SHA1(hardcoded-string||x+1), etc. as a starting point to search for primes. Unless you know what is the hardcoded-string you cannot tell that the random starting point was not that random: it is very important to realize that randomness is the property of the source and not of a string. BTW, note that what you can see in the certificate request for an RSA key is n and not p and q themselves. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: whoops (residues in a finite field)
On Mon, 19 Dec 2005, Travis H. wrote: He says no mpi/modular arithmetic libraries that he knows of use this technique I guess the main reason is that the environments where these libraries are supposed to be used are believed to be immune to the attacks these checks are trying to prevent: the faults attacks are not likely on a PC and especially hard to do remotely :-) OTOH, ICCs (aka. smartcards) are quite vulnerable and usually do employ the countermeasures. The idea is that if an attacker exploits a bug A fault attack does not exploit a bug, but, say, a power glitch or radiation. Exactly what you would do in that case, I'm not sure... It depends on what exactly you try to prevent: which information you want to hide. For example, if you calculate RSA signature (with CRT) on an ICC using dummy multiplications (to avoid side channel attacks) and checks correctness only in the end, the fact that no error occurs may suggests that the glitch was introduced during such a dummy operation and thus it does not matter what you do if you detect an error. OTOH if you check error on each arithmetic operation (including the dummy one) you can just stop -- this does not give an attacker any additional information since he might as well guess himself that the power glitch he applied would cause a fault. BTW, fault-based cryptanalysis is not limited to RSA with CRT (or public key in general): block ciphers can be also vulnerable. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How security could benefit from high volume spam
On Wed, 14 Dec 2005, Hadmut Danisch wrote: Maybe in near future the advantages of that noise produced by millions of bots will outweigh the disadvantages? First of all, even if you receive 1000 spams a day plus a message from your commander it does not give you much since the spams are from random sources and the only one who sends you messages every day is your headquarters. OTOH, you can still use, say, yahoo mail and the only trace left in your ISP is IP of mail.yahoo.com (of course, you should also use one-time-mail-boxes :-). Provided that almost nobody uses email on their home PCs (most IP black lists of spam fighters include ISP's users and thus it is hard to send email directly anyway) all this address logging seems pointless. For web-browsing you can use tor. BTW, it looks like I cannot use google thru tor anymore: the error message says that too many requests are received from my IP (they try to stop worms which use google to search for new victims). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Hacker attacks in US linked to Chinese military: researchers
On Mon, 12 Dec 2005, R. A. Hettinga wrote: --- begin forwarded text [...] These attacks come from someone with intense discipline. No other organization could do this if they were not a military organization, Paller said in a conference call to announced a new cybersecurity education program. In the attacks, Paller said, the perpetrators were in and out with no keystroke errors and left no fingerprints, and created a backdoor in less than 30 minutes. How can this be done by anyone other than a military organization? Sounds really convincing :-) Of course, only a military can type for 30 minutes without a single keystroke error. (I would rather guess that this was a script.) Left no fingerprints is even more revealing :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
On Mon, 12 Dec 2005, Travis H. wrote: In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). Probably you have misunderstood it: if you do it correctly (e.g., use some standard method like RSAES-OAEP or even RSAES-PKCS1-v1_5) you can send the same message to 3 (or whatever) separate users without any bad consequences. The problem appears if you use some non-standard method, e.g., plain RSA (c = m^e \pmod n). My question is, what is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? This is quite simple: get some respected standard (see, e.g., NIST http://csrc.nist.gov/CryptoToolkit/ or PKCS http://www.rsasecurity.com/rsalabs/node.asp?id=2124) and implement it exactly. Interoperability is a bonus :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA posts notice about faster, lighter crypto
On Sat, 10 Dec 2005, Anne Lynn Wheeler wrote: NSA posts notice about faster, lighter crypto http://www.fcw.com/article91669-12-09-05-Web This makes me wonder how news are created -- the NSA announcement made on 16 February 2005 becomes a news in December... BTW, we already discussed here Suite B a couple of months ago (see, e.g., NSA Suite B Cryptography thread started by Perry posted on Thu, 13 Oct 2005 21:41:50 -0400 (EDT)) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto wiki -- good idea, bad idea?
On Mon, 12 Dec 2005, Travis H. wrote: Seems like a lot of new folks (myself included) ask questions that have the following answer: Read the literature, no there's no one site, that would be too much effort, c. Would a wiki specifically for crypto distribute the burden enough to be useful? The problem is not the effort on the writer's side (it was actually done many times in the past), the problem is the effort on the reader's side and there is no hope to solve it unless direct to brain information downloading is invented :-) Or should we just stick to wikipedia? Is it doing a satisfactory job? You can decide it for youself: http://en.wikipedia.org/wiki/Portal:Cryptography -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gonzo cryptography; how would you improve existing cryptosystems?
On Thu, 17 Nov 2005, Jari Ruusu wrote: Unfortunately truecrypt is just another broken device crypto implementation that uses good ciphers in insecure way. Specially crafted static bit patterns are easily detectable through that kind of bad crypto. Looks like they have fixed it: version 4.1 (2005-11-25) supports tweakable narrow-block encryption (LRW). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Encryption using password-derived keys
On Tue, 29 Nov 2005, Jack Lloyd wrote: The basic scenario I'm looking at is encrypting some data using a password-derived key (using PBKDF2 with sane salt sizes and iteration counts). [...] My inclination is to use the PBKDF2 output as a key encryption key, rather than using it to directly key the cipher (with the key used for the cipher itself being created by a good PRNG). IMO this is too much complicated: just generate random salt with your PRNG and use PBKDF2(password, salt) as a session key. Since PBKDF2 is a (xor of) PRF outputs it is (pseudo-)random. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Haskell crypto
On Sat, 19 Nov 2005, Ian G wrote: Someone mailed me with this question, anyone know anything about Haskell? It is a *purely* functional programming language. http://www.haskell.org/aboutHaskell.html Original Message I just recently stepped into open source cryptography directly, rather than just as a user. I'm writing a SHA-2 library completely in Haskell, which I recently got a thing for in a bad way. Seems to me that nearly all of the message digest implementations out there are written in C/C++, or maybe Java or in hw as an ASIC, but I can't find any in a purely functional programming language, let alone in one that can have properties of programs proved. TTBOMK the main reason why people write low-level crypto in something other than C is for integration simplification (e.g., there is a lisp sha1 implementation in the emacs distribution): IMO it is pointless to write SHA in a language that ``can have properties of programs proved,'' because test vectors are good enough, and there is no real assurance that when you write the specification in a machine-readable form you do not make the same mistake as in your code. BTW, there is low-level crypto in Haskell as well: http://web.comlab.ox.ac.uk/oucl/work/ian.lynagh/sha1/haskell-sha1-0.1.0/ -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
On Fri, 11 Nov 2005, Joseph Ashwood wrote:
From: Charlie Kaufman [EMAIL PROTECTED]
I've heard but not confirmed a figure of one failure in 20 million. I've
never heard an estimate of the probability that two runs would fail to
detect the composite. It couldn't be better than one failure is 20 million
squared or worse than one in 80 million.
I can confirm that that number of completely wrong. I just implemented a
small Java program to test exactly that. Each number was vetted by a single
pass of Miller-Rabin (iterations = 1). With 512-bit numbers the first 52
random guesses that pass the first test resulted in 26 numbers that failed
to pass 128 iterations. I find it rather odd that this is exactly half, and
I also notice that of those that failed they almost all seem to have failed
at least half of them.
The general consensus is that for 500-bit numbers one needs only 6 MR
tests for 2^{-80} error probability [1]:
number of Miller-Rabin iterations for an error rate of less
than 2^-80 for random 'b'-bit input, b = 100 (taken from table
4.4 in the Handbook of Applied Cryptography [Menezes, van
Oorschot, Vanstone; CRC Press 1996]; original paper: Damgaard,
Landrock, Pomerance: Average case error estimates for the
strong probable prime test. -- Math. Comp. 61 (1993) 177-194)
#define BN_prime_checks(b) ((b) = 1300 ? 2 : \
(b) = 850 ? 3 : \
(b) = 650 ? 4 : \
(b) = 550 ? 5 : \
(b) = 450 ? 6 : \
(b) = 400 ? 7 : \
(b) = 350 ? 8 : \
(b) = 300 ? 9 : \
(b) = 250 ? 12 : \
(b) = 200 ? 15 : \
(b) = 150 ? 18 : \
/* b = 100 */ 27)
and thus a single test gives ~2^{-13}.
[1] http://cvs.openssl.org/getfile/openssl/crypto/bn/bn.h?v=1.21
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
On Wed, 9 Nov 2005, Jeremiah Rogers wrote:
I guess the small increase in efficiency would not be worth additional
program code.
That depends on the size of the numbers you're working with...
Considering the research that goes into fast implementations of
PowerMod I don't think the required computation is trivial.
For large n the ratio s to log n is small (where n-1 = d 2^s) and s is
exactly the number of multiplication you may hope to avoid.
But MR will still fail when given a Carmichael number,
since elsewhere MR is defined as iterated application of the Fermat
test.
It is very easy to check.
561 is a Carmicael number (the smallest one), for example, for a = 2
2^560 = 1 (561) and the same for all a's coprime to 561.
Btw, 651 = 3*11*17, so don't try with a = 3 :-)
Let us now go to the RM test: 560 = 35 * 2^4 (d = 35 and s = 4), so,
e.g., for a = 2, 2^35 = 263 (that is a^d \ne 1) and
263^2 = 166, 166^2 = 67, 67^2 = 1 (that is a^{2^r d} \ne -1 \forall r
\in [0, s-1]), so RM test declares that 561 is composite and 2 is a
strong witness of this.
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Pseudorandom Number Generator in Ansi X9.17
On Thu, 10 Nov 2005, Terence Joseph wrote: The Pseudorandom Number Generator specified in Ansi X9.17 used to be one of the best PRNGs available if I am correct. I was just wondering if this is still considered to be the case? Is it widely used in practical situations or is there some better implementation available? What would be the advantages/disadvantages of modifying the Ansi X9.17 PRNG to use AES instead of 3DES? Is this feasible at all? It is now called ANSI X9.31 Appendix A.2.4 http://csrc.nist.gov/CryptoToolkit/tkrng.html and yes, there is NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms http://csrc.nist.gov/cryptval/rng/931rngext.pdf Btw, anybody was lucky enough to cache the draft of X9.82 which was posted on the NIST site some time ago? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gonzo cryptography; how would you improve existing cryptosystems?
On Mon, 7 Nov 2005, Jason Holt wrote: Take a look at ecryptfs before rewriting cfs ... or at TrueCrypt (which works on linux and windows): http://www.truecrypt.org/downloads.php -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Wed, 26 Oct 2005, JЖrn Schmidt wrote: --- Travis H. [EMAIL PROTECTED] wrote: [snip] Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful. You can already do the latter with SwitchProxy (http://www.roundtwo.com/product/switchproxy). Basically, it's a Firefox extension that saves you the trouble of going into the 'preferences' dialogue everytime you want to switch from one proxy to another (or go from using a proxy to not using one, that is). In fact, it is possible to setup it all thru privoxy alone: # 5. FORWARDING # = # # This feature allows routing of HTTP requests through a chain # of multiple proxies. It can be used to better protect privacy # and confidentiality when accessing specific domains by routing # requests to those domains through an anonymous public proxy (see # e.g. http://www.multiproxy.org/anon_list.htm) Or to use a caching # proxy to speed up browsing. Or chaining to a parent proxy may be # necessary because the machine that Privoxy runs on has no direct # Internet access. # # Also specified here are SOCKS proxies. Privoxy supports the SOCKS # 4 and SOCKS 4A protocols. [...] # 5.1. forward # # # Specifies: # # To which parent HTTP proxy specific requests should be routed. # # Type of value: # # target_pattern http_parent[:port] # # where target_pattern is a URL pattern that specifies to which # requests (i.e. URLs) this forward rule shall apply. Use / # to denote all URLs. http_parent[:port] is the DNS name or # IP address of the parent HTTP proxy through which the requests # should be forwarded, optionally followed by its listening port # (default: 8080). Use a single dot (.) to denote no forwarding. Btw, I guess everybody who installs tor with privoxy has to know about this since he has to change this section. The problem is that it is not clear how to protect against `malicious' sites: if you separate fast and tor-enabled sites by the site's name, e.g., tor for search.yahoo.com, and no proxy for everything else, yahoo can trace you thru images served from .yimg.com; OTOH if you change proxy `with one click' first of all you can easily forget to do it, but also a site can create a time-bomb -- a javascript (or just http/html refresh) which waits some time in background (presumably, until you switch tor off) and makes another request which allows to find out your real ip. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
On Sun, 11 Sep 2005, Alexander Klimov wrote:
Does anyone know a good survey about ECC patent situation?
I have made a shallow review (comments are welcome!) of the
patents that Certicom claims are pertained to ECC implementation
and it looks like there are no real road-blocks for ECDH and
ECDSA among them. In other words, IIUC it is possible to
implement EC encryption and signing without violating any patent
(of course, the implementer must be lucky enough to avoid any
patented optimization).
BTW, it looks like OpenSSL developers share this POV: README [1]
on branch OpenSSL_0_9_8-stable which implements ECDH and ECDSA
has PATENTS section which does not say a word about ECC.
In order to make this review I located two documents [2,3] in
which Certicom lists its patents related to ECC. It is
impossible to say that nobody else has patents in this area, but
the fact that the web site of SECG [4] (which is the first
working group anywhere that is devoted exclusively to developing
standards based on ECC) does not have claims by anybody else
can be viewed as a hint of this.
Let us now review these lists. The first of them [2] contains
the following patents:
[As of May 26, 1999] Certicom is the owner of the following
issued patents:
US 4,745,568 Computational method and apparatus for finite
field multiplication, issued May 17, 1988. This patent
includes methods for efficient implementation of finite field
arithmetic using a normal basis representation.
[Optimization of multiplication in GF_{2^n}]
US 5,787,028: Multiple Bit Multiplier, issued July 28, 1998.
[Multiplication in GF_{2^{nm}}, IIUC it is of no use now due to
Weil descent attack for EC(GF_{2^k}) with composite k.]
US 5,761,305 Key Agreement and Transport Protocol with
Implicit Signatures, issued June 2, 1998. This patent includes
versions of the MQV protocols.
US 5,889,865 Key Agreement and Transport Protocol with
Implicit Signatures, issued March 30, 1999. This patent
includes versions of the MQV protocols.
US 5,896,455 Key Agreement and Transport Protocol with
Implicit Signatures, issued April 20, 1999. This patent
includes versions of the MQV protocols.
[These three are about MQV protocol and so are unrelated to ECDH
and ECDSA.]
Certicom has the exclusive North American license rights to
the following issued patent:
US 5,600,725 Digital signature method and key agreement
method, issued Feb. 4, 1997. This patent includes the
Nyberg-Rueppel (NR) signature method.
[Described as pertains to PV signatures below.]
Certicom has patent applications that include the following:
* Methods for efficient implementation of elliptic curve
includes efficient methods for computing inverses.
* Methods for point compression.
* Methods to improve performance of private key operations.
* Various versions of the MQV key agreement protocols.
* Methods to avoid the small subgroup attack.
* Methods to improve performance of elliptic curve
arithmetic; in particular, fast efficient multiplication
techniques.
* Methods to improve performance of finite field
multiplication.
* Methods for efficient implementation of arithmetic modulo n.
* Methods to perform validation of elliptic curve public keys.
* Methods to perform efficient basis conversion.
The second [3] of the lists contains the following:
[As of February 10, 2005] Certicom is the owner of the
following issued patents:
EP 0 739 105 B1 (validated in DE, FR, and the UK) Method for
signature and session key generation pertains to the MQV
protocol
[Anybody knows, where it is available online?]
US 5,761,305 Key Agreement and Transport Protocols with
Implicit Signatures pertains to the MQV protocol
US 5,889,865 Key Agreement and Transport Protocol with
Implicit Signatures pertains to the MQV protocol
US 5,896,455 Key Agreement and Transport Protocol with
Implicit Signatures pertains to the MQV protocol
US 6,122,736 Key agreement and transport protocol with
implicit signatures pertains to the MQV protocol
US 6,785,813 Key agreement and transport protocol with
implicit signatures pertains to the MQV protocol
[Menezes-Qu-Vanstone (MQV) protocol -- an authenticated protocol
for key agreement based on the Diffie-Hellman scheme.]
US 5,600,725 Digital Signature Method and Key Agreement
Method pertains to PV signatures
[Pintsov-Vanstone (PV) signatures -- a scheme with partial
message recovery.]
US 5,933,504 Strengthened public key protocol pertains to
preventing the small-subgroup attack
[This one contains the following claims:
1. A method of determining the integrity of a message
exchanged between a pair of correspondents, said message
being secured by embodying said message in a function of
.alpha..sup.x where .alpha. is an element of a finite
group S of order q, said method comprising the steps of
at least one
Re: Pseudonymity for tor: nym-0.1 (fwd)
On Sun, 2 Oct 2005, Matt Crawford wrote:
On Sep 29, 2005, at 18:32, Jason Holt wrote:
Of course, you can put anything you want in the cert, since the
servers know that my CA only certifies 1 bit of data about users
(namely, that they only get one cert per scarce resource).
One per person is a tough thing to do purely over the internet. IP
addresses get NATted or reassigned dynamically. Email addresses are
free in infinite quantity. Any system that levels penalties on nyms
for bad actions is playing whack-a-mole. A system in which nyms
accumulate {fame, credit, privilege} for good actions still has a
hope ... as long as those credits can't be granted by an army of
extra nyms of the same person.
Since the problem we are trying to solve is to prevent '''automated''' [1]
vandalism, I guess the only solution is to use some Turing-test
system, for example, recognition of the number on an image. In fact,
this test only needed on the user registration form and for edit by
non-registered user.
The problem with any other more complex system (even if it works) is
that it prevents new users from becoming editors and thus it is
counterproductive.
[1] I guess, that non-automated vandalism is not a big problem since
the number of watchers is higher than the number of vandals (otherwise,
something is wrong with the system :-) and reverting to the previous
content is not time-consuming.
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
On Tue, 13 Sep 2005, Paul Hoffman wrote: At 9:32 AM -0700 9/12/05, James A. Donald wrote: It has been a long time, and no one has paid out money on an ECC patent yet. That's pretty bold statement that folks at Certicom might disagree with, even before http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld1.htm. http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld9.htm: What is Really Covered o The use of elliptic curves defined over GF(p) where p is a prime number greater than 2^255 when the product satisfies the Field of Use conditions o Both compressed and uncompressed point implementations o Use of elliptic curve MQV and ECDSA under the above conditions This hints that indeed only some particular curves are patented. Grepping -list_curves of the new openssl (0.9.8) which has a list of curves from SECG, WTLS, NIST, and X9.62 gives not that much: secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field Alternatively, this coverage can be interpreted that NSA is not interested in curves which provide less security than 128-bit AES. Any idea, which alternative is true? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is there any future for smartcards?
On Mon, 12 Sep 2005, Jaap-Henk Hoepman wrote: I believe smartcards (and trusted computing platforms too, btw) aim to solve the following problem: How to enforce your own security policy in a hostile environment, not under your own physical control? Examples: - Smartcard: electronic purse: you cannot increase the amount on your e-purse (unless reloading at the bank). - Trusted computing: DRM: my content cannot be illegally copied on your machine. As soon as the environment is under your won physical control, software only solutions suffice. Well, SC is just a processor which runs some software. Unfortunately, in our non-perfect world a person can physically control his own computer which is (logically) 0wned by somebody else :-) Of course, a smart card inserted into compromised card accepting device can be (mis)used by the 0wner as well, but at least the owner can be sure that once she removes the card no new transaction can be authenticated. BTW, there is also `something-you-have' authentication use-case. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
On Sun, 11 Sep 2005, Ben Laurie wrote: Alexander Klimov wrote: ECC is known since 1985 but seems to be absent in popular free software packages, e.g., neither gnupg nor openssl has it (even if the relevant patches were created). It looks like the main reason is some patent uncertainty in this area. I don't, but it is not the case that OpenSSL does not include ECC. You are absolutely right the Sun patch was finally accepted, although there were some patent-related discussions, e.g., at http://lists.debian.org/debian-legal/2002/10/msg00100.html There is also work on ECC for gnupg http://www.g10code.de/tasklist.html#gcrypt-ecc and again there were patent-related discussions about the issue. ECC is also implemented in crypto++ and other libraries. But (potential) problem still persists: even if openssl implements ECC it does not save you from patent issues if they exist. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ECC patents?
Hi. ECC is known since 1985 but seems to be absent in popular free software packages, e.g., neither gnupg nor openssl has it (even if the relevant patches were created). It looks like the main reason is some patent uncertainty in this area. An internet research shows that Certicom claims to hold quite a few patents in the area. Some people claims that it is still possible to implement ECC without violating any patent, because neither ECC in general, nor ECDH, nor ECElGamal are patented. Yet another POV is that although algorithms themselves are not patented the curves (especially whose standardized by NIST) are patented (probably, only for GF(p) and GF(2^n)-based curves are not). Does anyone know a good survey about ECC patent situation? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How many wrongs do you need to make a right?
On Wed, 17 Aug 2005, Florian Weimer wrote: Can't you strip the certificates which have expired from the CRL? (I know that with OpenPGP, you can't, but that's a different story.) Probably, you want to save the signatures on the old lists, but I dont see why you can not download only delta of the new revoked certificates each day (e.g., using rsync). that CRL leaks sensitive information. At least from a privacy point of view, this is a big, big problem, especially if you include some indication which allows you to judge the validity of old signatures. Apparently it is just usual serial number: ``the military also has revoked 10 million ... which has bloated to over 50M bytes in file size,'' that is just 5 bytes for each entry. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Query about hash function capability
On Thu, 4 Aug 2005, Arash Partow wrote: My question relates to hash functions in general and not specifically cryptographic hashes. I was wondering if there exists a group of hash function(s) that will return an identical result for sequentially similar yet rotate/shift wise dissimilar input: ie: input1 : abcdefg - h(abcdefg) = 123 input2 : gabcdef - h(gabcdef) = 123 input3 : fgabcde - h(fgabcde) = 123 Here a,b,c,d,e,f,g represent symbols (ie: groups of bits with equivalent group sizes etc...) I know that one simple hash method would be to add the symbols together, but the results would also be equivalent if say the symbols were in any order, also collisions would occur with other totally dissimilar sequences that happen to have the same sum as the sequence. Is there anything out there research/papers etc, or is this a meaningless avenue of enquiry? Just sort all the rotations and use some known hash for the smallest. For example, if you start with abcab you sort abcab, babca, ababc, cabab, and bcaba, and calculate SHA1(ababc). BTW: this rotate-and-sort technique is actually used for data compression -- search for `Burrows-Wheeler Transform' if you are interested. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ostiary
On Tue, 2 Aug 2005, Udhay Shankar N wrote: Sounds interesting. Has anybody used this, and are there any comments? For similar purpose I used to use .qmail based system: the script started from .qmail when a message to some special address arrives, the script checks the digital signature on the message, compare the first line with stored counter (to avoid replay attacks) and executes the needed command. The positive side of this technique is that it is very simple (just few lines to code), does not need to open a port (and so it is firewall-friendly, no need to talk with sysadmins, ...), very unlikely to introduce security holes (qmail has quite good records, and in my case the mail was needed anyway). -- Regards, ASK P.S. If the moderator is troubled with spam let us agree on some special word in subject so that he can automatically reject the messages which do not have it. [Moderator's note: blocking messages from non-subscribers has been 100% effective already. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
On Wed, 13 Jul 2005, Perry E. Metzger wrote: Why is it, then, that banks are not taking digital photographs of customers when they open their accounts so that the manager's computer can pop up a picture for him, which the bank has had in possession the entire time and which I could not have forged? While we are very good at recognizing somebody we know on a picture, it is in fact very hard to answer the following question: is the person in front of you is the same person who is depicted on the photo? AFAIR there were experiments which show that if you just get a random photo of a person with the same race, age, and gender as you have you have very good probability to successfully pretend that you are the person on the picture. As a result the criminal don't really need to change the photo to be able to pretend that he is you. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
