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
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
