From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 9 Feb 2016 01:27:06 +0100 (CET) Received: by mail-wm0-x230.google.com with SMTP id g62so154647676wme.0 for ; Mon, 08 Feb 2016 16:27:06 -0800 (PST) References: <56B20C05.7080307@gmail.com> <56B90DDD.1080107@gmail.com> <56B91889.7070306@whgl.uni-frankfurt.de> From: Milan Broz Message-ID: <56B93257.3050508@gmail.com> Date: Tue, 9 Feb 2016 01:27:03 +0100 MIME-Version: 1.0 In-Reply-To: <56B91889.7070306@whgl.uni-frankfurt.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] The future of disk encryption with LUKS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sven Eschenberg , dm-crypt@saout.de On 02/08/2016 11:36 PM, Sven Eschenberg wrote: > Are you serious about using JSON on disk level? yes. Actually using text format for metadata works pretty well even for on-disk metadata (it was one of good ideas in lvm2, just there it was non-standard text format). I want to use something easily readable by common simple library (libjson-c is the only dependence we use). JSON is very simple format for representation of data we need (with exception of storing uint64 and small binary data that need some easy common tricks). The reason for this universal format is that you can manipulate with unknown objects (keyslot metadata for slot you do not understand in core code). (Note it is used only for metadata not the raw key material for luks1 keyslot.) We can probably easily use binary representation of JSON (like ubjson) or one of the many such formats but in principle it is the same. m.