Re: [cryptography] Duplicate primes in lots of RSA moduli

On Thu, Feb 16, 2012 at 12:28 PM, Jeffrey Schiller wrote: >> Are you thinking this is because it causes the entropy estimate in the RNG >> to be higher than it really is? Last time I checked OpenSSL it didn't block >> requests for numbers in cases of low entropy estimates anyway, so line 3 >> w

Re: [cryptography] Applications should be the ones [GishPuppy]

On Thu, Feb 16, 2012 at 8:45 PM, <2...@gishpuppy.com> wrote: > Nico Williams wrote: > >> Applications (in the Unix sense) should not be the ones seeding the > system's PRNG.  The system should ensure that there is enough entropy > and seed its own PRNG (and mix in

Re: [cryptography] Applications should be the ones [GishPuppy]

Note that there may be times when the application definitely should initialize a PRNG (seeded from the OS' entropy system -- I still maintain that the whole system needs to work well). For example, when using cipher modes where IVs/confounders need to be random but also not re-used. In that case

Re: [cryptography] Duplicate primes in lots of RSA moduli

On Fri, Feb 17, 2012 at 2:39 PM, Thierry Moreau wrote: > If your /dev/urandom never blocks the requesting task irrespective of the > random bytes usage, then maybe your /dev/random is not as secure as it might > be (unless you have an high speed entropy source, but what is "high speed" > in this c

Re: [cryptography] Duplicate primes in lots of RSA moduli

On Fri, Feb 17, 2012 at 2:51 PM, Jon Callas wrote: > On Feb 17, 2012, at 12:41 PM, Nico Williams wrote: >> On Fri, Feb 17, 2012 at 2:39 PM, Thierry Moreau >> wrote: >>> If your /dev/urandom never blocks the requesting task irrespective of the >>> random bytes u

Re: [cryptography] Homomorphic split-key encryption OR snake oil crypto

On Sun, Feb 19, 2012 at 10:08 AM, Florian Weimer wrote: > * Saqib Ali: > >> Can somebody explain me how this so-called Homomorphic split-key >> encryption works? > > Isn't this just a protocal which performs a cryptographic primitive > using split key material, without actually recombining the key

Re: [cryptography] Homomorphic split-key encryption OR snake oil crypto

My guess is that since fully homomorphic systems will be very slow that one could use it to guard just a tiny secret. But what's the point? Who cares if you can protect the customer's keys, if you can't protect the customer's plaintext data? Nico -- __

Re: [cryptography] Duplicate primes in lots of RSA moduli

On Mon, Feb 20, 2012 at 7:07 AM, Ben Laurie wrote: > In FreeBSD random (and hence urandom) blocks at startup, but never again. So, not exactly a terribly wrong thing to do, eh? ;) What OSes have parallelized rc script/whatever nowadays? Quite a few, it seems (several Linux distros, MacOS X, So

Re: [cryptography] Certificate Transparency: working code

On Thu, Mar 1, 2012 at 3:14 PM, Thierry Moreau wrote: > May I ask a (maybe stupid) question? > > "... audit proofs will be valid indefinitely ..." > > Then what remains of the scheme reputation once Mallory managed to inject a > fraudulent certificate in whatever is being audited (It's called a "l

Re: [cryptography] Constitutional Showdown Voided as Feds Decrypt Laptop

On Thu, Mar 1, 2012 at 3:22 PM, Randall Webmail wrote: > From: "Jeffrey Walton" >>Perhaps Fricosu reused a password and was on a mailing list using Mailman... > > Yeah - what's the deal with Mailman sending the password in clear-text, once > a month? > > Did anyone really think that was a good

Re: [cryptography] Constitutional Showdown Voided as Feds Decrypt Laptop

On Thu, Mar 1, 2012 at 4:56 PM, Jeffrey Walton wrote: >>> Mailman passwords are of very low value. >> >> >> Precisely correct.  The security mechanism is commensurate with the general >> risk.  And if you're running that high-value a mailing list, you simply >> disable that feature. > Low value to

Re: [cryptography] Constitutional Showdown Voided as Feds Decrypt Laptop

IOW, I doubt mailman is how they got Fricosu's password. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [info] The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say)

On Mon, Mar 19, 2012 at 9:26 AM, Jon Callas wrote: > But really, I wouldn't do the crypto at all. I would just go for traffic > analysis. And huge supercomputers would help with that. Good traffic analysis > makes crypto irrelevant. Agreed, traffic analysis is likely the main purpose. Even if

Re: [cryptography] Key escrow 2012

On Sun, Mar 25, 2012 at 10:55 PM, Marsh Ray wrote: > On 03/25/2012 11:45 AM, Benjamin Kreuter wrote: >> The US government still wants a No, probably parts of it: the ones that don't have to think of the big picture. The U.S. government is not monolythic. The NSA has shown a number of times that

Re: [cryptography] Key escrow 2012

On Tue, Mar 27, 2012 at 5:18 AM, Darren J Moffat wrote: > On 03/26/12 05:54, Nico Williams wrote: >> >> I'm with you: key escrow is necessarily dead letter, at least for the >> time being and the foreseeable future. > > For the purposes of covert surveillance wh

Re: [cryptography] Key escrow 2012

On Fri, Mar 30, 2012 at 7:10 AM, StealthMonger wrote: > Adam Back writes: > >> Not sure that we lost the crypto wars.  US companies export full strength >> crypto these days, and neither the US nor most other western counties have >> mandatory GAK.  Seems like a win to me :) > > Nope.  If we had

Re: [cryptography] Predictive SSH alternative for vt sessions 'Mosh: An Interactive Remote Shell for Mobile Clients'

On Wed, Apr 11, 2012 at 11:06 AM, Marsh Ray wrote: > http://mosh.mit.edu/ > http://mosh.mit.edu/mosh-paper-draft.pdf Very interesting. It's basically a VNC/RDP-like protocol but for terminal applications. > Hat's off to anyone brave enough to consider a correct and supportable MitM > on somethi

Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years

On Tue, Apr 24, 2012 at 11:20 AM, Marsh Ray wrote: > On 04/23/2012 08:47 PM, Peter Maxwell wrote: > I look at it this way: > > * Revocation is junk. It doesn't work. It especially doesn't work when an > attacker wants it not to work. > > It is so broken that Chrome isn't even going to bother with

Re: [cryptography] “On the limits of the use cases for authenticated encryption”

I think Tahoe-LAFS is the exception to any rule that one should use AE, and really, the very rare exception. Not the only exception, though this type of application might be the only exception we want. A ZFS-like COW filesystem with Merkle hash trees should have requirements similar to Tahoe's, s

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning? (was: “On the limits of the use cases for authenticated encryption”)

You'd have to ask Darren, but IIRC the design he settled on allows for unkeyed integrity verification and repair. I too think that's a critical feature to have even if having it were to mean leaking some information, such as file length in blocks, and number of files, as I look at this from an ope

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning? (was: “On the limits of the use cases for authenticated encryption”)

On Wed, Apr 25, 2012 at 10:27 PM, Marsh Ray wrote: > On 04/25/2012 10:11 PM, Zooko Wilcox-O'Hearn wrote: >> 2. the verifier-oriented way: you make a secure hash of the chunk, and >> make the resulting hash value known to the good guy(s) in an >> authenticated way. > > > Is option 2 sort of just pu

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning? (was: “On the limits of the use cases for authenticated encryption”)

Also, On Wed, Apr 25, 2012 at 10:11 PM, Zooko Wilcox-O'Hearn wrote: > Hello Nico Williams. Nice to hear from you. > > Yes, when David-Sarah Hopwood and I (both Tahoe-LAFS hackers) > participated on the zfs-crypto mailing list with you and others, I > learned about a lot of

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning? (was: “On the limits of the use cases for authenticated encryption”)

o data at rest, because typically they use data in motion cryptographic protocols for their transport security.) > data is persistent. The intuitions of the ZFS crypto designers (Darren > Moffat and others including Nico Williams) seems to have been that > secret-based integrity-checking stil

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning?

On Thu, Apr 26, 2012 at 4:04 AM, Darren J Moffat wrote: > On 04/26/12 04:52, Nico Williams wrote: >> You'd have to ask Darren, but IIRC the design he settled on allows for >> unkeyed integrity verification and repair. > > Yes it is.  That was a fundamental requirement o

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning?

On Thu, Apr 26, 2012 at 11:06 AM, Darren J Moffat wrote: > The over all dataset size in blocks yes that information is effectively in > the clear. > > However I don't think there is anyway to calculate a file size from the > information in the blkptr_t.  Since even though the DMU object type and b

Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning?

On Fri, Apr 27, 2012 at 9:15 AM, ianG wrote: > Easy.  Take the hash, then publish it.  The data can be secret, the hash > need not be. That works for git. In particular what's nice about it is that you get copies of the hash stored all over. A similar approach can work for Tahoe-LAFS. If the c

Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years

The idea of using fresh certs (not necessarily short-lived) came up in the TLS WG list in the context of the OCSP multi-stapling proposal. So far the most important objection to fresh-lived certs was that it exacerbates clock synchronization issues, but I'm willing to live with that. Short-lived

Re: [cryptography] DIAC: Directions in Authenticated Ciphers

On Wed, May 2, 2012 at 8:00 PM, D. J. Bernstein wrote: > I should emphasize that an authenticated-cipher competition would be > much more than an "AE mode" competition. There are certainly people > working on new ways to use AES, but there are many more people working > on new authenticators, new

[cryptography] Better to focus on value exchange media (Re: Bitcoin-mining Botnets observed in the wild? (was: Re: Bitcoin in endgame)

On Fri, May 11, 2012 at 6:22 PM, Adam Back wrote: > ([...] A stable mechanism for > value storage would be a rather useful instrument.) Indeed, it would be, but in the *long*-term no such instrument is possible *on its own* regardless of how you might construct it. All value storage media depend

Re: [cryptography] Master Password

On Wed, May 30, 2012 at 2:32 AM, Jon Callas wrote: > (1) You take the master password and run it through a 512-bit hash function, > producing master binary secret. > > You pick scrypt for your hash function, because you think burning time and > space adds to security. I do not. This is a place w

Re: [cryptography] Master Password

On Wed, May 30, 2012 at 3:25 PM, Maarten Billemont wrote: > I'm currently considering asking the user for their full name and using that > as a salt in the scrypt operation.  Full names are often lengthy and there's > a good deal of them.  Do you recon this might introduce enough entropy or > s

Re: [cryptography] Master Password

On Thu, May 31, 2012 at 2:03 AM, Jon Callas wrote: > On May 30, 2012, at 4:28 AM, Maarten Billemont wrote: > >> If I understand your point correctly, you're telling me that while scrypt >> might delay brute-force attacks on a user's master password, it's not >> terribly useful a defense against

Re: [cryptography] Master Password

On Thu, May 31, 2012 at 10:43 AM, Adam Back wrote: > One quite generic argument I could suggest for being wary of scrypt would be > if someone said, hey here's my new hash function, use it instead of SHA1, > its "better" - you would and should very wary.  A lot of public review goes > into finding

Re: [cryptography] Master Password

On Thu, May 31, 2012 at 2:03 PM, Marsh Ray wrote: > On 05/31/2012 11:28 AM, Nico Williams wrote: >> Yes, but note that one could address that with some assumptions, and >> with some techniques that one would reject when making a better hash >> -- the point is to be slow, &g

Re: [cryptography] Master Password

On Thu, Jun 7, 2012 at 4:14 PM, Steven Bellovin wrote: > There's another, completely different issue: does the attacker want a > particular password, or will any passwords from a large set suffice? > > Given the availability of cheap cloud computing, botnets, GPUs, and botnets > with GPUs, Aa *

Re: [cryptography] Microsoft Sub-CA used in malware signing

On Sun, Jun 10, 2012 at 3:03 PM, Florian Weimer wrote: > * Marsh Ray: > >> Marc Stevens and B.M.M. de Weger (of >> http://www.win.tue.nl/hashclash/rogue-ca/) have been looking at the >> collision in the evil CN=MS cert. I'm sure they'll have a full report >> at some point. Until then, they have sa

Re: [cryptography] Key extraction from tokens (RSA SecurID, etc) via padding attacks on PKCS#1v1.5

On Thu, Jul 5, 2012 at 9:17 AM, Martin Paljak wrote: > On Tue, Jul 3, 2012 at 1:56 AM, Michael Nelson wrote: >> It also does not matter whether you are using pkcs11 APIs, and whether you >> are doing key wrap/unwrap, and whether the data is a key. Any secret piece >> of data encrypted under an

Re: [cryptography] abstract: Air to Ground Quantum Key Distribution

On Tue, Sep 18, 2012 at 10:30 AM, Natanael wrote: > Does anybody here take quantum crypto seriously? Just wondering. I do not > see any benefit over classical methods. If one trusts the entire link and > knows it's not MitM'd in advance, what advantage if any does quantum key > distribution have o

Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)

On Wed, Oct 3, 2012 at 9:19 AM, Dr Adam Back wrote: > Incidentally a somewhat related problem with dedup (probably more in cloud > storage than local dedup of storage) is that the dedup function itself can > lead to the "confirmation" or even "decryption" of documents with > sufficiently low entro

Re: [cryptography] [zfs] SHA-3 winner announced

On Wed, Oct 3, 2012 at 7:41 AM, David McGrew (mcgrew) wrote: > Are the requirements for the security of ZFS and the use of cryptography > in that filesystem documented anywhere? > mentions a > Merkle tree of checksums, where the checksum

Re: [cryptography] Client certificate crypto with a twist

On Wed, Oct 10, 2012 at 7:44 AM, Guido Witmond wrote: > I'm proposing to revitalise an old idea. With a twist. > > The TL;DR: Not to pile on, but just to note that this is typically called "relying party-only certificates". Nico -- ___ cryptography mai

Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address

On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton wrote: > I have a Secure Remote Password (SRP) implementation that went through > a pen test. The testers provided a critical finding - the email > address was sent in the plaintext. Noe that plaintext email addresses > are part of the protocol. Tha

Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address

On Thu, Oct 18, 2012 at 8:36 PM, Nico Williams wrote: > On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton wrote: >> I'm not really convinced that using an email address in the plaintext >> for the SRP protocol is finding-worthy, considering email addresses >> are public

Re: [cryptography] Secure Remote Password (SRP) and Plaintext Emil Address

On Thu, Oct 18, 2012 at 9:40 PM, Jeffrey Walton wrote: > I think Hash(email) or a UID (rather than email address) is the best > course of action. UID doesn't work: the user must then remember it, and you don't want to burden them with that :( Nico -- _

Re: [cryptography] Just how bad is OpenSSL ?

I strongly suggest you move to git ASAP. It's not hard, though some history can be lost in the move using off-the-shelf conversion tools. (MIT Kerberos recently moved from SVN to git, and before that, from CVS to SVN, and they seem to have done a lot of manual cleanup to avoid some losses of histo

Re: [cryptography] Just how bad is OpenSSL ?

On Tue, Oct 30, 2012 at 9:50 AM, Ben Laurie wrote: > On Tue, Oct 30, 2012 at 2:39 PM, Patrick Mylund Nielsen > wrote: >> I would be happy to volunteer to move everything to Github. But it really is >> really, really easy to do, and the maintenance required is minimal. That or >> git+redmine or gi

Re: [cryptography] Application Layer Encryption Protocols Tuned for Cellular?

On Wed, Oct 31, 2012 at 5:23 PM, Jeffrey Walton wrote: > The problem in practice is TCP/IP and later generation cellular > networks (especially 4G and the "All IP" implementations). All appears > OK when moving among cells if the IP address is forwarded and the > device remains connected. All hell

Re: [cryptography] Just how bad is OpenSSL ?

On Sun, Nov 4, 2012 at 8:42 AM, Ben Laurie wrote: > On Sat, Nov 3, 2012 at 12:26 AM, James A. Donald wrote: >> On Oct 30, 2012 7:50 AM, "Ben Laurie" wrote: >>> The team has ruled out having the master at github. >> >> What is wrong with github? > > TBH, I wouldn't mind much, but I think the conc

Re: [cryptography] openssl on git

On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton wrote: > Would you consider adding a hook to git (assuming it include the ability). > > Have the hook replace tabs with white space. This is necessary because > different editors render tabs in different widths. So white space > makes thing consisten

Re: [cryptography] openssl on git

On Tue, Jan 8, 2013 at 11:08 PM, Jeffrey Walton wrote: > On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams wrote: >> On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton wrote: >>> Would you consider adding a hook to git (assuming it include the ability). >>> >>> H

Re: [cryptography] openssl on git

And, of course, *all* the gate checkers need to be available to the developer, so *they* can run them first. No trial and error please. (One quickly learns to code in the target upstream's style and other requirements.) ___ cryptography mailing list cry

Re: [cryptography] Isn't it odd that...

On Tue, Jan 29, 2013 at 9:40 PM, Thor Lancelot Simon wrote: > ...despite all the attacks we've seen on compresion-before-encryption, and > all the timing > atatacks we've seen on encryption, [...] > > ..we haven't really seen any known-plaintext key recovery attacks facilitated > by timing > ana

Re: [cryptography] Q: CBC in SSH

On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann wrote: > There have been attacks on SSH based on the fact that portions of the packets > aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt > encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a > no-br

Re: [cryptography] Q: CBC in SSH

On Mon, Feb 11, 2013 at 4:57 PM, Peter Gutmann wrote: > Nico Williams writes: >>On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann >>wrote: >>> There have been attacks on SSH based on the fact that portions of the >>> packets >>> aren't a

Re: [cryptography] Q: CBC in SSH

I'd go further: this could be the start of the end of the cipher suite cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key exchange separately, or possibly cipher, mode, and key exchange, in just the same way as you propose negotiation of encrypt-then-MAC. Nico -- ___

Re: [cryptography] Q: CBC in SSH

On Mon, Feb 11, 2013 at 6:04 PM, Peter Gutmann wrote: > Nico Williams writes: > >>I'd go further: this could be the start of the end of the cipher suite >>cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key >>exchange separately, or possibly c

Re: [cryptography] Q: CBC in SSH

On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell wrote: > On 02/12/2013 12:04 AM, Peter Gutmann wrote: >> The problem with the cipher-suite explosion is that people want to throw in >> vast numbers of pointless vanity suites and algorithms that no-one will ever >> use > > On balance I think the ci

Re: [cryptography] Q: CBC in SSH

On Mon, Feb 11, 2013 at 7:00 PM, Stephen Farrell wrote: > On 02/12/2013 12:42 AM, Nico Williams wrote: >> On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell >> wrote: >> But I suspect that that was not the rationale way, way back when, back >> when cartesian explosio

Re: [cryptography] [zfs] Edon-R hashing and dedup

FYI, my argument was that for dedup one wants a cryptographic hash only because those are the ones that provide the best collision resistance, even though we don't need the other security properties of cryptographic hashes (not even collision resistance) if we have verify=on. Nico -- _

Re: [cryptography] why did OTR succeed in IM?

On Saturday, March 23, 2013, ianG wrote: > Someone on another list asked an interesting question: > > Why did OTR succeed in IM systems, where OpenPGP and x.509 did not? > Because it turns out that starting with anonymous key exchange is good enough in many cases. Leap of faith would have b

Re: [cryptography] Here's What Law Enforcement Can Recover From A Seized iPhone

On Thu, Mar 28, 2013 at 7:24 PM, Kevin W. Wall wrote: > On Thu, Mar 28, 2013 at 7:27 PM, Jon Callas wrote: >> [Rational response elided.] > > All excellent, well articulated points. I guess that means that > RSA Security is an insane company then since that's > pretty much what they did with the

Re: [cryptography] ICIJ's project - comment on cryptography & tools

On Thu, Apr 4, 2013 at 3:51 PM, ianG wrote: > On 4/04/13 21:43 PM, Jon Callas wrote: >> This is great. It just drives home that usability is all. > > Just to underline Jon's message for y'all, they should have waited for > iMessage: > > "Encryption used in Apple's iMessage chat service has s

Re: [cryptography] ICIJ's project - comment on cryptography & tools

On Fri, Apr 5, 2013 at 9:17 PM, NgPS wrote: > In the movies and presumably in real life, bad guys have smart crooked > lawyers advising them. Surely the bad guys have the resources to set up > bunch of servers a la iMessage/Whatsapp, and write/deploy their own apps on > their mobile devices, runni

Re: [cryptography] ICIJ's project - comment on cryptography & tools

On Sat, Apr 6, 2013 at 6:34 AM, ianG wrote: >> We hope the NSA types haven't forgotten that good guys >> need crypto, whether LEA like it or not. > > I personally believe that the NSA's policy that the good guys don't need > good crypto is the underlying root to the problem. A goodly portion if n

Re: [cryptography] Validating cryptographic protocols

On Wed, May 1, 2013 at 9:50 AM, Florian Weimer wrote: > I've recently been asked to comment on a key exchange protocol which > uses symmetric cryptography and a mutually trusted third party. The > obvious recommendation is to copy the Kerberos protocol (perhaps with > updated cryptographic primit

Re: [cryptography] Validating cryptographic protocols

To complete the thought I meant to... don't just copy Kerberos. Copy the fixes, and fold them in better. Regarding crypto primitives, as Jeff Altman points out, the Kerberos ones have been separated out from Kerberos. See RFC 3961 and 3962. Note that for AES in particular Kerberos relies on ciph

Re: [cryptography] skype backdoor confirmation

On Fri, May 17, 2013 at 6:06 AM, Ben Laurie wrote: > On 17 May 2013 11:39, wrote: >> Trust but verify is dead. > > Maybe for s/w, but not everything: > http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf Which requires s/w. Infinite loop detected. :) More seriously, we can't de

Re: [cryptography] skype backdoor confirmation

On Mon, May 20, 2013 at 12:08 PM, Mark Seiden wrote: > any mechanism to do this (that i could think of, anyway) presents a possible > risk to > those communicants who want no attributable state saved about their > communication. > either these are privacy freaks (not intended pejoratively: for

Re: [cryptography] skype backdoor confirmation

On Mon, May 20, 2013 at 12:22 PM, Jeffrey Walton wrote: > The original Skype homepage (circa 2003/2004) claims the service is > secure: "Skype calls have excellent sound quality and are highly > secure with end-to-end encryption." > (http://web.archive.org/web/20040701004241/http://skype.com/). S

Re: [cryptography] skype backdoor confirmation

On Mon, May 20, 2013 at 1:50 PM, Mark Seiden wrote: > On May 20, 2013, at 1:18 PM, Nico Williams wrote: >> Corporations are privacy freaks. I've worked or consulted for a >> number of corporations that were/are extremely concerned about data >> exfiltration. > >

Re: [cryptography] Snowden: Fabricating Digital Keys?

On Tue, Jun 25, 2013 at 6:01 PM, Peter Gutmann wrote: >>How would one fabricate a digital key? They probably meant something that sounds close. E.g., minted a certificate, or a ticket, or token, or whatever the thing is, by subverting an issuing authority or its processes (possibly via social en

Re: [cryptography] Is the NSA now a civilian intelligence agency? (Was: Re: Snowden: Fabricating Digital Keys?)

On Mon, Jul 1, 2013 at 3:37 AM, ianG wrote: > Hmmm. Thanks, Ethan! Maybe I'm wrong? Maybe the NSA was always allowed to > pass criminal evidence across to the civilian police forces. It's a very > strange world. No, the doctrine of the fruit of the poisoned tree makes it non-trivial to avoid

Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)

On Mon, Jul 1, 2013 at 9:05 AM, Eugen Leitl wrote: > On Mon, Jul 01, 2013 at 01:31:51PM +0200, Guido Witmond wrote: > >> The only answer is to take key management out of the users' hands. And >> do it automatically as part of the work flow. > > You need at least a Big Fat Warning when the new fing

Re: [cryptography] Is the NSA now a civilian intelligence agency? (Was: Re: Snowden: Fabricating Digital Keys?)

On Mon, Jul 1, 2013 at 4:57 PM, grarpamp wrote: >> And when LEA >> get caught doing this nothing terribly bad happens to LEA (no officers >> go to prison, for example). > > It is often in the interest/whim of the executive to decline to > prosecute its own, > even if only to save embarassment, so

Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])

On Tue, Jul 2, 2013 at 10:07 AM, Adam Back wrote: > On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote: >> >> On 2 July 2013 11:25, Adam Back wrote: >>> >>> does it provide forward secrecy (via k' = H(k)?). >> >> >> Resumed [SSL] sessions do not give forward secrecy. Sessions should be >>

Re: [cryptography] [liberationtech] Heml.is - "The Beautiful & Secure Messenger"

[BTW, when responding to a message forwarded, do please fix the quote attribution.] On Fri, Jul 12, 2013 at 2:29 PM, ianG wrote: > This thread has been seen before. On-chip RNGs are auditable but not > verifiable by the general public. So the audit can be done then bypassed. > Which in essence

Re: [cryptography] 100 Gbps line rate encryption

On Wed, Jul 17, 2013 at 7:42 AM, ianG wrote: > On 17/07/13 10:50 AM, William Allen Simpson wrote: > Thing is, you don't just need an encryption algorithm, you also need IV, > MAC, Padding concepts. (I agree that using a stream cipher obviates any > messing Padding needs and the 'mode' choice.) C

Re: [cryptography] authentication protocol proposal

> Subject [cryptography] authentication protocol proposa For authentication of what/whom, with what credentials, to what target(s)? Ah, users with passwords to some node with a password verifier. On Wed, Jul 17, 2013 at 4:54 PM, Krisztián Pintér wrote: > hello, > some benefits: > [...] > * any

Re: [cryptography] [liberationtech] Random number generator failure in Rasperri Pis?

On Fri, Jul 19, 2013 at 4:52 PM, Lodewijk andré de la porte wrote: > 2013/7/19 Mahrud S >> Isn't the thermal noise a good enough entropy source? I mean, it's a $25 >> computer, you can't expect much of it. > > "See, sir, you shouldn't wonder why all your data isn't actually encrypted. > You shoul

Re: [cryptography] Updated Certificate Transparency site

On Thu, Aug 1, 2013 at 12:57 PM, wasa bee wrote: > in CT, how do you tell if a newly-generated cert is legitimate or not? > Say, I am a state-sponsored attacker and can get a cert signed by my > national CA for barclays. How do you tell this cert is not legitimate? It > could have been barclays' I

Re: [cryptography] HKDF salt

Two words: rainbow tables. Salting makes it impossible to pre-compute rainbow tables for common inputs (e.g., passwords). Now, this HKDF is not intended for use as a PBKDF, so the salt effectively adds no real value when the input key material is truly random/unpredictable by attackers, which it

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service

On Tue, Aug 13, 2013 at 12:02 PM, ianG wrote: > Super! I think a commercial operator is an essential step forward. A few points: - if only you access your own files then there's much less interest for a government in your files: they might contain evidence of crimes and conspiracies, but you c

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service

On Tue, Aug 13, 2013 at 2:09 PM, Peter Saint-Andre wrote: > Although presumably there would be value in shutting down a > privacy-protecting service just so that people can't benefit from it any > longer. When the assumption is that everything must be public, any > service that keeps some informat

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service

On Fri, Aug 16, 2013 at 2:11 PM, zooko wrote: > On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote: >> >> Nothing really gets anyone past the enormous supply of zero-day vulns in >> their complete stacks. In the end I assume there's no technological PRISM &

Re: [cryptography] urandom vs random

On Fri, Aug 16, 2013 at 7:24 PM, D. J. Bernstein wrote: > I'm not saying that /dev/urandom has a perfect API. [...] It might be useful to think of what a good API would be. I've thought before that the Unix everything-as-a-file philosophy makes for lame entropy APIs, and yet it's what we have t

Re: [cryptography] Reply to Zooko (in Markdown)

On Sat, Aug 17, 2013 at 12:50 PM, Jon Callas wrote: > On Aug 17, 2013, at 12:49 AM, Bryan Bishop wrote: > > Would providing (signed) build vm images solve the problem of distributing > > your toolchain? A more interesting approach would be to use a variety of independently sourced disassemblers

Re: [cryptography] urandom vs random

On Wed, Aug 21, 2013 at 12:29 AM, Yazid Boukeroui wrote: > In terms of usability engineering, /dev/random is fairly cumbersome and in > dire need of reform and expansion. > > A user, might want more control of /dev/random - which sources of entropy, > when, and which applications. e.g. I want my

Re: [cryptography] Compositing Ciphers?

On Fri, Sep 6, 2013 at 7:27 PM, Jeffrey Walton wrote: > I've been thinking about running a fast inner stream cipher (Salsa20 > without a MAC) and wrapping it in AES with an authenticated encryption > mode (or CBC mode with {HMAC|CMAC}). My own very subjective opinion is that assuming all of: cons

Re: [cryptography] Compositing Ciphers?

On Fri, Sep 6, 2013 at 8:05 PM, Jeffrey Walton wrote: > I'm more worried about key exchange or agreement. The list of things to get right is long. The hardest is getting the implementation right -- don't do all that work just to succumb to a remotely exploitable buffer overflow. Next up is phys

Re: [cryptography] Compositing Ciphers?

We have a purely (now mostly) all-symmetric key protocol: Needham-Schroeder -- Kerberos. Guess what: it doesn't scale, not without a strong dose of PK (and other things). Worse, its trusted third parties can do more than MITM/impersonate you like PKI's: they get to see your session keys (unless y

Re: [cryptography] very little is missing for working BTNS in Openswan

On Mon, Sep 09, 2013 at 10:25:03AM +0200, Eugen Leitl wrote: > Just got word from an Openswan developer: > > " > To my knowledge, we never finished implementing the BTNS mode. > > It wouldn't be hard to do --- it's mostly just conditionally commenting out > code. > " > There's obviously a large p

Re: [cryptography] very little is missing for working BTNS in Openswan

't care about active attacks, then you can get BTNS with minimal effort. This is quite true. At least some times we need to care about active attacks. > On Thu, 12 Sep 2013, Nico Williams wrote: > >Note: you don't just want BTNS, you also want RFC5660 -- "IPsec > >ch

Re: [cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)

On Tue, Sep 24, 2013 at 12:03:12AM +0200, Adam Back wrote: [In response to the idea of using encrypted file hashes as part of the key wrapping procedure...] > Thats not bad (make the decryption dependant on accessibility of the entire > file) nice as a design idea. But that could be expensive in

Re: [cryptography] A question about public keys

Just because curve25519 accepts every 32-byte value as a public key doesn't mean that every 32-byte value is a valid public key (one resulting from applying the curve25519 operation). The Elligator paper discusses several methods for distinguishing valid public keys from random. Nico -- _

Re: [cryptography] A question about public keys

I should add that the ability to distinguish public DH keys from random is a big deal in some cases. For example, for EKE: there's a passive off-line dictionary attack that can reject a large fraction of possible passwords with each EKE iteration -- if that fraction is 1/2 then after about 20 roun

Re: [cryptography] the spell is broken

On Fri, Oct 4, 2013 at 4:58 PM, Jeffrey Goldberg wrote: > On 2013-10-04, at 4:24 AM, Alan Braggins wrote: > >> Surely that's precisely because they (and SSL/TLS generally) _don't_ >> have a One True Suite, they have a "pick a suite, any suite" approach? > > And for those of us having to choose be

Re: [cryptography] the spell is broken

On Fri, Oct 4, 2013 at 6:55 PM, Jeffrey Goldberg wrote: >> b) algorithm agility is useless if you don't have algorithms to choose >> from, or if the ones you have are all in the same "family”. > > Yep. > > And even though that was the excuse for including Dual_EC_DRBG among the > other DBRGs, does

Re: [cryptography] cryptographic agility (was: Re: the spell is broken)

On Fri, Oct 4, 2013 at 11:48 PM, Jeffrey Goldberg wrote: > On 2013-10-04, at 10:46 PM, Patrick Pelletier > wrote: >> On 10/4/13 3:19 PM, Nico Williams wrote: >> >>> b) algorithm agility is useless if you don't have algorithms to choose >>> from, or

Re: [cryptography] New cipher

On Saturday, November 2, 2013, Roth Paxton wrote: > Check out www.cryptographyuniversal.com > The first few paragraphs are incomprehensible and defensive. A perfect sign that reading further is a waste of time. If the author's paper was rejected so and so then telling the world that they're jus

Re: [cryptography] [Cryptography] Email is unsecurable

On Mon, Nov 25, 2013 at 09:51:41PM +, Stephen Farrell wrote: > New work on improving hop-by-hop security for email and other > things is getting underway in the IETF. [1] Basically the idea I see nothing in the proposed charter you linked to about hop-by-hop security. I could imagine somethin

<    1   2   3   >