Re: RSA question
On Tue, Aug 31, 2010 at 11:27:39PM -0700, Bill Stewart wrote: > It's possible that > under some conditions, trying to brute-force the RSA is more efficient > than simply brute-forcing the symmetric key As of 2003, RSA said: 1024 bit RSA ~= 80 bit symmetric 2048 bit RSA ~= 112 bit symmetric 3072 bit RSA ~= 128 bit symmetric So PK is usually weaker than the symmetric part of a hybrid scheme. I hear that NIST Key Mgmt guideline (SP 800-57) suggests that the RSA key size equivalent to a 256 bit symmetric key is roughly 15360 bits. I haven't actually checked this reference, so I don't know how they got such a big number; caveat emptor. I have no idea what the state of, say, AES brute forcing is, so I don't know the ratio from AES key size to ideal symmetric cipher key sizes. I'm guessing it's pretty close to 1, but would love to hear if it's not. -- It asked me for my race, so I wrote in "human". -- The Beastie Boys My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgp16o2aSPNwM.pgp Description: PGP signature
Re: questions about RNGs and FIPS 140
On Thu, Aug 26, 2010 at 06:24:26PM +0300, Alexander Klimov wrote: > I guess you misinterpret it. In no place 140-2 "does not allow > TRNG". On closer reading, I guess that's true. Annex C, "Approved Random Number Generators", claims that no TRNGs have been approved, but that's not the same as saying that they are specifically excluded. -- It asked me for my race, so I wrote in "human". -- The Beastie Boys My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpXrWix15I6f.pgp Description: PGP signature
Re: questions about RNGs and FIPS 140
On Thu, Aug 26, 2010 at 06:25:55AM -0400, Jerry Leichter wrote:
> [F]IPS doesn't tell you how to *seed* your deterministic generator. In
> effect, a FIPS-compliant generator has the property that if you start it
> with an unpredictable seed, it will produce unpredictable values.
That brings up an interesting question... if you have a source of
unpredictable values in the first place, why use a CSPRNG? ;-)
Actually, I know I'm being snarky; I'm aware that they're handy for
"stretching" your random bits, if you don't have enough for the task.
I suppose some people feel they're also handy for whitening them, so
that if they're not entirely random, the structure isn't completely
obvious from the output alone, but I think that's probably a separate
property that needs to be evaluated independent of the others.
Last I checked Linux /dev/{u,}random uses SHA-1 hash over the pool,
which suggests they had this in mind. However, it also makes using it
very slow for wiping disks or any other high-bandwidth tasks, at least
when compared to something like Yarrow.
I heard from a colleague that /dev/urandom exists on Android, but
/dev/random does not. Our best guess is that it's the same as the
standard Linux /dev/urandom, but we're not really sure. Presumably
they dumped /dev/random because there just weren't enough sources of
unpredicability on that platform. I'd like to hear from anyone who
knows details.
Also, please do check out the links about RNGs on the aformentioned
page. Seth Hardy's /dev/erandom looks very interesting, and has
languished in relative obscurity for nearly a decade.
I'll take the rest of my comments to this list:
http://lists.bitrot.info/mailman/listinfo/rng
--
It asked me for my race, so I wrote in "human". -- The Beastie Boys
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/
If you are a spammer, please email j...@subspacefield.org to get blacklisted.
pgp9yzKJ9OT7R.pgp
Description: PGP signature
questions about RNGs and FIPS 140
Hey all,
Looking for feedback on this section on RNGs:
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc29
Equations are broken in HTML, but clear in PDF:
http://www.subspacefield.org/security/security_concepts/security_concepts.pdf
I am aware the Renyi entropy link is broken.
I also wanted to double-check these answers before I included them:
1) Is Linux /dev/{u,}random FIPS 140 certified?
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.
2) Is CryptGenRandom certified?
Yes - is that because they have a deterministic mode? Wikipeda makes it sound
like this closed-design system seeds from system timings and other stuff, which
would seem to make it non-deterministic as far as FIPS 140 testing is concerned.
3) Is determinism a good idea?
See Debian OpenSSL fiasco. I have heard Nevada gaming commission
regulations require non-determinism for obvious reasons.
4) What about VMs?
Rolling back a deterministic RNG on those systems gives the same
values unless/until you re-seed with something new to this iteration.
Do those sound right?
--
It asked me for my race, so I wrote in "human". -- The Beastie Boys
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/
If you are a spammer, please email j...@subspacefield.org to get blacklisted.
pgp3mbtjlj8Kf.pgp
Description: PGP signature
phpwn: PHP cookie PRNG flawed (Netscape redux)
https://media.blackhat.com/bh-us-10/whitepapers/Kamkar/BlackHat-USA-2010-Kamkar-How-I-Met-Your-Girlfriend-wp.pdf Hey, another PRNG is broken. Raise your hand if you're surprised. -- A Weapon of Mass Construction My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpXw4d3k1gaP.pgp Description: PGP signature
work factor calculation for brute-forcing crypto
Hi folks, Assume for a moment that we have a random number generator which is non-uniform, and we are using it to generate a key. What I'd like to do is characterize the work factor involved in brute-force search of the key space, assuming that the adversary has knowledge of the characteristics of the random number generator? The algorithm for this is simple: Let the array X represent the probabilities of the outcomes of the random number generator, sorted by probability, with x[0] being the probability of the most probable value. Then, for a given fraction of the messages n (0 < n <= 1): i = 0 m = 0 while (m + x[i]) < n: m = m + x[i] i = i + 1 return (i - 1) + (n - m) / (m + x[i]) This return value represents the average number of decryption attempts required to guess the right key. If one wanted to round up, one could just return i instead of the last expression above, because the second term is always in (0, 1] I'm curious if there's a way to express this calculation as a mathematical formula, rather than an algorithm, but right now I'm just blanking on how I could do it. -- Obama Nation | My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpJ4gqi6vQJo.pgp Description: PGP signature
Re: Intercepting Microsoft wireless keyboard communications
On Tue, Dec 11, 2007 at 02:01:03PM -0500, j...@tla.org wrote: > How many bits (not just data, also preamble/postamble, sync bits, etc.) > is the keyboard sending for each keystroke anyway? FWIW, it is likely sending keyboard scan codes: http://en.wikipedia.org/wiki/Scancode It doesn't send the actual characters typed, because games and the like need to know when keys are depressed and released, not just what letter was typed. Here's an overview of keyboard input under Linux: http://www.subspacefield.org/~travis/keyboard/index.html -- Obama Nation | My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpePeM4q7uNa.pgp Description: PGP signature
padding attack vs. PKCS7
http://www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/ Towards the end of this rather offbeat blog post they describe a rather clever attack which is possible when the application provides error messages (i.e. is an error oracle) for PKCS7 padding in e.g. AES CBC-encrypted web authenticators that allows an adversary to attack the crypto one octet at a time. -- Obama Nation | My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgptls3HY1oR9.pgp Description: PGP signature
Re: Seagate announces hardware FDE for laptop and desktop machines
Reading really old email, but have new information to add. On Wed, Oct 03, 2007 at 02:15:38PM +1000, Daniel Carosone wrote: > Speculation: the drive always encrypts the platters with a (fixed) AES > key, obviating the need to track which sectors are encrypted or > not. Setting the drive password simply changes the key-handling. > > Implication: fixed keys may be known and data recoverable from factory > records, e.g. for law enforcement, even if this is not provided as an > end-user service. There was an interesting article in 2600 recently about ATA drive security. It's in Volume 26, Number 1 (Spring 2009). Sorry that I don't have an electronic copy. The relevant bit of it is that there are two keys. One key is for the user, and one (IIRC, it is called a master key) is set by the factory. IIRC, there was a court case recently where law enforcement was able to read the contents of a locked disk, contrary to the vendor's claims that nobody, even them, would be able to do so. The man in question had his drives sized by the FBI and they read the drives, uncovering emails between the man and his lawyer. He was suing the manufacturer for false advertising. Here are the links from the 2600 article: http://tinyurl.com/atapwd http://tinyurl.com/cmrrse http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml hdparm -security-erase-enhanced in Linux http://www.deadondemand.com/ http://www.vogon-investigation.com/password-cracker.htm -- Obama Nation | My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpvh6qewOZcV.pgp Description: PGP signature
CSPRNG algorithms
I have never seen a good catalog of computationally-strong pseudo-random number generators. It seems that everyone tries to roll their own in whatever application they are using, and I bet there's a lot of waste and inefficiency and re-inventing the wheel involved. If this true, or is there a survey somewhere? If not, would people like to help me create one by emailing me references to extant PRNG definitions? -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
X.509 certificate overview + status
Hello, Recently I set up certificates for my server's SSL, SMTP, IMAP, XMPP, and OpenVPN services. Actually, I created my own CA for some of the certificates, and in other cases I used self-signed. It took me substantially more time than I had anticipated, and I'm left with feelings of unease. It seems the way to do this revolves around openssl, but while I was able to find instructions*, they were cookbook-style, and didn't really give me as complete an understanding as I had hoped. [*] http://sial.org/howto/openssl/ I experimented with tinyca2, which appears only to create certificates with passphrases, which is obnoxious. Only some applications (e.g. dovecot) allow you to specify passphrases, and in most cases the config file with the passphrase is protected the same way as the key itself, using filesystem permissions, making it pointless. However, I still have problems with dovecot. Whenever I connect to IMAPS, it complains that the certificate is for '' (empty string), and I'm not sure what I did wrong in the certificate creation. In other cases, such as openvpn, there are some scripts there (easy-rsa) which take care of it for you. I couldn't, in particular, find comprehensive information on the openssl.cnf file, particularly the v3 extensions. In some cases, such as OpenBSD's isakmpd, I had to abandon my plans completely because they had requirements that the certificates have some fields (subjectAltName, I think) that weren't well documented. I can't remember exactly if I couldn't create this field, or merely didn't know what to put in it. However, in this case, the main problem I found was that the Linux port of isakmpd was not reliable, and nearly impossible to debug. It just would work 50% of the time, and not the other 50%. OpenBSD's isakmpd is pretty sexy - it detects NAT traversal and automagically encapsulates in UDP - but apart from the Linux reliability issue, I also had issues with multiple tunnels going through the same NAT/fw box that was itself running IPSec. Whereas by contrast, OpenVPN handles that situation well, and has support for MS-Windows should I ever want it. Further, trying to dig into ASN.1 was extremely difficult. The specs are full of obtuse language, using terms like "object" without defining them first. Are there any tools that will dump certificates in human-readable formats? I would really like something that could take a PEM file of a cert and display it in XML or something of the sort. Although I have it all working, I am considering redoing all the work, hopefully all under one CA cert that I control. But I'm not sure if that's wise. I'm plowing through the O'Reilly OpenSSL book, but are there other resources out there that could help me, or others like me? -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: peer review of presentation requested
On Tue, Feb 24, 2009 at 03:06:21PM -0500, Perry E. Metzger wrote: > If you expect to be presenting things at that level of detail to > developers, you're going to lose. Agreed on this end. However, these are web security people, not mere web developers. They are very sharp on complicated issues like web security, and just today one of them was joking about how one web developer thought that hidden fields in forms are immutable. > There is no chance that they'll > absorb the details, and they'll get entirely the wrong message, which > is that they should be making decisions on such things instead of just > using prepackaged protocols. Hmm, interesting thought. I was hoping to present the multiple failures (by smart people) as a way to convince them of the need to use existing algorithms rather than try to design their own. This actually touches on something I've noticed. With a locally-executing application, the operating system provides abstractions like user IDs and file permissions that an application developer gets "for free", and by and large they are making effective use of them. However, in the web application or web services world, nearly everyone* is doing things like user account management from scratch, and they're making the same sort of mistakes over and over again. [*] There are possible exceptions in web application frameworks like Zope. Some of these systems may already provide security features and abstractions that can be used by web developers. > The single most important lesson in cryptography is that cryptography > and cryptographic protocols are insanely hard to get right. Strong agreement. > The > average PHP hacker is not in a position to spend enough time to learn > the field well enough -- he's busy getting his application > working. Much better to avoid the entire issue. I'm not so sure; it seems that, for better or worse, web developers are doing these things, and they're doing them wrong. Hopefully this presentation will deliver two messages; one, that cryptography and cryptographic protocols are insanely hard to get right, and two, that they should use some relatively standard mechanisms for implementing their crypto, like AES256-CBC (for confidentiality) and SHA-2-HMAC (for integrity protection). But I suppose it could backfire, if people came away with the notion that _now_ they are educated enough on crypto to make informed decisions about new combinations. Maybe I should make a point of telling them that this is not the case. -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
peer review of presentation requested
Hello all, I'm working on a presentation about cryptography to give to the Open Web Application Security Project (OWASP). The reason why I'm giving it is that I've seen web developers doing crypto a lot lately, and they seem to be making some naive mistakes, like using ECB mode for multi-block structures, using encryption when they should be using MACs, and that kind of stuff. I had originally intended to make the entire presentation on web security failures, but found it time-consuming to locate information about web-specific vulnerabilities... they just aren't documented well because they're usually in the application layer for a single company, and so generally not shared widely. So, I've thrown in some non-web examples of application developers trying to invent their own crypto and getting it wrong (LANMAN hashes, for example). Anyway, I'd like some cryptographers to review my presentation to make sure that I am giving solid advice. http://www.subspacefield.org/security/web_20_crypto.pdf In addition, I'm curious about: Which hashes are currently vulnerable to length-extension attacks. If I recall Bruce Schneier's book "Practical Cryptography" correctly, he stated that even SHA-1 was vulnerable. Do any hashes in the SHA-2 family have protection against length extension? Is it sufficient to have a one-way finalization function in your Merkle-Damgaard hash construction to prevent length extension attacks? -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
preparing a web 2.0 crypto talk
Hi, I've been working on a presenation for the local OWASP chapter, and here it is: http://www.subspacefield.org/security/web_20_crypto.pdf I'd like suggestions on how to stretch this talk out a bit. I would particularly like good examples of real web apps that have done crypto wrong - and how. Unfortunately, I found this talk, Cryptography for Pen Testers, after writing mine: http://video.google.com/videoplay?docid=-5187022592682372937 It has a lot of similar material, but I think his talk is much better because it goes into how it would actually be attacked. He also must have powerpoint-fu whereas I'm using lyx Any opinions? -- Crypto ergo sum. http://www.subspacefield.org/~travis/ Do unto other faiths as you would have them do unto yours. If you are a spammer, please email j...@subspacefield.org to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Code makers and breakers of WWII era
http://news.cnet.com/2300-1029_3-6240826-1.html?tag=ne.gall.pg -- Crypto ergo sum. https://www.subspacefield.org/~travis/ Truth does not fear scrutiny or competition, only lies do. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
quantum cryptography broken?
http://www.kurzweilai.net/news/frame.html?main=/news/news_single.html?id%3D8471 Quantum cryptography broken KurzweilAI.net, April 20, 2008 Two Swedish scientsts, Jorgen Cederlof, now of Google, and Jan-Ake Larsson of Link In a paper published in IEEE Trans. Inf Theory, 54: 1735-1741 (2008), they point out that an eavesdropper could gain partial knowledge on the key in quantum cryptography that may have an effect on the security of the authentication in the later round. By accessing the quantum channel used in quantum cryptography, the attacker can change the message to be authenticated (since the message is influenced by attacker-initiated events on the quantum channel). This, combined with partial knowledge of the key (transmitted on the quantum channel), creates a potential security gap, they suggest. Their proposed solution: simply transmit an extra exchange of a small amount of random bits on the classical (Internet) channel. FAQ: http://www.mai.liu.se/~jalar/qkg/faq.html -- Crypto ergo sum. https://www.subspacefield.org/~travis/ My password is easy to remember; it's the digits of Pi. All of them. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Pi, randomness, entropy, unpredictability
I've been working on the "randomness and unpredictability" this morning instead of doing my taxes, and found these links: http://crd.lbl.gov/~dhbailey/pi/ http://pisearch.lbl.gov/ The section on randomness, entropy, etc. is here: http://www.subspacefield.org/security/security_concepts.html#tth_sEc20 The formatting on the PDF is better: http://www.subspacefield.org/security/security_concepts.pdf Currently the section begins on page 72. Please tell me what you think. -- Crypto ergo sum. https://www.subspacefield.org/~travis/ My password is easy to remember; it's the digits of Pi. All of them. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
presentations about encrypted storage
I've got two presentations I've given on encrypted storage technologies here: http://www.subspacefield.org/security/ There's also a book I'm writing, if anyone is interested. -- https://www.subspacefield.org/~travis/ I need a better strategy for being less analytical. For a good time on my email blacklist, email [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
delegating SSL certificates
So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. I know that if we had IT put our root cert in the browsers, that we could then generate our own SSL certs. Are there any options that don't involve adding a new root CA? I would think this would be rather common, and I may have heard about certs that had authority to sign other certs in some circumstances... -- https://www.subspacefield.org/~travis/> Who Would Jesus Bomb? For a good time on my email blacklist, email [EMAIL PROTECTED] pgp62b6zjh4z9.pgp Description: PGP signature
crypto quotes
http://www.amk.ca/quotations/cryptography/ -- https://www.subspacefield.org/~travis/> The stream is deaf, yet sings its melody for all to hear. For a good time on my email blacklist, email [EMAIL PROTECTED] pgpqS3cxnwgDl.pgp Description: PGP signature
Re: crypto class design
On Wed, Dec 19, 2007 at 08:22:09AM +0100, Luis Martin wrote: > I am not sure I understood what you want but here's my suggestion. The problem is that client code assumes that there is a fixed (constant) relationship between the size of the output and the size of the input, and does its own memory allocation for the output, and uses pointers. This makes it difficult to change that relationship safely; I basically have to track down and change all the calling code, which may be near-impossible. I think the right solution in this case is to pass objects and not pointers, unless performance dictates otherwise. But, are there similar assumptions implicit in the calling code which I can avoid through proper design, now? That having been said, your suggestion for a data type for this purpose, with semantically-useful subdivisions, is an interesting one; thank you (and everyone else who gave suggestions!) -- In God We Trust, All Others Must Provide Source Code https://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my email blacklist, email [EMAIL PROTECTED] pgp89cGmO9kmW.pgp Description: PGP signature
crypto class design
So... supposing I was going to design a crypto library for use within
a financial organization, which mostly deals with credit card numbers
and bank accounts, and wanted to create an API for use by developers,
does anyone have any advice on it?
It doesn't have to be terribly complete, but it does have to be
relatively easy to use correctly (i.e. securely).
I was thinking of something like this:
class crypto_api
{
...
// developers call these based on what they're trying to do
// these routines simply call crypto_logic layer
Buffer encrypt_credit_card(Buffer credit_card_number, key_t key);
Buffer encrypt_bank_account(Buffer bank_account, key_t key);
Buffer encrypt_other(Buffer buffer, key_t key);
...
};
class crypto_logic
{
...
algo_default = ALGO_AES256CBC;
// encrypt with a given algorithm
Buffer encrypt(Buffer buffer, key_t key, algo_t aid = algo_default);
// calls different routines in crypto_implementation layer depending on
algorithm used
Buffer decrypt(Buffer buffer, key_t key);
...
};
class crypto_glue
{
...
// calls routines in libraries such as OpenSSL
// mostly wrappers that translate between our data types and theirs
Buffer aes256cbc-encrypt(...);
Buffer aes256cbc-decrypt(...);
...
};
The general idea is that crypto_api provides domain-specific APIs that
are easy for anyone to understand, that the logic layer allows for the
selection of different algorithms, and the glue layer is basically a
translation layer to underlying libraries.
It is very important that the API remain stable, because the code
base is large and owned by various groups.
One thing that I'm wondering is how to indicate (e.g.) the overhead in
terms of padding, or whatever, for various algorithms... or if it
matters. The old code had some really disturbing practices like
assuming that the output buffer was 16 octets bigger, and stuff like
that... scary.
Intend to skim the OpenSSL design and Gutmann's "Design of a
Cryptographic Security Architecture" for ideas.
Comments?
--
In God We Trust, All Others Must Provide Source Code
https://www.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my email blacklist, email [EMAIL PROTECTED]
pgp60d9I19hOd.pgp
Description: PGP signature
Re: refactoring crypto handshakes (SSL in 3 easy steps)
On Thu, Nov 15, 2007 at 10:28:43AM +0200, [EMAIL PROTECTED] wrote: > There's a dependency from "negotiated capabililities" > to the cryptographic things included in the first message > from client to server (since e.g. what algorithm is > used by the client, or even what certificate is selected, > depends on these "non-crypto" capability/feature parts.) > > But as James pointed out, you could probably handle this > in "optimistic" mode; i.e. make a guess what the "negotiated > capabilities" are likely to be, and fall back to more > RTTs if the guess is wrong. One could theoretically send all of the permutations prior to negotiation. However, there would be a bandwidth penalty, a privacy penalty (any listener knows all cryptographic identities), and a possible security penalty (if any of the supported methods are undesirably weak). However, if you only have strong ciphers and don't care about cryptographic identity protection, it could be useful. Note that all these weaknesses already exist, as they could be triggered by communicating with a less-capable client, or one controlled by an adversary. Whether or not it matters depends on some contextual details. > (BTW, usually we also want the capability negotiation > to be secure; SSL simply exchanges MACs of all messages > once the key for MAC has been agreed on. Would this > add 0.5 or 1RTT? Or perhaps there's some clever > way to do it without additional RTT?) Schneier suggests keeping a running MAC over the entire datastream, the state of which is sent with each logical message. I think that's a simple and safe way to do it, and so there's no extra messages involved. You always check the MAC first, before operating on the data, and you abort whenever you receive one with a message with an invalid MAC. The MAC with each message attests to the integrity of all data ever sent over that connection, period. The obvious way - doing a specific step just to verify the handshake - is the kind of code-centric thinking that I'm trying to avoid. I'm having trouble finding the right words for it. Basically an encrypted network protocol is a language in which a transmission is syntactically correct if and only if all the security properties hold. In some ways current protocols are like a poorly-written language whose parser that needs a seperator character between statements instead of being able to detect the syntax error when it starts processing the following statement. Basically it lacks even a single symbol look-ahead. -- Life would be so much easier if it was open-source. https://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpjHn1QEV8i0.pgp Description: PGP signature
Re: refactoring crypto handshakes (SSL in 3 easy steps)
On Tue, Nov 13, 2007 at 08:35:52AM +0200, [EMAIL PROTECTED] wrote: > The "extra messages" might be irrelevant for cryptography, > but they're not irrelevant for security or functionality. > E.g. in SSL, you have capability/feature negotiation > (cipher suites, trusted CAs, in TLS 1.2 also signature > algorithms, etc.) So, this is a good place to attempt to use this method. Data to be sent: 1) supported capabilities on the client 2) supported capabilities on the server 3) negotiated capabilities Dependencies: 1) No dependencies (first message from client to server) 2) No dependencies (first message from server to client) 3) Depends on #1 and #2 Results: 3 messages 1-1.5 RTTs (one if there's a simultaneous open, which is rare) So unless I'm missing something, we're still at 3 messages. Aside: I would like to point out that TCP-based protocols have the latency disadvantage of having to do a 3-way handshake before transferring any data. If you were to design a new IP protocol, you could do the key exchange within the handshake, which would save 3 messages, but may be vulnerable to a resource-consumption attack on the CPU. I wonder if we here could develop a handshake that was cryptographically secure, resistant to CPU DoS now, and would be possible to adjust as we get faster at doing crypto operations to reduce latency even further. Basically an easy knob for balancing high latency and DoS resistance vs. crypto overhead and low latency. It should be adjustable on either end without altering the other. -- Life would be so much easier if it was open-source. https://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp8fMSK6gOb3.pgp Description: PGP signature
cryptanalysis of RNG of Windows OS
Interesting-looking paper from some guys in Israel: http://eprint.iacr.org/2007/419.pdf Quoting: We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in O(2^23) work (this is an attack on the forward-security of the generator, an O(1) attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks. The generator is run in user mode rather than in kernel mode, and therefore it is easy to access its state even without administrator privileges. The implication of these findings is that a buffer overflow attack or a similar attack can be used to learn a single state of the generator, which can then be used to predict all random values, such as SSL keys, used by a process in all its past and future operation. This attack is more severe and more efficient than known attacks, in which an attacker can only learn SSL keys if it is controlling the attacked machine at the time the keys are used. -- Life would be so much easier if it was open-source. https://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp8GVGsxKlJi.pgp Description: PGP signature
Caffe Latte attack cracks WEP from clients in 6 mins
http://www.airtightnetworks.net/knowledgecenter/wep-caffelatte.html The Caffe Latte attack debunks the age old myth that to crack WEP, the attacker needs to be in the RF vicinity of the authorized network, with at least one functional AP up and running. We demonstrate that it is possible to retrieve the WEP key from an isolated Client - the Client can be on the Moon! - using a new technique called "AP-less WEP Cracking". With this discovery Pen-testers will realize that a hacker no longer needs to drive up to a parking lot to crack WEP. Corporations still stuck with using WEP, will realize that their WEP keys can be cracked while one of their employees is transiting through an airport, having a cup of coffee, or is catching some sleep in a hotel room. Interestingly, Caffe Latte also has a great impact on the way Honey-pots work today and takes them to the next level of sophistication. At its core, the attack uses various behavioral characteristics of the Windows Wireless stack along with already known flaws in WEP to pull off this feat! We have considered all combinations of network configurations and shown how it is possible to retrieve the WEP key in matter of less than 6 minutes in each case. We exploit the shared key authentication flaw and the message modification flaw in 802.11 WEP, to send a flood of encrypted ARP requests to the isolated Client. The Client replies to these requests with a barrage of encrypted ARP responses. We use these ARP responses and plug them into the PTW cryptographic attack and recover the WEP key in less than 6 minutes. It is important to note that though our talk will center on wireless Clients which run a Windows operating system, the core idea presented can be easily used to find similar attacks for other operating systems. -- Life would be so much easier if it was open-source. https://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpRD97hwznY8.pgp Description: PGP signature
refactoring crypto handshakes (SSL in 3 easy steps)
ASSUMPTIONS: Network latency is important, and will only become more so, since light won't go faster in a given medium, and we can't do better than c, ever. PROPOSED SOLUTION: Refactor protocol to minimize number of interlocked steps. Specifically, reduce the number of messages. METHODOLOGY: Identify data which must be transmitted, and identify their dependencies. Send data on first outbound message to peer after all its dependencies are available (i.e. on the step after it is received). Each transmission is a sweep of one level of the dependency tree, starting at the root and working downward. PREVIOUS WORK: Three messages is the proven minimum for mutual authentication. Last two messages all depend on the previous message, so minimum handshake time is 1.5 RTTs. EXAMPLE: First examine SSL with Mutual Auth, which is detailed here: http://en.wikipedia.org/wiki/Image:Ssl_handshake_with_two_way_authentication_with_certificates.png Here is a refactored version of the important messages: C->S: hello, RNc, client cert, enc_S(client_cert) S->C: server cert C->S: enc_S(PMS) DISCUSSION: Providing the datum as soon as its dependencies are satisfied is well-studied in processor design. One may have extra messages, but they are implementation artifacts, completely irrelevant to the cryptography. Network protocol libraries advance through time monotonically and thus are analogous to LR(1) language parsers which parse from left to right and are only able to look at the next token (message); perhaps we can apply what we already know about them to create unambiguous crypto handshakes with respectable error handling. Sending one layer of the dependency tree at once is like a synchronous circuit; one could also fire off messages as soon the data becomes available, like an asynchronous circuit, which may reduce overall time of the handshake due to computation by the endpoints. However, it is an implementation detail, not important to this analysis. OPEN QUESTIONS: When would a handshake require more? Is there such a thing, in any extant ZKS or PFS systems? COMMENTS? -- Life would be so much easier if it was open-source. https://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp3jScb43Di8.pgp Description: PGP signature
Re: Hushmail in U.S. v. Tyler Stumbo
On Tue, Oct 30, 2007 at 12:27:53PM -0400, [EMAIL PROTECTED] wrote: > I stumbled across this filing: > http://static.bakersfield.com/smedia/2007/09/25/15/steroids.source.p > rod_affiliate.25.pdf I probably shouldn't say anything about this, but whoever made this PDF failed to properly redact the personal information in #10, just like the NYT failed to do with the names of the people who helped the US in Iran. I can simply switch desktops and see the numbers underneath before the rectangles are drawn over them (possibly on another layer). Actually the box on #14 seems to work, possibly because it is larger, or was done differently. > What I found interesting was: > 1. The amount of data which Hushmail was required to turn over to > the US DEA relating to 3 email addresses. 3 + 9 = 12 CDs What > kind of and for what length of time does Hushmail store logs? You would think that they would store the minimum or none, so that they didn't have to answer such requests. In the US, companies can require compensation for resources spent filling these requests, but many do not for fear of increased scrutiny by law enforcement. I have been around when my department at a Usenet server had to fill these kinds of requests on posts from people selling GHB or something like that. They pretty much write their subpoenas as wide as possible, pretty much "any record you have about..." and then they give you every relevant piece of identifying information they have. I think you have to swear under penalty that you got them everything. Sorry bro IIRC, there were laws passed in Europe dictating minimum retention times for ISPs and such. They may have been passed in Canada and the US as well. I guess the legal theory is that when a business offers services to the public they give up some rights over private property. Probably they did the minimum work to comply, which means that the CDs are either mostly empty, or full of unrelated data. > 2. That items #5 and #15 indicated that the _contents_ of emails > between several Hushmail accounts were "reviewed". Yep. > 3. The request was submitted to the ISP for IP addresses related > to a specific hushmail address (#9). How would the ISP be able to > link a specific email address to an IP when Hushmail uses SSL/TLS > for both web and POP3/IMAP interfaces? It appears he used IP addresses gathered from #4. > Since email between hushmail accounts is generally PGPed. (That is > the point, right?) And the MLAT was used to establish probable > cause, I assume that the passphrases were not squeezed out of the > plaintiff. How did the contents get divulged? My guess is that Hushmail has had subpoenas before and had to develop and install a modified java applet which captures the passphrase when the user enters it. With that and the stored keys, it can decrypt all the stored communications. If that's true, I wouldn't expect them to trumpet it, since it would mostly negate their value proposition. -- Life would be so much easier if it was open-source. http://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpZ2FLxvXa1Y.pgp Description: PGP signature
password strengthening: salt vs. IVs
So back in the bad old days when hashing was DES encryption of the zero vector with a fixed key, someone came up with salt as a password strengthening mechanism. I'm not quite sure why it was called salt. It perturbed the S-boxes in DES IIRC, but essentially it was a known bit of text that was an input to the algorithm that varied between entries, like an IV does with encryption. If there isn't already a term for this, I'm going to call this general concept "individuation", or possibly "uniquification". Nowadays with strong hash algorithms, but rainbow tables and low-entropy passwords as the threat, I'm wondering what the best practice is. I was thinking of simply prepending a block of text to each passphrase prior to hashing, and storing it with the hash - similar to salts in passwd entries. It should have at least as much entropy as the hash output, maybe a little more in case there's collisions. If it were uniformly random, you could simply XOR it with the passphrase prior to hashing and save yourself some cycles, right? Would it be appropriate to call this salt, an IV, or some new term? -- Life would be so much easier if it was open-source. http://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpsfGwr9Iy35.pgp Description: PGP signature
Re: kernel-level key management subsystem
On Tue, Oct 09, 2007 at 06:08:44PM +1300, Peter Gutmann wrote: > how do you want access to the keys controlled? ACLs? Who sets the ACLs? Who > can manage them? How are permissions managed? What's the UI for this? Under > what conditions is sharing allowed? If sharing is allowed, how do you handle > the fact that different apps (with different levels of security) could have > access to the same keys? Do you derive keys from a master key? Do you > migrate portions of the app functionality into the kernel to mitigate the > problems with untrusted apps? How is key backup handled? What about > > [Another 5 pages of questions] Good stuff. I was hoping perhaps to stimulate a discussion on just these sorts of issues. There's a bit of interrelated stuff here; you can start with requirements, postulate some mechanisms, think about implications of their implementation, which leads to refining requirements. It's sure to be a learning experience. Maybe this isn't the best place to do that, but it seems to me that this group would be one of the best for ironing out the details, and would have a vested interest in any such management interface not suck. Ideally I'd like to be able to develop something for, say, Linux, and possibly integrate it with your open-source co-processor stuff. > Once you've got a clear statement of exactly what you want to do (which in its > most abstract form is "solve an arbitrarily complex key management problem"), > implementation is almost trivial in comparison. Sure. Maybe that's a good question: what are the idioms in key management? Is there any similar work already that I could read up on? Where can I read up on current HSM functionality, offerings, features, etc.? "Computers are useless; they can only give answers." -- Pablo Picasso -- http://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpRDG3MxsVBo.pgp Description: PGP signature
Re: 307 digit number factored
On Mon, May 21, 2007 at 04:32:10PM -0400, Victor Duchovni wrote: > On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote: > > My take: clearly, 1024 bits is no longer sufficient for RSA use for > > high value applications, though this has been on the horizon for some > > time. Presumably, it would be a good idea to use longer keys for all > > applications, including "low value" ones, provided that the slowdown > > isn't prohibitive. As always, I think the right rule is "encrypt until > > it hurts, then back off until it stops hurting"... > > When do the Certicom patents expire? I really don't see ever longer RSA > keys as the answer, and the patents are I think holding back adoption... They already expired. Some EC primitives in the latest OpenSSL. But why assume short ECC keys are stronger than long RSA? AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Although every time I read up on ECC, I understand it, and then within a few days I don't remember anything about it. I think they teflon coated those ideas somehow, because they don't stick. > With EECDH one can use ECDH handshakes signed with RSA keys, but that > does not really address any looming demise of 1024 bit RSA. Why can't they do something like El-Gamal? I'm not comfortable with RSA somehow. It seems fundamentally more complicated to me than DLP, and it's hard to get right - look at how many things there are in the PKCS for it. -- http://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpBNtfcR3SYr.pgp Description: PGP signature
Re: kernel-level key management subsystem
On Mon, May 21, 2007 at 01:44:23PM +1200, Peter Gutmann wrote: > >Ignoring special-purpose hardware, does anyone have thoughts on what the > >requirements for a kernel-level key management subsystem should be? > > Yes, but first you'd have to tell me what you're trying to do. Protect keys in kernel land rather than userland. Allows for things like e.g. 1) marking memory unpageable (avoiding swap hazard) 2) relocating the data to different physical pages to prevent burn-in 3) secure wiping 4) providing a common system for storing and protecting them rather than doing it in each individual application 5) allowing for them to be shared securely among processes (like ssh-agent and gpg-agent) 6) provide protection against userland snooping programs (gdb anyone?) etc. -- http://www.subspacefield.org/~travis/> Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp7rkyiXmAFj.pgp Description: PGP signature
ECC vs. D/H or RSA
Does anyone have information on: 1) The ECAES weakness that led to ECIES 2) Any known weaknesses of ECIES 3) Relative performance figures between ECC routines like ECIES and D/H (or possibly RSA, though IES is based on EC-DH) I can generate the last if these figures are not available. BTW, I noticed that the latest OpenSSL has some EC functions, including EC-DH IIRC. It does not have ECAES or ECIES though. References: http://en.wikipedia.org/wiki/ECIES http://www.secg.org/download/aid-385/sec1_final.pdf -- http://www.subspacefield.org/~travis/> Tat Tvam Asi For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpvAz1RvHImk.pgp Description: PGP signature
Undocumented Bypass in PGP Whole Disk Encryption
http://it.slashdot.org/article.pl?sid=07/10/04/1639224&from=rss Interesting quote: Jon Callas, CTO and CSO of PGP Corp., responded that this [previously undocumented] feature was required by unnamed customers and that competing products have similar functionality. -- http://www.subspacefield.org/~travis/> Tat Tvam Asi For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpUavsYRK20D.pgp Description: PGP signature
debunking snake oil
I think it might be fun to start up a collection of snake oil cryptographic methods and cryptanalytic attacks against them. It would be more fun for me than crossword puzzles, and educational for all the would-be cryptographers. I'd like to start with the really simple stuff; classical cryptography, systems with clean and obvious "breaks". Although I find the magazine entertaining to read, I'm finding that 2600 Magazine is a particularly good source of this brand of snake oil. So, when you find a particularly obnoxious dilettante going on about his bone-headed unbreakable scheme, please forward it to me and I'll see about breaking it, and then publish the schemes and the results on a web site for publicly "educating" them. Honestly, there's probably no better way to educate people than to see schemes submitted and broken, and I'm not sure there's a good site for it, although there are plenty of books. Unfortunately, these types won't be bothered to buy books since they already know everything. If you have a break of some scheme you wish to contribute, please do forward me a URL and I'll link to it. Perhaps this should be a wiki? I'm revamping my web site, so the crypto wiki has been down temporarily but will be back up. -- http://www.subspacefield.org/~travis/> -><- dharma <>< advaita For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpZSRJOjN7nS.pgp Description: PGP signature
magnifying unpredictability and common subexpressions
So I'm looking for a minimum cost transformation with _only_ the following characteristic: Given a set of m input bits X, produce a set of n output bits Y such that knowledge of some subset of X and Y gives a minimum knowledge of the remainder (of Y if that makes it simple, but of X would be nice). This is not unlike the "all-or-nothing" package transform proposed by Rivest; the basic idea is that you have to know all of X in order to know anything about Y - sort of. My first iteration is as follows: Let ^ represent xor. Let p be the exclusive or of all bits of x (i.e. the parity). Let Y = f(X), where f(x) = p ^ x Basically, each bit of Y is the xor of every _other_ bit of x (x was actually xored into p, so by xoring again, it cancels out) However, my problem is that no matter how few bits of X you know, you only have to guess one bit, p, in order to know the bits of Y that correspond to the bits you know of X. Let me be concrete; suppose that I know only bits 0 of X and bit 0 of Y. I can then compute p, and from that I can use any further knowledge of bits of X to compute corresponding bits of Y. Note that p = x[0] ^ y[0]. Then if I know x[1], I can reveal y[1] = p ^ x[1]. And so forth. Obviously I need something more complex. The problem seems to be that the equations for every bit y depend only on x and p; that is, if we know x, we only have to guess p once for the whole array. In a way, this reminds me of an idea I had earlier, whereby this variable p is what I call a common subexpression, a key which unlocks the equation, a sort of trapdoor. Suppose I had written Y = f(X) as follows: y[0] = x[1] ^ x[2] ^ x[3] ^ x[4] y[1] = x[0] ^ x[2] ^ x[3] ^ x[4] y[2] = x[0] ^ x[1] ^ x[3] ^ x[4] ... A novice may have not have realized that each bit of y depends _only_ on x ^ p, and that knowing or guessing p would reveal every bit of Y for each known bit of X, without having to know any other bit of X. Now, what I sometimes wonder is whether the equations and tables in things like DES or SHA-1 are not similar... a table allows for several boolean logic representations, and depending on which you pick for each output bit, it may be possible that a common subexpression like p falls out of the equations, minimizing the amount of unknowns, or the amount of compute power necessary to brute-force it. For a Feistel cipher like DES, one might pick different boolean logic representations in different rounds, to minimize the complexity of the equations you get at the end. This is why I don't try to design ciphers. I could possibly come up with some complicated-looking tables and equations, but I'd have no assurance that a simple common subexpression did not exist. Do I need to resort to a conventional hash like SHA-1? I am not convinced that it is necessary, or that I'd have any more assurance from SHA-1 than I'd have with a randomly-generated set of equations. Does it have to be random? Isn't there a regular structure I could exploit here? It seems like there should be! Randomly-generated equations remind me a bit of the following AI Koan: In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6. "What are you doing?", asked Minsky. "I am training a randomly wired neural net to play Tic-Tac-Toe", Sussman replied. "Why is the net wired randomly?", asked Minsky. "I do not want it to have any preconceptions of how to play", Sussman said. Minsky then shut his eyes. "Why do you close your eyes?", Sussman asked his teacher. "So that the room will be empty." At that moment, Sussman was enlightened. -- http://www.subspacefield.org/~travis/> -><- dharma <>< advaita For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpdBhbOliHn7.pgp Description: PGP signature
Re: luks disk encryption benchmarks
On Tue, Jun 05, 2007 at 07:00:51PM -0500, Travis H. wrote: > I just did some performance testing on a file server (debian 4.0) and > thought I'd share the figures, both raw and using the luks > cryptosystem described here: > > http://luks.endorphin.org/about > > Here's the specs: > > AMD Athlon 64 x2 3600+ (1800MHz) > 2GB 800MHz DDR2 ECC DRAM > Asus M2N32WS motherboard > 3ware 9650SE SATA RAID controller (PCI Express) in PCI Express x16 slot > 4 Seagate SATA-II 500GB 7200 RPM drives with NCQ in RAID 10 configuration > 16kB stripe size > Debian 4.0 stable (etch) > > My hunch is that over NFS, even with gigabit ethernet, there will be no > measurable > difference between encrypted and non-encrypted storage. raw over NFS: Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nfsclient4G 16756 61 40475 21 12033 9 15669 85 15564 6 445.8 3 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2329 12 8480 32 4185 22 1857 10 9742 27 3692 18 nfsclient,4G,16756,61,40475,21,12033,9,15669,85,15564,6,445.8,3,16,2329,12,8480,32,4185,22,1857,10,9742,27,3692,18 crypt over NFS: Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nfsclient4G 16416 61 33488 13 10666 9 14084 73 16143 7 392.7 3 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2218 12 7444 25 4248 20 2288 12 9401 28 3575 15 nfsclient,4G,16416,61,33488,13,10666,9,14084,73,16143,7,392.7,3,16,2218,12,7444,25,4248,20,2288,12,9401,28,3575,15 So... yeah, pretty minimal - IMHO, not worth worrying about. -- ``To know love, be like the running brook, which though deaf, sings its melody for others to hear.'' -- Master Po, "Kung Fu" http://www.subspacefield.org/~travis/> -><- dharma <>< advaita For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp0t6UIV8S0K.pgp Description: PGP signature
luks disk encryption benchmarks
I just did some performance testing on a file server (debian 4.0) and thought I'd share the figures, both raw and using the luks cryptosystem described here: http://luks.endorphin.org/about Here's the specs: AMD Athlon 64 x2 3600+ (1800MHz) 2GB 800MHz DDR2 ECC DRAM Asus M2N32WS motherboard 3ware 9650SE SATA RAID controller (PCI Express) in PCI Express x16 slot 4 Seagate SATA-II 500GB 7200 RPM drives with NCQ in RAID 10 configuration 16kB stripe size Debian 4.0 stable (etch) # time dd if=/dev/zero of=/dev/sdb bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 23.0923 seconds, 45.4 MB/s real0m23.094s user0m0.000s sys 0m4.508s Now here demonstrates the luks cryptsetup overhead: # time dd if=/dev/zero of=/dev/mapper/bulk bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 31.0872 seconds, 33.7 MB/s real0m31.089s user0m0.004s sys 0m14.053s So, with write-caching disabled, performance is fairly close. Then I enabled write-caching and got this: # time dd if=/dev/zero of=/dev/sdb bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 3.08291 seconds, 340 MB/s real0m3.126s user0m0.000s sys 0m1.996s That seems to reflect that it isn't really going to disk. I'm surprised the controller has that much RAM on it, really... so I ran this: # time dd if=/dev/zero of=/dev/sdb bs=1024k count=4000 4000+0 records in 4000+0 records out 4194304000 bytes (4.2 GB) copied, 81.0223 seconds, 51.8 MB/s real1m21.024s user0m0.004s sys 0m19.197s Now here's the overhead with encryption: # time dd if=/dev/zero of=/dev/mapper/bulk bs=1024k count=4000 4000+0 records in 4000+0 records out 4194304000 bytes (4.2 GB) copied, 151.202 seconds, 27.7 MB/s real2m31.227s user0m0.008s sys 1m29.318s Based on this, it looks like one of two things is happening: Write cache is 2GB and encryption cancels it out OR Encryption reduces bandwidth by about a factor of 2 with write-caching enabled. Now, for these filesystem tests I just used the default ext3... it does use a journal, which will slow down writes, but this should give ballpark figures: Here are the filesystem-level benchmarks without encryption (using LVM to make the filesystem 4G or so): Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP machine4G 54305 96 84213 14 37749 8 52767 94 119217 13 436.6 0 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 5175 99 + +++ + +++ 5131 99 + +++ 14419 99 machine,4G,54305,96,84213,14,37749,8,52767,94,119217,13,436.6,0,16,5175,99,+,+++,+,+++,5131,99,+,+++,14419,99 Here's the filesystem-level performance with encryption (again, with LVM on top of the encryption, file system 10G): Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP machine4G 36692 98 79380 71 28544 6 50631 91 74157 9 464.5 0 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 5344 99 + +++ + +++ 5261 99 + +++ 16060 99 machine,4G,36692,98,79380,71,28544,6,50631,91,74157,9,464.5,0,16,5344,99,+,+++,+,+++,5261,99,+,+++,16060,99 This presents a more interesting picture; it appears that for work on actual files, the overhead is pretty modest... with all but character-at-a-time input, it's not worth worrying about. My hunch is that over NFS, even with gigabit ethernet, there will be no measurable difference between encrypted and non-encrypted storage. -- ``To know love, be like the running brook, which though deaf, sings its melody for others to hear.'' -- Master Po, "Kung Fu" http://www.subspacefield.org/~travis/> -><- For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpHe5SIlTgbj.pgp Description: PGP signature
crypto maxims
I have posted my ideas on defensive use of crypto here: https://www.subspacefield.org/security/cgi-bin/moin.py/CryptoMaxims This is not about cipher design, it's more about protocol design and implementation. Everyone here is welcome to edit it as they see fit; questions and answers, discussion - the goal is education, so all of those are desirable. -- Good idea: helping a stranger move Bad idea: helping a stranger move bodies http://www.subspacefield.org/~travis/> -><- For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpxaOXrYkI6v.pgp Description: PGP signature
kernel-level key management subsystem
Ignoring special-purpose hardware, does anyone have thoughts on what the requirements for a kernel-level key management subsystem should be? -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp9WQGxTEqLS.pgp Description: PGP signature
Re: phone encryption technology becoming popular in Italy
On Wed, May 02, 2007 at 06:12:31PM +0100, Dave Korn wrote: > If you wanted to be /really/ certain, I guess you'd have to take the tops > off all the ICs inside and look at them under an EM, to make sure they really > were the parts they claimed to be and don't have any extra circuitry or hidden > functions built in If the chips had more than a single layer, or even if they were single layer, it's probably possible to hide some functionality. I've heard of devices that are capable of displaying the current flowing through the conductive regions of the chip (electrons move just a little too fast to follow, about 1/4 the speed of light in copper) but that's an awfully labor-intensive way to check that everything is working to spec... it's probably cheaper to build it yourself. And then with respect to the non-crypto issues; are you going to cut open every capacitor on the red signal path to check for, say, miniature FM transmitters? I'm reminded a bit of the US embassy in Moscow, where (using neutron scanners) they found bugs in the girders that were the same density as the steel, and so invisible to X-rays... in the end, they learned that the only way to avoid these kinds of surprises was to use only their own building materials and labor. Earlier in this list tamper-resistant hardware was mentioned... the downside of that is that unless you're the manufacturer, your attempts to verify that it doesn't have any surprises look a whole lot like the kind of tampering it is designed to resist... It seems like this is a deep rabbit hole with no obvious end. Probably the best one could hope for is to avoid targeted attacks, where the opponent knows you are getting something and has it customized for you. Widespread (indiscriminate) compromisation is probably impractical to detect. If you're a nation, or particularly wealthy, then perhaps you can do it all yourself, but for high-tech devices that can get very expensive. History is littered with examples where countries tried to create a domestic source for some strategic good and failed miserably. Incidentally, on my web page I have some pictures and code for a HWRNG that an associate built (I wrote the software); he made a limited run of 10 or so, but if anyone wants the schematics, you'll want to send a SASE to Brad Martin at http://www.nshore.com/ (the plans are not in an easy-to-email form and this method filters out all but serious inquiries). It is actually a pretty neat device, battery powered to avoid 60Hz signal injection (you can use a wall wart if you want to though, the filters are good) and even enters a power-saving mode when not in use. My software (written for Linux and BSD) supports a mode where it allows the device to power down when /dev/random is above a "high water mark", and automatically powers it up when it drops below it. One person called it "the most over-engineered RNG I have ever seen". I think the cost to build one is about $100-200, but Brad spent $30k of unbillable time on this personal project, mostly on the design. It's a shame to see that only used on 10 units. There are, incidentally, some open-source hardware web sites, where they have schematics for various chips and cores... although you can't just etch your own silicon, there are shops that do all of that for you; you just email them the layouts and send them the money, and they can do a small run of chips for reasonable prices. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpBE4zRtMeSN.pgp Description: PGP signature
Re: More info in my AES128-CBC question
On Wed, May 09, 2007 at 06:11:03PM -0400, Leichter, Jerry wrote: > Just being able to generate traffic over the link isn't enough to > carry out this attack. Well, it depends on if you key per-flow or just once for the link. If the latter, and you have the ability to create traffic over the link, and there's a 1-for-1 correspondence between plaintext and encrypted packets, then you have a problem. Scenarios include: Private wifi network, you are sending packets at a customer from unprivileged node on internet; you want known plaintext for the key used to secure the wifi traffic, or you want the contents of his connection. Target is VPN'ed into corporate headquarters, you are sending packets at them (or you send them email, they download it from their mail server) -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpEWNibI30LX.pgp Description: PGP signature
Re: More info in my AES128-CBC question
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote: > However, cryptographically secure RNG's are typically just as expensive > as doing a block encryption. So why not just encrypt the IV once with > the session key before using it? (This is the equivalent of pre-pending > a block of all 0's to each packet.) There's many ways to deal with it if you're willing to do more crypts per block. For example, you could derive an independent key and use that to encrypt a counter for IVs... becoming a cryptographically strong permutation... that'd work as long as you didn't send so many IVs that you ran through most of the cycle (the last value in the cycle is 100% predictable). -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpYqqeHkErOq.pgp Description: PGP signature
Re: Public key encrypt-then-sign or sign-then-encrypt?
On Thu, May 03, 2007 at 07:57:18PM +1000, James A. Donald wrote: > Assume Ann's secret key is a, and her public key is A = G^a mod P > > Assume Bob's secret key is b, and his public key is B = G^b mod P > > Bob wants to send Ann a message. > > Bob generates a secret random number x, and sends Ann X = G^x mod P > > Ann responds with Y = G^y mod P, where y is another secret random number. > > Ann calculates [(B*X)^(a+y)] mod P This appears to simplify to: (G^b * G^x)^(a+y) = (G^(b+x))^(a+y) = G^((b+x)(a+y)) Right? This doesn't appear to be anything like the latest rev of the OTR protocol: http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html Apparently they key exchange is now a variant of the SIGMA protocol, and relies upon the implementation to disclose MAC keys automagically as the related session keys are destroyed/expired. Apparently this fixes an identity-binding flaw: http://lists.cypherpunks.ca/pipermail/otr-users/2005-July/000316.html And this illustrates a subtlety: > For example, if Bob thinks he's talking to Mallory, he may tell her > something in confidence he would not want Alice to hear. Note that > although Mallory could relate this confidential information to Alice > herself, but in the attack scenario Alice has assurance that the > message came from Bob rather than having to take Mallory's word for it. Contrast this to sign-then-encrypt, where Mallory could decrypt, then forward to Alice. Compare with encrypt-then-sign. But it brings up an interesting point; that when a party relays a piece of data it may not be equivalent to receiving it directly; that is, authenticity may not be transitive. Put another way, maybe it's not the information that matters, but who says it. The New York Times may say that someone did XYZ, but that's not entirely the same as the person admitting it under oath. In international politics, many believe that admitting to having performed some provocative action can be more provocative than actually the action itself, even if everyone already knows who is responsible. If you believe this, I suppose the official lie can be said to serve the interest of both sides, as the government receiving the provocation can allow the story to go unchallenged, and probably not be forced into taking an overt retaliatory action. Thus it preserves their options, and avoids forcing them into what could be a disastrous confrontation. If they are too weak to confront the provocateur, they aren't likely to shout this from the rooftops. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp2OKJBtiEKs.pgp Description: PGP signature
Re: Public key encrypt-then-sign or sign-then-encrypt?
On Wed, May 02, 2007 at 09:29:39AM -0600, Anne & Lynn Wheeler wrote: > where there is possibly the suggestion that if the only thing being > performed > is authentication (and doesn't require either integrity and/or privacy) ... > then possibly a totally different protocol by utilized (rather than > digital signature) This reminds me a bit of a suggestion I once heard for protocol designers that the messages of the various steps of the protocol include a step number or something like it to prevent cut-and-paste attacks (presumably each message has some redundancy to protect the integrity/authenticity as well, like a running hash covering all the previous messages (in this direction)). I wonder if something similar couldn't be done with digital signatures, where the input is padded with data that indicates the semantics of the signature; not unlike the forms which say "by signing here I agree that..." This also makes it very difficult for the opponent to do any kind of chosen-plaintext trickery since the plaintext will be framed with this data that the opponent does not control, but that is also true with other padding options and such. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpnvBUihZ9Sw.pgp Description: PGP signature
Re: More info in my AES128-CBC question
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote: > Frankly, for SSH this isn't a very plausible attack, since it's not > clear how you could force chosen plaintext into an SSH session between > messages. A later paper suggested that SSL is more vulnerable: > A browser plugin can insert data into an SSL protected session, so > might be able to cause information to leak. Hmm, what about IPSec? Aren't most of the cipher suites used there CBC mode? If it doesn't key each flow seperately, and the opponent has the ability to generate traffic over the link, which isn't unreasonable, then this would seem feasible. And then there's openvpn, which uses SSL for the point-to-point link, thus probably vulnerable, more vulnerable than a browser. I am also aware of SSL being used many places other than browsers and openvpn. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpvjZwMdNcnK.pgp Description: PGP signature
truncating MACs for confidentiality, was Re: Public key encrypt-then-sign or sign-then-encrypt?
One more thing to consider; if you pick a reasonable MAC with twice the security factor you need, then truncate the output to half the size, I believe you get both confidentiality and integrity/authentication guarantees of the desired strength. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpmO9O0IvaLW.pgp Description: PGP signature
Why CBC? What is wrong with n-bit CFB?
I've always wondered this about the lesser-used modes. What's special about CBC? With CFB in particular, I think 8-bit CFB is stupid (one full block encryption per byte processed - rather computationally expensive), but n-bit CFB seems just as useful as CBC, if not more so. Specifically, I can start sendings bits of C_(i-1) = IV xor P_(i-1) as soon as I feel like it, even before all of P_(i-1) is in, and it uses the same number or less crypts than CBC. Futhermore, it can be used to encrypt "in place" like CBC but without any special "ciphertext stealing" or other processing. Of course I assume that integrity is handled by a completely seperate mechanism that includes redundancy; anything less is snake oil. For that matter, error extension doesn't seem to be an issue to me in most cases. Error handling should be done via a seperate layer that adds redundancy to the ciphertext prior to transmission (and can do error correction, not just detection). If any error is so bad that it defeats this layer, I want to know about it (and will find out via yet another layer, an integrity/authenticity layer); it could also be a malicious attack, and unless there is bad sunspot or EMP activity the seperation of duties allows me to distinguish between the two. The exception I can see is if retransmission or delay is unacceptable and it is better to get a garbled message than none at all. This may be the case with human spies in occupied territory, or perhaps for emergency messages to a deep space probe, or such. Still, this is the Internet age and transmission errors are increasingly handled by the lower layers. Is anyone actually doing crypto with plaintext that is interpreted by humans (so they can detect and deal with garbles) over radio any more? Not many among us here I suspect. That having been said, I can't see much in favor of OFB over CTR mode. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpVkl00SrKY3.pgp Description: PGP signature
Re: More info in my AES128-CBC question
On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote: > A confounder is an extra block of random plaintext that is prepended to > a message prior to encryption with a block cipher in CBC (or CTS) mode; > the resulting extra block of ciphertext must also be sent to the peer. Not true. Since we are comparing confounders to IVs, let's make identical assumptions; that the value is somehow agreed upon in advance. Then, one need not send it; the receiver can compute C_(i-1) = E_k(confounder) without actually having it sent to him, and from there continue decryption with P_i = C_(i-1) xor D_k(C_i) and so on. > 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. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp5R1OqVH44H.pgp Description: PGP signature
Re: Public key encrypt-then-sign or sign-then-encrypt?
On Wed, Apr 25, 2007 at 03:24:06PM -0300, Mads Rasmussen wrote: > Hugo Krawczyk [1] showed in the symmetric key setting that the > encrypt-then-authenticate was the way to go about securing the integrity > of an encrypted message. Haven't read this yet, but will... and may have comments. Without reading it, I do have some comments. At least one authentication protocol failed because it was possible to strip off a signature then re-use an encrypted blob (e.g. with one's own signature on it). So they are malleable. In _many_ poorly-designed systems it becomes possible to use a system as a signature oracle to sign arbitrary things. Smartcards with a hostile PC are just one of these cases. One must be very careful what a signature is supposed to attest. Also there's a semantic issue; am I attesting to the plaintext, or the ciphertext? It's possible the difference could be important. Do we sign letters, or sign envelopes? If I sign an envelope containing a letter, I deprive you of much of the evidentiary value that a signed letter would carry; you cannot easily prove to someone what I signed without revealing your decryption key(s). With encrypt-then-authenticate, one can check authentication, and if it fails, avoid decryption - while in theory this could avoid DoS, in practice the authentication is more costly than decryption. In my reading on information-theoretic security, I found that if one does encryption around the authentication, then one can prevent the opponent from learning anything about the message. Specifically, if Enc(x) is a one-time-pad, then one can use very efficient and ostensibly unsecure hash functions such as a selection from the universal hash family ax + b (mod n) for one's integrity and authentication, and (for certain restrictions on a, b, and n, and under the assumption of secrecy of a and b) one can have _information-theoretic security for authentication and integrity_. That is, no matter how many messages sent, no matter how many CPU cycles the opponent has available, the opponent can learn nothing new. I've been discussing and developing a prototype system that aims to provide information-theoretic security (and at worst, conventional computational security) for low-bandwidth purposes (i.e. email or IM), and I will post details here when I have them in a relatively stable form, for those who are interested. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpynIGWJie62.pgp Description: PGP signature
open source disk crypto update
Forgive me as this isn't as technical as the usual posts, but I find it interesting nonetheless. OpenBSD has, for some time, supported encrypted swap. 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? I think a simple evolution would be to make /boot and/or /root on removable media (e.g. CD-ROM or USB drive) so that one could take it with you. Of course if someone reflashes your BIOS you are still hosed, but it appears that there's no way to completely eliminate that kind of threat without taking the whole system with you. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpUUuyAM5f8F.pgp Description: PGP signature
crypto component services - is there a market?
So back when I was reading about secure logging I thought it'd be a fun service to offer, but it doesn't seem like a "product" that the average business would be interested in; it seems more like something that would be a component of a larger system, or used by other systems. Same with digital timestamping. Does anyone think there is a market for these "point solutions"? -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp6QuqaLXeIi.pgp Description: PGP signature
explanation of security classification schemes
This is probably the most lucid coverage of the topic I've seen: http://en.wikipedia.org/wiki/Classified_information_in_the_United_States -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpDsIqQzcUua.pgp Description: PGP signature
Re: interesting and thought provoking resources on quantum crypto
On Thu, Feb 08, 2007 at 04:29:25PM -0800, Saqib Ali wrote: > i have been tasked by my advisor to create series of mini-lectures > slides on the topic of cryptography for a freshman year CS class. You know, you shouldn't use the Internet to ask people to do your homework for you... ;-) j/k > any thoughts? the resource has to be related to quantum crypto... Well, this company sells quantum cryptography devices: http://www.idquantique.com/home.htm On the other side, any link collection on quantum _cryptanalysis_ wouldn't be complete without Shor: http://www-math.mit.edu/~shor/ I went to one of his lectures at my university, and it was one of those experiences where you know they're speaking English, but it's just not communicating information to you. Usually this means one of two things; either they are trying to fool you, or you are the fool. I'm convinced it was the latter. I know an EPR pair from a quantum decoy, but I still have no idea what the angles on his graphs had to do with QC and superposition. Lots of good papers on his electronic publications list: http://www-math.mit.edu/~shor/elecpubs.html He points to this wiki: http://www.qubit.org/ This page is about the watershed paper: http://en.wikipedia.org/wiki/Shor's_algorithm And this page attempts to illustrate it: http://pdivos.mobstop.com/shor/ -- Good code works. Great code can't fail. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpS1PBD0MH5l.pgp Description: PGP signature
Re: Entropy of other languages
On Wed, Feb 07, 2007 at 05:53:16PM -0500, Steven M. Bellovin wrote: > Speakers of such Native American languages as Navajo, Choctaw > and Cheyenne served as radio operators, know as Code Talkers, > to keep communications secret during both World Wars. Welsh > speakers played a similar role during the Bosnian War. > > Does anyone know anything more about this use of Welsh? http://en.wikipedia.org/wiki/Welsh_Guards says: In 2002 the regiment arrived in Bosnia as part of SFOR, a NATO-led force intended to ensure peace and stability reigns supreme in the Balkan nation. During their deployment HM the Queen Mother died. A number of officers of the Welsh Guards stood in vigil around the Queen Mother's coffin which was lying in state in Westminster Hall, one of a number of regiments to do so. The regiment returned home from their deployment to Bosnia later in the year. That's all I could find in a 10 minute search... -- Good code works. Great code can't fail. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp0PTSZawU9U.pgp Description: PGP signature
Re: Entropy of other languages
On Wed, Feb 07, 2007 at 05:42:49AM -0800, Sandy Harris wrote: > He starts from information theory and an assumption that > there needs to be some constant upper bound on the > receiver's per-symbol processing time. From there, with > nothing else, he gets to a proof that the optimal frequency > distribution of symbols is always some member of a > parameterized set of curves. Do you remember how he got from the "upper bound on processing time" to anything other than a completely uniform distribution of symbols? Seems to me a flat distribution has the minimal upper bound on information content per symbol for a given amount of information! -- Good code works. Great code can't fail. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpmipxzIhxBi.pgp Description: PGP signature
Re: Entropy of other languages
On Sun, Feb 04, 2007 at 03:46:41PM -0800, Allen wrote: > An idle question. English has a relatively low entropy as a > language. Don't recall the exact figure, but if you look at words > that start with "q" it is very low indeed. I seem to recall Shannon did some experiments which showed that with a human as your probability oracle, it's roughly 1-2 bits per letter. Many of his papers are online last time I looked, but some of his experimental results are harder to locate online. > What about other languages? Does anyone know the relative entropy > of other alphabetic languages? What about the entropy of > ideographic languages? Pictographic? Hieroglyphic? IIRC, it turned out that Egyptian heiroglyphs were actually syllabic, like Mesopotamian, so no fun there. Mayan, on the other hand, remains an enigma. I read not long ago that they also had a way of recording stories on bundles of knotted string, like the end of a mop. -- The driving force behind innovation is sublimation. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpyE3iyc6JFI.pgp Description: PGP signature
OTP, was Re: data under one key, was Re: analysis and implementation of LRW
On Sun, Feb 04, 2007 at 11:27:00PM -0500, Leichter, Jerry wrote: > | 1) use a random key as large as the plaintext (one-time-pad) > ...thus illustrating once again both the allure and the uselessness (in > almost all situations) of one-time pads. For long-term storage, you are correct, OTP at best gives you secret splitting. However, if people can get at your stored data, you have an insider or poor security (network or OS). Either way, this is not necessarily a crypto problem. The system should use conventional crypto to deal with the data remanance problem, but others have alleged this is bad or unnecessary or both; I haven't seen it proven either way. In any case, keeping the opponent off your systems is less of a crypto problem than a simple access control problem. It was my inference that this data must be transmitted around via some not-very-secure channels, and so the link could be primed by exchanging key material via registered mail, courier, or whatever method they felt comfortable with for communicating paper documents _now_, or whatever system they would use with key material in any other proposed system. The advantage isn't magical so much as practical; you don't have to transmit the pad material every time you wish to send a message. You do have to store it securely (see above). You should compose it with a conventional system, for the best of both worlds. Of course any system can be used incorrectly; disclosing a key or choosing a bad one can break security in most systems. So you already have a requirement for unpredictability and secure storage and confidential transmission of key material (in the case of symmetric crypto). The OTP is the only "cipher" I know of that hasn't had any cryptanalytic success against it for over 70 years, and offers a proof. [1] As an aside, it would be interesting to compare data capacity/density and networking speeds to see if it is getting harder or easier to use OTP to secure a network link. [1] Cipher meaning discrete symbol-to-symbol encoding. OTP's proof does rely on a good RNG. I am fully aware that unpredictability is just as slippery a topic as resistance to cryptanalysis, both being universal statements that can only be proved by a counterexample, but that is an engineering or philosophical problem. By securely combining it with a CSPRNG you get the least predictable of the pair. Everyone in reliable computing understands that you don't want single points of failure. If someone proposed that they were going to deploy a system - any system - that could stay up for 70 years, and it didn't have any form of backup or redundancy, and no proof that it wouldn't wear down over 70 years (e.g. it has moving parts, transistors, etc.), they'd be ridiculed. And yet every time OTP comes up among cryptographers, the opposite happens. When it comes to analysis, absence of evidence is not evidence of absence. > Anyway ... while the question "how can we keep information secure for > 70 years" has some theoretical interest, we have enough trouble knowing > how to keep digital information *accessible* for even 20 years that it's > hard to know where to reasonably start. I think that any long-term data storage solution would have to accept two things: 1) The shelf life is a complete unknown. By the time we know it, we will be using different media, so don't hold your breath. 2) The best way to assure being able to read the data is to seal up a seperate instance of the hardware, and to use documented formats so you know how to interpret them. Use some redundancy, too, with tolerance of the kind of errors the media is expected to see. 3) Institutionalize a data refresh policy; have a procedure for reading the old data off old media, correcting errors, and writing it to new media (see below). The trend seems to be that I/O capacity is going up much faster than I/O bandwidth is increasing, and there doesn't seem to be a fundamental limitation in the near future, so the data is "cooling" rapidly and will continue to do so (in storage jargon, temperature is related to how often the data is read or written). Further, tape is virtually dead, and it looks like disk-to-disk is the most pragmatic replacement. That actually simplifies things; you can migrate the data off disks before they near their lifespan in an automated way (plug in new computer, transfer data over direct network connection, drink coffee). Or even more simply, stagger your primary and backup storage machines, so that 1/2 way through the MTTF of the drive, you have a new machine with a new set of drives as the backup, do one backup and swap roles. Now your data refresh and backup are handled with the same mechanism. At least, that's what I'm doing. YMMV. -- The driving force behind innovation is sublimation. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp876Gxt2EB4.pgp Description: PGP signature
deriving multiple keys from one passphrase
Hey, quick question. If one wants to have multiple keys, but for ease-of-use considerations want to only have the user enter one, is there a preferred way to derive multiple keys that, while not independent, are "computationally independent"? I was thinking of hashing the passphrase with a unique string for each one; is this sufficient? If sufficient, is a cryptographically strong hash necessary? I got a clarification about the "use CRCs to process passphrase" idea someone mentioned. The salient bit is that he was using several CRCs (not sure if it's random or carefully chosen), and each one is run on the passphrase, and the output of all of them concatenated to initialize a PRNG seed. The passphrase and seed are both secret, so according to him there's no need to use a cryptographically strong hash, and CRCs have a well-understood mathematical basis. I presume this would be insufficient for deriving independent keys, but perhaps there is a way to do that with careful selection of the CRC polys? -- The driving force behind innovation is sublimation. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpgxzMEc4EYQ.pgp Description: PGP signature
length-extension and Merkle-Damgard hashes
So I was reading this: http://en.wikipedia.org/wiki/Merkle-Damgard It seems to me the length-extension attack (given one collision, it's easy to create others) is not the only one, though it's obviously a big concern to those who rely on it. This attack thanks to Schneier: If the ideal hash function is a random mapping, Merkle-Damgard hashes which don't use a finalization function have the following property: If h(m0||m1||...mk) = H, then h(m0||m1||...mk||x) = h(H||x) where the elements of m are the same size as the block size of the hash, and x is an arbitrary string. Note that encoding the length at the end permits an attack for some x, but I think this is difficult or impossible if the length is prepended. -- The driving force behind innovation is sublimation. -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpL5KPdwlGvf.pgp Description: PGP signature
data under one key, was Re: analysis and implementation of LRW
n a captured record? What is the budget? Who are the users? How competent are they? How much can we educate them? How will we fix bugs or update it? What are the security priorities? (usability, confidentiality, authenticity, integrity, availability, identification, authorization, repudiation) When the system fails, does it fail-safe or fail unsafe? What is the backup method when it fails? Can the main system be forced to fail by the opponent? What are the legal and economic considerations? That is, are the people who can best secure the system also the ones with the financial liability? If the patient is the beneficiary of the confidentiality, do they have any control over which system they use, or do they have any ability to make sure the system is secure? Who bears the cost of the system? Ultimately, a patient should be able to choose between priorities; if my drug allergies were stored on the system, and I had a heart attack and passed out, confidentiality and self-authorization would not be my primary concern. It's easy to imagine other scenarios with other priorities. In my experience, the last consideration (legal and economic) is the most common reason why systems fail. Compare the security of voting systems versus the security of slot machines and you'll see exactly how economics and self-interest trumps everything else. What you want to do is terribly difficult to do with any assurance, unless you're willing to spend a lot of money on it. I would recommend figuring out what you're trying to do, then hiring some consultants; cryptographers, systems analysts, penetration testers, professional engineeers on reliability, and so on. Brainstorm. Propose ideas and shoot them down. If your funds are limited, publication on the web, trade magazines, and a public email list plus referendum may be the best way to get free design critiques. Since "all bugs are shallow to one set of eyes", so too most weaknesses are obvious to some brain, and most failures are predictable by someone. The closer they are to the problem domain, the more valuable they are, but even stopped clocks are right twice a day. I'm thinking about unconditional security, and will write up a proposed design soon. I'll send it around when it's ready for public vetting. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpk3ZrReLV8W.pgp Description: PGP signature
block cipher modes and collisions
The wikipedia page on the IEEE SISWG debate about LRW says: "[A] general security requirement for any block cipher, regardless of mode of operation, is that no block cipher should be used to encrypt any more data, without changing the key, when the probability of a collision becomes not negligible (see also birthday paradox)." They must mean output collisions, rather than multiple preimages, but I think some modes will have collisions at a rate which depends on the plaintext (LRW being the obvious example)... but I've never heard of this security requirement before. Excepting the Handbook of Applied Cryptography, which I need to read, does anyone have another reference for this requirement, or others like it? I suppose that NIST might have published something like that in the various publications about block cipher modes, but don't know where to look exactly... -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> pgp39knc2U9V2.pgp Description: PGP signature
OT: SSL certificate chain problems
Hi, This is not really typical of the traffic on this list, hence the OT. I send it because I think this is one of the few places where I'll find some people with deep understanding of SSL certs. Recently I had an issue where Google checkout would not accept an SSL certificate because Apache didn't present the entire hierarchy, just the site certificate itself. The CA was Thawte. What Google said was that many browsers supply missing certs as needed, but apparently their software did not. The fix would seem to be easy; just put the right CA root cert in the SSLCACertFile directive. or point to the directory with SSLCACertPath. However, I've tried over and over with various root CA certs downloaded from Thawte, and with one intermediate CA cert, and various combinations thereof, but with no sucess. The troubleshooting command line Google gave us was: openssl s_client -connect www.domain.com:443 -showcerts < /dev/null Hi, This is not really typical of the traffic on this list, hence the OT. I send it because I think this is one of the few places where I'll find some people with deep understanding of SSL certs. Recently I had an issue where Google checkout would not accept an SSL certificate because Apache didn't present the entire hierarchy, just the site certificate itself. The CA was Thawte. What Google said was that many browsers supply missing certs as needed, but apparently their software did not. The fix would seem to be easy; just put the right CA root cert in the SSLCACertFile directive. or point to the directory with SSLCACertPath. However, I've tried over and over with various root CA certs downloaded from Thawte, and with one intermediate CA cert, and various combinations thereof, but with no sucess. The troubleshooting command line Google gave us was: openssl s_client -connect www.domain.com:443 -showcerts < /dev/null Which shows: depth=0 /C=US/ST=California/L=Los Angeles/O=Company, LLC/OU=COMPANY, LLC/CN=www.domain.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=California/L=Los Angeles/O=Company, LLC/OU=COMPANY, LLC/CN=www.domain.com verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=California/L=Los Angeles/O=Company, LLC/OU=COMPANY, LLC/CN=www.domain.com verify error:num=21:unable to verify the first certificate verify return:1 CONNECTED(0003) --- Certificate chain 0 s:/C=US/ST=California/L=Los Angeles/O=Company, LLC/OU=COMPANY, LLC/CN=www.domain.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA -BEGIN CERTIFICATE- [...] -END CERTIFICATE- --- Server certificate subject=/C=US/ST=California/L=Los Angeles/O=Company, LLC/OU=COMPANY, LLC/CN=www.domain.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA --- No client certificate CA names sent --- SSL handshake has read 1396 bytes and written 340 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: 0DD3301C8B8AF7BD3706A991475B22580AA32FCF85A141D753E2F051A691ED86 Session-ID-ctx: Master-Key: ... Key-Arg : None Start Time: 1169584627 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- DONE I can't seem to get that certificate chain to have any contents other than what you see above, no matter what I do, and hence can't get rid of the Verify return code: 21... does anyone have any advice on what to do next? URLs or references to other mailing lists welcome. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> pgpOnPmmhdFCX.pgp Description: PGP signature
Re: analysis and implementation of LRW
On Mon, Jan 22, 2007 at 10:56:06AM -0500, james hughes 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. Interesting... reference? Might look into CMC or EME: http://clemens.endorphin.org/LinuxHDEncSettings -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> pgpnQAfBIwqSi.pgp Description: PGP signature
Re: Private Key Generation from Passwords/phrases
On Sun, Jan 21, 2007 at 12:13:09AM -0500, Steven M. Bellovin wrote: > Could you explain this? It's late, but this makes no sense at all to > me. I probably wasn't clear, you bring out my realization that there are a number of unwritten assumptions going on here. > Similarly, the size of the output is irrelevant; we're not talking > about cryptanalysis here. Well, I can't disagree, since I also approved of truncating it to its original size, but I wouldn't want to induce collisions by making the salted input space much larger than the output space, or else the work factor goes down for the attacker, right? > that's not the only form of dictionary attack -- see M. > Bishop, ?An Application of a Fast Data Encryption Standard > Implementation,? Computing Systems 1(3) pp. 221?254 (Summer 1988), for > example. I'll have to look at that. > With 4K possible salts, you'd need a > very large password file to have more than a very few collisions, > though. It's only a benefit if the password file (or collection of > password files) is very large. Well, birthday paradox here, but what you say is true. IIRC, standard cracker practice back when tftp'ing password files was popular was to pool them all and sort by salt, then computing the most common salts and the most common passwords. > There is also some benefit if the attacker is precomputing > dictionaries, but there the size of the search space is large enough > that the salt factor isn't that important given even minimal quality > checks. Really? What about rainbow tables? I heard recently that there was a relatively complete MD5 rainbow table online with an ajax/js interface for searching it. Unless I'm missing something obvious, this basically eliminates the advantage of hashing unsalted passwords with MD5 to null. I look favorably on the formats that allow you to iterate a OWF over the password N times, and that store N in the entry. That way, if the costs of running the algorithm go down, you can just increase the number of times it has been run on every entry in the file without requiring any interaction from end-users. This kind of scaling with the world is needed, because cryptanalysis isn't a stagnant field, and Moore's Law still holds, and I find the idea of having to change between incompatible systems just to keep the same level of security, and on someone else's schedule, to be undesirable. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> pgpI8slDM82ce.pgp Description: PGP signature
Re: Private Key Generation from Passwords/phrases
On Fri, Jan 19, 2007 at 12:11:40AM -0800, Bill Stewart wrote: > One of the roots of the problem is that for many applications, > i is a well-defined event and P(i) is a fixed value (for i) , > but for many other applications, > i might not be a well-defined event, and/or > P(i) is really a conditional probability, P(i|other-stuff-you-know), > and it's hard to tell whether that's > usefully different from the non-conditional P(i). Yes; in textbooks, the author is usually kind enough to give a complete description of the source; in cryptanalysis, you're usually looking at the output and making inferences about the source, and thus, the entropy. > Another entropy example was the Venona decryptions - > people banging "randomly" on typewriters didn't actually produce > independent or identically distributed letters, > so the conditional probabilities didn't actually match > the assumed ones, so the entropy estimates were wrong, > and human language plaintext being what it is, > they really needed the 1-bit-per-bit of key entropy. Actually, my reading of a book on Venona said they captured some unused OTP on microfilm, but weren't able to use the non-randomness of the source to decrypt anything. Someone here mentioned that the entropy of the plaintext and the OTP have to merely add to 1 to prevent decryption; the OTP does not necessarily have to provide it all. Shannon's estimates were that English prose carries about 1 bit per symbol. There were some decrypts of material; the official explanation is that they recovered a partial codebook and discovered some OTP re-use (the KGB encoded then superenciphered it). BTW, dictionary attacks can probably be effectively resisted by making the hashes of passwords twice as big, and using a random value concatenated with the password before hashing, and storing it alongside the hash (it's like crypt(3) salting, but more so). If the password is important to keep from disclosure beyond the needs of this security system, one could even truncate the output of the hash to half its size, so that there's multiple preimages; since you doubled the hash size to begin with, you end up with the same security factor against guessing, I believe. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> pgpJoxUCemN6j.pgp Description: PGP signature
Re: gang uses crypto to hide identity theft databases
On Sun, Dec 24, 2006 at 11:10:40PM +, Rick van Rein wrote: > This is not =entirely= true. A key stored in the same (non-swappable) > location for a long time will burn into the memory. (I know that I am > reacting beside the point of your story, to which I agree.) Pimpin' Peters Papers: http://www.cypherpunks.to/~peter/usenix01.pdf -- A: No. Q: Should I include quotations after my reply? http://www.subspacefield.org/~travis/> -><- pgp8gThz9AZST.pgp Description: PGP signature
Skype reverse-engineering details]
Some very juicy details here: http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pd -- "Cryptography is nothing more than a mathematical framework for discussing various paranoid delusions." -- Don Alvarez http://www.subspacefield.org/~travis/> -><- --- Begin Message --- Trying this again... hopefully the envelope sender gets set right. Some very juicy details here: http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pd -- "Cryptography is nothing more than a mathematical framework for discussing various paranoid delusions." -- Don Alvarez http://www.subspacefield.org/~travis/> -><- pgpDsDeOH8h78.pgp Description: PGP signature --- End Message --- pgpSmV0dqE60W.pgp Description: PGP signature
Re: Traffic Analysis References
On 10/19/06, Leandro Meiners <[EMAIL PROTECTED]> wrote: Can anybody point me to any good references regarding traffic analysis? This is the only interesting page I found on it: http://guh.nu/projects/ta/safeweb/safeweb.html There are some historical incidents that are sufficiently old to be unclassified: For example, the Japanese left their normal morse operators behind when setting sail for Pearl Harbor. They continued to send transmissions as though they were still in Japan's waters. Morse operators are fairly identifiable by their rhythm and idiosyncrasies, known collectively as their "fist". It's just like any other behavior performed subconsciously, like typing or signing your name; at first there's a lot of variation, and later it becomes fairly fixed and potentially identifying. Also during WWII, a year before D-Day, the Allies in Scotland created a radio net that purported to be a [nonexistent] 4th Army, ostensibly to feint towards southern Norway. The purpose behind this was to further dilute Axis forces, to keep them far enough away to be unable to participate around Normandy (there were, obviously, numerous deception operations around D-Day). This last bit is well documented in "The Codebreakers", which also has numerous entries in its appendix for Traffic Analysis. I suspect that in many instances where traffic analysis was useful, it was necessary to make (or learn) certain assumptions about typical traffic patterns; that is, orders come from the top and are disseminated down the military hierarchy, etc.; that requests for supplies, battle damage assessments, and other feedback flows up from the front-line troops to the logistic units or field commanders; that traffic increases as one approaches a major military operation, etc. In other words, it's context-specific, and may resist generalization into easily-remembered axioms. Also, the mixmaster and cypherpunk remailers, AT&T's crowds, and the onion-routing groups, probably have some papers considering various traffic analysis and correlation attacks against those systems since they are encrypted inside the mixers. One thing I have been interested in is the security of typical plaintext Internet protocols when "secured" with SSL/TLS/IPSec. If they don't do any padding, then the length of each step of the protocol is effectively given away; just count how much data passes to the recipient before data starts flowing in the opposite direction. Also, there is timing information, and it is fairly well preserved even across the Internet (see the timing side channel attacks against SSL). Even if there is padding, which is basically wasted bandwidth, it may still be possible to discern information. I've been thinking about this, and I am not sure how to entirely avoid it without running into other problems. For example, Unix's configuration files and application-level TCP/IP protocols are very easy to interpret and troubleshoot thanks to their human-readable strings. The typical encrypted protocol uses non-textual, constant-length messages, which can make it difficult to extend without introducing incompatibilities (or even making different responses different lengths again, the worst of both worlds). One doesn't typically need very extensive decoding algorithms in order to make the plaintext data human-readable, which is good because those decoding libraries are also processing data from remote (untrusted) entities and form part of the attackable surface, and have proven to be security holes on more than one occasion. One alternative I came up with is to send the entire catalog of possible responses at the beginning of the transmission, then refer to them by a fixed-length index. This would be a lot of overhead in many cases. Another alternative is to have a standard catalog, something like an MIB, that may be cached between invocations. Nevertheless, there are many times during a protocol that you wish to dynamically construct a response without knowing it a priori; it would seem difficult to deal with those cases in any other way. These approaches could be implemented simultaneously, and perhaps one only needs to pad when sending variable-length messages, so that "normal" common messages don't incur any overhead (at the cost of fixed-length and variable-length messages being distinguishable sets, but not distinguishable individually). In this way it is similar to what cryptologists were doing with telegraph codebooks, which encoded standard phrases in relatively similarly sized units, but had to spell out anything not in the codebook using many codes (each signifying one letter or part of a word). If you come across any other links, please let me know as I'd like to add them to my page on side-channel attacks: http://www.subspacefield.org/~travis/side_channel_attacks.html -- "It's not like I'm e
hashes on restricted domains: random functions or permutations?
So I was reading about the OTP system (based on S/Key) described in RFC 2289. It basically hashes a secret several times (with salt to individualize it) and stores the value that the correct password will hash to. Now my question is, if we restrict ourselves to, say, 160-bit inputs, is SHA-1 a permutation, or do collisions exist? If there are collisions, then iterating the hash could lead to fewer possible values each time, potentially converging on a set of inputs that form a permutation and are closed under composition. Is that correct? What are the expected sizes of such sets? Is it worth worrying about? -- "The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.'' [sic] -- Bill Gates -><- http://www.subspacefield.org/~travis/> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
On 10/12/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote: Beyond that: Are weak keys even detectable using a ciphertext-only attack (beyond simply trying them - but that can be done with *any* small set of keys)? Yes, generally, that's the definition of a weak key. But that's an odd attack to defend against - why not just try all the weak keys (or, again, any small subset of keys) and see if they work? Because that's the definition of brute forcing, and generally the key distribution is close to uniform in any [symmetric] system that is worth a second glance? do "continuous online testing": Compute the entropy of the generated ciphertext, and its correlation with the plaintext, and sound an alarm if what you're getting looks "wrong". This is a decent idea. Of course, there are scads of problems that are not detectable by a simple memoryless markov model, but this would be a decent sanity check on all but the smallest of plaintexts. I would also want continuous monitoring of my HWRNG outputs; maybe I wouldn't want a simple entropy check, which a properly-functioning HWRNG will fail with a probability predicted by chance, but perhaps a graphical display of the previous values. I'm not a visual thinker, but I don't think any amount of statistics are going to be as useful in detecting deviations from uniformity as a plot and a human brain. -- "The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.'' [sic] -- Bill Gates -><- http://www.subspacefield.org/~travis/> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TPM & disk crypto
On 10/9/06, Adam Back <[EMAIL PROTECTED]> wrote: The bad part is that the user is not given control to modify the hash and attest as if it were the original so that he can insert his own code, debug, modify etc. (All that is needed is a debug option in the BIOS to do this that only the user can change, via BIOS setup.) Actually, it's the BIOS I don't trust. I can validate everything else, but as long as the BIOS is motherboard-specific and closed source, I don't see why I should trust it. We need to get rid of this legacy crud. LinuxBIOS is a good step but unfortunately it is only supported on a few motherboards. No BIOS I know of has a semblance of security, given temporary physical access to the machine. BTW, the x86 microcode updates are performed by the BIOS IIRC and require no hardware settings. Is there any reason you can't update the processor microcode later on in the boot process? -- "The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.'' [sic] -- Bill Gates -><- http://www.lightconsulting.com/~travis/> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
handling weak keys using random selection and CSPRNGs
Hi all, It occured to me that there is a half-decent way to avoid weak keys in algorithms when it is undesirable or impossible to prompt the user for a different passphrase. It is even field-upgradable if new weak keys are found. Basically, instead of using the hash of the passphrase up front, you do a PRNG expansion of the passphrase. For example, k_1 = hash(1||passphrase) k_2 = hash(2||passphrase) and so on. The important thing here is that it is not something like the following: k_1 = hash(passphrase) k_2 = hash(k_1) ... k_n = hash(k_(n-1) In that method, the number of input states is limited by the hash size, whereas the former algorithm has a number of states that the k sequence can be in is limited by the size of the passphrase. I suppose that a running hash would be limited by the size of the hash state (chaining variables). Next you construct k = k_1 || k_2 || ... k_n The computation can be done incrementally on an as-needed basis. Then, you read in the number of weak keys, and perform a random selection on the number of valid keys using the algorithm I posted earlier, with k as the source of unpredictability. This leaves you with a random number between 0 and the number of non-weak keys minus one. Then you iterate over the weak keys in numerical order, incrementing the value from the previous step by one if it exceeds the weak key's numerical value. This part runs in time linear with the number of weak keys, not the size of the non-weak keyspace. You are left with a value that has a uniform distribution over the non-weak keys. The random selection algorithm may run indefinitely, but the chances of that are infinitesimal. If there are a huge number of weak keys, then it may take longer, but I'd be willing to bet that CPU speed increases faster than discovery of weak keys, and if it doesn't the user might be inconvenienced enough to upgrade to a less broken cipher algorithm. -- "The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.'' [sic] -- Bill Gates -><- http://www.lightconsulting.com/~travis/> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
cryptography@metzdowd.com
First, I found this interesting site by John Savard which discusses the various crypto designs since... well, since pencil and paper systems. Notable is the detailed discussion of the declassified SIGABA machine: http://www.quadibloc.com/crypto/jscrypt.htm Next, can anyone point me in the direction of any web references on using FPGAs to implement cryptographic (or other) algorithms? I would like the speed of hardware, but feel that it is necessary to amend the algorithms as the state of the art advances. I've also wanted to do some low-level hardware interfacing. Have there been any attempts to construct ciphers based on a key or random number? It would be interesting to see a family of ciphers from which one is chosen periodically, in addition to re-keying. I suppose that one could permute S-tables in Feistel-type ciphers fairly easily (a la traditional Unix crypt() salt), but have there been any more general efforts, perhaps using virtual machines or lisp? I do realize that an algorithm is already parameterized by the key, but the general structure remains the same. I found this amazing paper on sandboxing x86 code (software-based fault isolation), and due to some engineering the overhead is pretty minimal (20% on SPECint2000): http://www.usenix.org/events/sec06/tech/mccamant.html Using a method like this between two systems with the same instruction set, the crypto protocol initiator could even send the algorithm they want to use to encrypt, compress, or otherwise transform the rest of the session, and the recipient could ostensibly execute it safely, and vice-versa. If any of you are die-hard assembly or algorithm mavens, this book might interest you: http://www.amazon.com/Hackers-Delight-Henry-Warren-Jr/dp/0201914654 -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
deriving multiple keys from one passphrase
What is the accepted way to derive several keys from a user-supplied input? Or, can you see anything wrong by prepending a counter to the passphrase and hashing it to create derived keys? k_n = hash(n || passphrase) I suppose a faster system would involve using hash(passphrase) as the key and encrypting a counter (assuming that hashes are slower than block ciphers). k_n = E(hash(passphrase), n) Both seem vulnerable to dictionary attacks, and it's not immediately clear to me how I could prevent them, or if that's even possible. Terry Ritter suggested using CRCs over the passphrase, but I haven't really analyzed that method at all. Any opinions? -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TPM & disk crypto
On 10/5/06, Erik Tews <[EMAIL PROTECTED]> wrote: First, you need a system with tpm. I assume you are running linux. Then you boot your linux-kernel and an initrd using the trusted grub bootloader. Your bios will report the checksum of trusted grub to the tpm before giving control to your grub bootloader. Your grub bootloader will then report the checksum of your kernel and your initrd to the tpm before giving control to them. Awesome, that's incredibly useful information. I had not heard of trusted grub. Thanks! One thing you should know is, that a tpm can never find out, if a software meets some specifications, like does not have an buffer overflow or does not execute code from the network or so. You just can check is has not been altered. Of course. However, you can sandbox x86 code efficiently: http://www.usenix.org/events/sec06/tech/mccamant/mccamant_html/index.html -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TPM & disk crypto
On 10/2/06, Erik Tews <[EMAIL PROTECTED]> wrote: Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: > Anyone have any information on how to develop TPM software? http://tpm4java.datenzone.de/ Using this lib, you need less than 10 lines of java-code for doing some simple tpm operations. Interesting, but not what I meant. I want to program the chip to verify that the BIOS, boot sector, root partition conform to *my* specification. I don't want binary-only hardware-enforced vendor lock-in, that went out of fashion with the mainframe and proprietary data[base] formats. -- TH - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
wanted: mod arith equivalences/tautologies
Hey does anyone have a good link for the various equivalencies (or inequivalencies) for modular arithmetic? I realize some will only apply to certain moduli, especially primes. I'm basically wanting to find some good algorithms for certain simple computations, like f(x) = ax + b (mod n), or the BPP digit extractor for Pi, but for very large values. I'm hoping to do them in ocaml or python. -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
The Geheimschreiber Secret - Swedish WWII SIGINT
http://frode.home.cern.ch/frode/ulfving/ulfving.html This discusses Swedish decryption of a German crypto machine. Although the break was done without any hints, it was a fairly straightforward system of long-period XOR and fixed transposition, and eventual success was predicated on the laziness of the operators (what else is new?). Perhaps someone can make this into some form of game-theoretic research paper. An interesting economic commentary, if somewhat off-topic, is: ``Many analysts consider that war preparations serve only as instruments of pressure during negotiations. However, that ignore the dynamics of future military developments which are created by a deployment as large as that which occurred here. Economic factors and military logistics make it almost impossible to keep large, inactive troop concentrations in place as a trump card during long negotiations, just as it is damaging for the units' fighting spirit. It is too expensive not to use the troops, therefore they must either be used in combat or be demobilized and returned to civilian life. Only victory justifies the price -- even if it is high. For example, consider the collapse of the economic, political and ecological systems now affecting the states of the former Soviet Union as a consequence, during a long period, of a highly forced ``war economy'' that did not result in any gains.'' Perhaps the "mission creep" seen in most large bureaucracies need not always be attributed to power-grabs and personal aspirations of department leaders, but to relatively benign economic arguments that "we already pay for it, we might as well use it". Along with the idea that capabilities must periodically be exercised in order to prevent atrophy, that probably explains a lot of otherwise puzzling decisions and apparent over-reactions on the part of decision-makers. -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
TPM & disk crypto
Quoting: Disk drives gear up for a lockdown Rick Merritt, EE Times (09/25/2006 9:00 AM EDT) Built-in security is the next big thing for hard-disk drives. By 2008, drive makers should be shipping in volume a broad array of drives based on a maturing standard. ... The first version of the Trusted Computing Group's standard for disk drive security could be completed by year's end. Seagate Technology Inc. already ships one drive with an integrated security chip, although some see that approach as an interim step. "For mass production, security has to be integrated into the controller. It's not that many gates, even if the function is not used," said A. Currie Munce, vice president of research for Hitachi Global Storage Technologies. Seagate CTO Mark Kryder agreed, saying his company will integrate security functions in the drive controller very soon. A security standard will open the door to selling drives preloaded with content that users can unlock after paying online for a digital key...' === Anyone know if this is going to be compatible with the IEEE SISWG standard? Anyone have any information on how to develop TPM software? Anyone else recognize how features migrate from the CPU to an add-on card and back to the CPU? Same thing happened with RAID and on-board video and so on... it seems to me that people need an open-source add-in card for crypto, perhaps based around an FPGA, that is updatable if the algorithms need strengthening. It seems that Peter Gutmann has already done something similar: http://www.cypherpunks.to/~peter/usenix00.pdf -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 9/26/06, Richard Salz <[EMAIL PROTECTED]> wrote: Really, what? There are things it doesn't do, but since it's only a packaging format that's a good thing. Though there are unshar tools, typically people run it as input to /bin/sh, usually without reading through it (and given the level of obfuscation sh offers, it's not clear that you couldn't sneak something through even if the person skims it). -- Enhance your calm, brother; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 9/15/06, Taral <[EMAIL PROTECTED]> wrote: *That* is the Right Way To Do It. If there are variable parts (like hash OID, perhaps), parse them out, then regenerate the signature data and compare it byte-for-byte with the decrypted signature. You know, this sort of reminds me of a problem with signatures on tar.gz files. Basically, you have to keep them around so you can check the signature, but you can't delete them because you can't reconstruct the original tar file from an untarred copy because it's full of metadata that won't necessarily be replicated on your system. For example, uids and gids. Unfortunately, cpio appears to be worse. From a tape backup standpoint, tar doesn't store enough (extended attributes, hard links, etc.) and so it appears to store both too much and too little at once. It would be nice if there was a format other than shar which was deterministic and only contained the contents of the files; no metadata. Then we could sign the code and nothing else. From a security point of view, shar has obvious problems :-) Anyone know of a relevant tool? -- Enhance your calm, brother; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IGE mode is broken (Re: IGE mode in OpenSSL)
On 9/9/06, Adam Back <[EMAIL PROTECTED]> wrote: IGE if this description summarized by Travis is correct, appears to be a re-invention of Anton Stiglic and my proposed FREE-MAC mode. However the FREE-MAC mode (below described as IGE) was broken back in Mar 2000 or maybe earlier by Gligor, Donescu and Iorga. I recommend you do not use it. There are simple attacks which allow you to manipulate ciphertext blocks with XOR of a few blocks and get error recovery a few blocks later; and of course with free-mac error recovery means the MAC is broken, because the last block is undisturbed. http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st I don't see why integrity+confidentiality has to cost n log n operations. I haven't read the whole paper yet (and the proof is at the end), but I don't see why you can't append a universal hash (chosen by a second key, or at random and identified in the plaintext in some suitable way) of the input to the plaintext prior to encryption, and get integrity for cheap. Or are universal hashes considered cryptographic-weight primitives, and thus this constitutes a "second pass" over the plaintext? I must admit I don't know of any lower bound on universal hash complexity... wikipedia only mentions f(x) = ax + b mod p, (p prime) which is clearly less heavy than modexp and other PK algos, and it looks like you could do it incrementally over the plaintext x, I think... my intuition tells me this is way faster than a block cipher. -- "On the Internet noone knows you're a dog - except Bruce Schneier." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Did Hezbollah use SIGINT against Israel?
On 9/20/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote: Newspaper reports have claimed that many troops were sent into the field with old equipment - including in particular 10+-year-old communications equipment. The Single Channel Ground and Airborne Radio System was designed in the 80's: http://www.fas.org/man/dod-101/sys/land/sincgars.htm I don't know the hop frequency, but it's probably smaller than modern standards (could possibly be followed with real-time tracking), it probably uses a manually-entered seed to generate a hop sequence, the PRNG that stretches the seed is probably not secure any more, and the input space is probably searchable by now in a reasonable amount of time. Further, once broken with some expensive hardware (maybe a custom-designed SIGINT SDR), they could program much cheaper units to follow the sequence until the Israelis re-keyed. Just my total guess. -- "On the Internet noone knows you're a dog - except Bruce Schneier." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
On 9/15/06, Daniel Carosone <[EMAIL PROTECTED]> wrote: But let's not also forget that these criticisms apply approximately equally to smart card deployments with readers that lack a dedicated pinpad and signing display. This looks mildly interesting: http://www.projectblackdog.com/product.html I guess it uses an autorun file on Windows; I wonder whether most systems allow you to effectively launch X. The docs say it connects via ethernet over USB, so you're effectively a thin X client. Nice that it's open-source. Good idea, still vulnerable to software surveillance and host OS. No display. This looks more interesting: http://fingergear.com/bio_computer_on_a_stick.php This has a display, a fingerprint reader, runs Linux, has many common apps (office-compatible suite), IM, etc. More relevant to the list, it has a OTP generator, so this is effectively a security token. See: http://fingergear.com/faq1.php#4 Unfortunately, it looks like you can't reimage it without wiping everything, and then you lose the OS. I hope you can get a modifiable OS image and install it just as one would save data to the USB drive, but it could be impossible. The worst cost for these more advanced methods may be in user acceptance: having to type one or more things into the token, and then the response into the computer. A USB connected token could improve on this by transporting the challenge and response, displaying the challenge while leaving the pinpad for authentication and approval. I wonder if the ubiquitous fingerprint reader could replace the need for lots of buttons; controls tend to be the most expensive and fragile part of electronic devices. I wonder why nobody has an open-source cell phone that does voice recognition yet. That would seem to be the ideal solution, wouldn't it? You're already carrying one around, and you have a keypad for dialing (can be used for PIN), LCD panel for output, and if you have a fingerprint reader, enough juice to perform some crypto, and a USB or bluetooth connector (for storage and communication) it'd be perfect. -- "On the Internet noone knows you're a dog - except Bruce Schneier." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IGE mode is broken (Re: IGE mode in OpenSSL)
On 9/10/06, James A. Donald <[EMAIL PROTECTED]> wrote:
Typo:
> We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
> means bitwise or, curly brace means encryption.
Should read:
We transmit T(k) = {W(k)} + ((~W(k-11){W(k-1)})
where ~ means bitwise negation, | means bitwise or,
curly brace means encryption.
Today wasn't a good day for typing? ;-)
T(k) = {W(k)} + (~W(k-1)|{W(k-1)})
Right?
I'm in agreement with the "don't use a screwdriver as a crowbar"
crowd; unless the combined modes came with clear proofs and
very weak assumptions computers are fast and getting faster,
and my performance needs remain relatively constant.
--
"On the Internet noone knows you're a dog - except Bruce Schneier."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
secure key storage APIs
Hey, Does anyone know of any OSS OS facilities for managing keys? With ssh-agent and gpg-agent providing access to key storage by inherited processes, and the keys themselves being vulnerable as stored on-disk, I wonder if there isn't any more general facility for doing key management and access control, and I was wondering if there were any useful papers on this kind of facility. As I see it, there are a couple of seperate issues: 1) Persistent key storage; how does it look on-disk? Obviously we will want confidentiality, and probably have integrity. But what kind of algorithm do we use? When designing key storage for a given system, one can usually use that system to access the persistent form. This has the neat property that a break in the storage security would imply that the given system itself could have been broken, so no harm done; the "attack surface" is not increased by the key store subsystem. 2) Non-persistent key store; there are data remanence issues with DRAM and other supposedly non-persistent storage. I have heard a story about a homebrew computer that stored the "clean shutdown" or "dirty" bit in the same memory location, and after a reboot it would read this location to decide if it needed to check the disks. Apparently it stayed "dirty" so long the value was burned-in. Maybe not a big deal for key store in a complex environment, but would be really important in embedded devices with fairly static memory layouts, e.g. VPN concentrators. Solve by secret-sharing between two locations, or by inverting every bit periodically. 3) Access control policy; who should get access to the keys? 4) OS support; should keys be stored as immutable quantities, like a process's real UID value? If so, can they be transferred, and under what conditions? Can they be inherited? Any considerations that I'm missing? -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
link fest on fingerprint biometrics
Found at doxpara.com: fingerprints: http://chris.fornax.net/biometrics.html faceprints: http://www.site.uottawa.ca/~adler/publications/2003/adler-2003-fr-templates.pdf More on fingerprints: http://onin.com/fp/cyanoho.html At home I have an excellent page on making fake fingerprints, but I cannot find it right now. It used gelatin (like jello) and was successful at fooling a sensor. I did find this, which reports success with gummi bears: http://msn.pcworld.com/article/id,116573-page,5/article.html This says play-doh works on Walmart and Target sensors: http://digg.com/security/Play-Doh_Beats_Wal*Mart_s_and_Target_s_Fingerprint_Scanners?cshow=927041 Or more generally: http://www.linuxelectrons.com/article.php/20051209175034721 More about fingerprints: http://www.latent-prints.com/ If anyone can give me any fingerprint-related links, particularly about spoofing/breaking them, I would be grateful. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IGE mode in OpenSSL
The NIST server is down. Care to post the algorithm? By the term "crib" do you mean a known-plaintext? I'd like to see a proof that it is not possible to alter the final block to make it decrypt to all zeroes; that seems worse than CRCs and putting a CRC at the end of the plaintext is a common, and often broken, way to do integrity checking, because it's linear and allows the opponent to toggle bits in the plaintext and fix the CRC without breaking the encryption. I don't see how appending a hash of the plaintext could be a crib. The encryption prevents the opponent from knowing the plaintext, so he wouldn't know what the hash preimage is. If you encrypt the hash, you basically have HMAC without using a keyed hash. There are block modes that do integrity and encryption at the same time; does this offer and advantage over them, and if so how? -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IGE mode in OpenSSL
Nevermind the algorithm, I saw the second PDF. For the other readers, the algorithm in more standard variable names is: c_i = f_K(p_i xor c_(i-1)) xor p_(i-1) IV = I suppose the dependency on c_(i-1) and p_(i-1) is the part that prevents the attacker from predicting and controlling the garble. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
signing all outbound email
Has anyone created hooks in MTAs so that they automagically sign outbound email, so that you can stop forgery spam via a SRV DNS record? -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
correction to uniformly random selection algorithms
I just realized I made a small error in algorithm 2. On 9/2/06, Travis H. <[EMAIL PROTECTED]> wrote: 2. This algorithm seems to waste fewer bits: Initialize with c = 0. x = extraction of n bits That should read: x = extraction of ceil(lg(p-c)) bits Otherwise there's nothing gained by carrying the remainder c. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
uniformly random selection algorithms
I didn't know about this RFC, but apparently the IETF has a standard for selecting people randomly for sortition in a publicly-verifiable way. References: http://rfc.sunsite.dk/rfc/rfc3797.html http://www.isi.edu/in-notes/rfc3797.txt This got me to thinking about random selection. They take several publicly-verifiable randomly generated numbers (such as government-run lotteries), concatenate them in an unambiguous way, and then hash each one (with a sequence number prefixed and suffixed), treat the results as a 128-bit big-endian integer, and take the remainder after division by the remaining pool size (i.e. without replacement). However, there's a slight bias for people towards the front of the pool; for demonstration, assume we start with a uniformly random 8-bit number instead of 128-bit, on a pool size of 100. These numbers are selected to exaggerate the bias. The first 55 people have 3 opportunities to win; person 0 has 0, 100, and 200. However, person 56 has only two; 56 and 156. It's a minor point for small pools and 128-bit integers, but wouldn't it be mathematically more uniform to create a pseudorandom stream from the hashed outputs and then apply one of the following algorithms? Assume a pool size p, lg means binary logarithm, n=ceil(lg(p)) and x is an unsigned big-endian integer: 1. Trial-and-error: x = extraction of n bits If x < p, then return x. Otherwise, discard and repeat. 2. This algorithm seems to waste fewer bits: Initialize with c = 0. x = extraction of n bits. Let y = x+c If y < p, then return y Otherwise, let c = y - p Go back to the extraction step. 3. This may be more efficient still; Pick b such that 2^b >> p (e.g. p=100, b=128) Let q = floor(2^b/p) y = one of the earlier algorithms with p=pq Return y mod n In this last algorithm, b is chosen to be a computationally-convenient size (e.g. size of the hash output). PS: In case anyone doesn't know, Lynn Wheeler's RFC index is amazing. Best RFC interface ever: http://www.garlic.com/~lynn/rfcietff.htm -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Debunking the PGP backdoor myth for good. [was RE: Hypothesis: PGP backdoor (was: A security bug in PGP products?)]
On 8/28/06, Ondrej Mikle <[EMAIL PROTECTED]> wrote: Take as an example group of Z_p* with p prime (in another words: DLP). The triplet (Z, p, generator g) is a compression of a string of p-1 numbers, each number about log2(p) bits. Pardon my mathematical ignorance, but isn't Z just a notation to indicate a ring, as opposed to a parameter that you'd have to store? -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: compressing randomly-generated numbers
On 8/29/06, Alexander Klimov <[EMAIL PROTECTED]> wrote: 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. Well, this is a fairly strict definition, I think uniform and e-close to independent is still potentially suitable for use in cryptography. > or a computationally-pseudorandom stream, This requires a random key. I can't use e-close to (uniform and independent)? 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. I hear this argument often, and it appears that the people who say it don't care about the rate of random bits, nor the desirability of not having to trust any one source to be truly unpredictable, nor have they understood the point of an extractor or hashing the output of multiple sources. For example, I'd like to use the Quantis HWRNG, but since it is an opaque container, then I cannot trust it fully. If I had another source that I could combine with it, then I do not have to trust it blindly; the opponent would have to compromise both in order to be able to predict the combined output. 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. No, you have no idea of the unpredictability of that source, because it is unspecified and unpredictability is untestable. That could very well be the output of a perfect HWRNG. So could 01010101, or 000, or 111. Each output is equally likely, and no amount of testing the output can say whether the source is imperfectly random or truly random. This was stated several times on this list; entropy depends on the model of the source, not on the output. The sequence: 0, 1, 2, 3, 4... 255, 0, 1, 2, 3, 4... 255 ... has a zero entropy if the source is defined as "an 8-bit counter starting at zero", and it has an entropy of 1 if the source is defined as "a HWRNG that generates 8-bit outputs in a uniform and independent manner". Re-read the definition of entropy, and pay particular attention to the calculation of probability for a given event. Interestingly, an additional requirement that the input stream has at least two bits of entropy does not change the situation I didn't understand this example. See above about ``sampling at a slower rate.'' I can take an analog random source, and sample it at one rate, and have a nearly independent stream. If I increase the sample rate, the bits will start to become more and more dependent upon the prior bit. So, if that is true, then logically a serially-correlated stream will become less and less correlated as I decrease the sample rate. Taking every other bit corresponds to sampling at half the speed, but doesn't require modifying the hardware. It seems that you are saying there is no general solution, given a total lack of knowledge about the source other than the fact that there is some dependency between the bits. I can agree with that. However, if you understand the physics of the source, then you do know something about the random phenomenon used as a source, and in that case you can eliminate specific kinds of dependencies that it may exhibit. The easiest way to eliminate (computationally) bias and dependency in one step is to combine with a CSPRNG. You can reseed it periodically with the combined output. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Hypothesis: PGP backdoor (was: A security bug in PGP products?)
On 8/23/06, Ondrej Mikle <[EMAIL PROTECTED]> wrote: We discussed with V. Klima about the "recent" bug in PGPdisk that allowed extraction of key and data without the knowledge of passphrase. I skimmed the URL and it appears this claim was answered several times in the original thread. Did you not read it, or not understand it? You have to have a valid passphrase from before the change, because the passphrase unlocks the disk key which doesn't change, unless you explicitly tell it to. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A security bug in PGP products?
On 8/23/06, Dave Korn <[EMAIL PROTECTED]> wrote: Given that, whatever passphrase you use, you will decrypt the EDK block and get /something/ that looks like a key, this comparison of hashes is a sanity test. If you bypass it but enter the wrong passphrase, you'll get an incorrectly-decrypted EDK, which will lead your disk to look like every sector is full of random garbage. Rather than decrypt the entire disk and run chkdsk to see if it looks sane, comparing the hashes of the passphrase is a quick and dirty way of testing if the resulting EDK is going to be the correct one. The PGP email encryption has two known-plaintext bytes for that purpose. This only honors a bad key 2^16 of the time, but ensures that brute-forcing must do a more extensive unknown-plaintext attack at that rate for any potentially-correct key. This reminds me a little of the suggestions that MACs should be truncated, although it seems to me that it's better to encrypt a hash of the plaintext. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
CRCs and passphrase hashing
Howdy! I was talking to Terry Ritter, and he was explaining to me that when he needed to make some keys from a user-supplied passphrase, he computed various CRCs over the passphrase, and used those as derived keys. I'd like to know more about it, and I was wondering if anyone knew of any work that addressed the strength of this kind of passphrase preprocessing. Forgive me for not being able to hit the ground running after reading the explanation from mathworld, as I don't have a degree in discrete math. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
collisions in 64 round variant of SHA-1 with 25% chosen plaintext
http://www.heise-security.co.uk/news/77244 ``Although the demonstration was restricted to the reduced SHA-1 variant in 64 steps, it can, according to the experts, also be generalised to the standard 80 step variant. This means that SHA-1 must also be considered as cracked in principle. Christian Rechberger, who developed the new attack together with his colleague Christophe De Cannière, explained to heise Security that, in their experiments, up to one quarter of the message could be freely selected. The remaining 75 percent is, as before, determined by the attack. Rechberger suspects, however, that the amount that can be freely selected can be further increased by optimising the attack.'' -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
setting up a CA with OpenSSL
Figured some people might be interested in doing this. I know how it all works (or fails to) on a theoretical level, but never actually implemented it. This page is very helpful: http://sial.org/howto/openssl/ca/ If anyone has any criticisms about this procedure as described, please speak out... -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
