Re: [jose] Reducing the size of JWS payloads

Mike Jones <Michael.Jones@microsoft.com> Thu, 20 December 2012 00:56 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467CC21F84D0 for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 16:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Level:
X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07hRRNZLRCZr for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 16:56:46 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id C56B721F8831 for <jose@ietf.org>; Wed, 19 Dec 2012 16:56:45 -0800 (PST)
Received: from BL2FFO11FD003.protection.gbl (10.173.161.203) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 00:56:42 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 00:56:41 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 00:56:37 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>
Thread-Topic: Reducing the size of JWS payloads
Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9QAAEkkLAAAb5OYAAApjQQ
Date: Thu, 20 Dec 2012 00:56:36 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436697A5D4@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977C74@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F6786@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115041F6786@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.73]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697A5D4TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(60454001)(377454001)(69234002)(52314002)(15202345001)(74502001)(47446002)(46102001)(54316002)(16236675001)(56776001)(5343635001)(5343655001)(51856001)(33656001)(512874001)(55846006)(44976002)(74662001)(31966008)(47976001)(47736001)(16406001)(4396001)(50986001)(49866001)(54356001)(59766001)(56816002)(77982001)(53806001)(76482001)(383094001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Subject: Re: [jose] Reducing the size of JWS payloads
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2012 00:56:47 -0000

Hi James,

I suspect it’s actually a fallback to emit the original if the tentative compressed form ends up being longer than the original.  FYI, I was able to deflate the 427 compressed bytes you sent me privately to obtain the original, so I’m using the same algorithm as you.  It just seems that the compression implementation I used isn’t doing as good a job as yours at finding exploitable redundancy during the compression process.

Anyway, as we also agreed in our private thread, these numbers probably aren’t highly relevant, for the reasons John and you cited – that an asymmetric signature is more likely to be applied before the encryption.  They would likely only become relevant if for some reason people wanted to do Sign-Encrypt-Sign.

                                                                -- Mike

From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
Sent: Wednesday, December 19, 2012 4:39 PM
To: Mike Jones; jose@ietf.org
Subject: RE: Reducing the size of JWS payloads

Mike,

Your DEFALTE output is not doing any compression. It is the original JWE content with a 5-byte prefix (00 0E 02 F1 FD) and 5-byte suffix (01 00 00 FF FF).
The first byte 00 means NO COMPRESSION and NOT THE LAST BLOCK; 0E 02 is the length (0x20E = 526); F1 FD is the inverse of 0E 02.
In the last 5 bytes, 01 mean NO COMPRESSION and LAST BLOCK; the length of this block is 0.

Perhaps your compression library doesn’t bother to try to compress if the content is fairly short.

--
James Manger

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, 20 December 2012 10:54 AM
To: Manger, James H; jose@ietf.org<mailto:jose@ietf.org>
Subject: RE: Reducing the size of JWS payloads


Hi James,



Hmmm - my quick-and-dirty test code used the .NET System.IO.Compression.DeflateStream<http://msdn.microsoft.com/en-us/library/system.io.compression.deflatestream(v=VS.90).aspx> class and CompressionMode.Compress to do the compression.  The documentation says that it implements RFC 1951 DEFLATE.  That being said, I know that one can use different implementations of the same compression algorithm and get different results, depending upon the matches and substitutions used – all of which will uncompress to the original value.  Do you want to swap data to confirm that we’re using the same compression format?



I compressed these bytes:

101 121 74 104 98 71 99 105 79 105 74 83 85 48 69 120 88 122 85 105 76 67 74 108 98 109 77 105 79 105 74 66 77 84 73 52 81 48 74 68 75 48 104 84 77 106 85 50 73 110 48 46 90 109 110 108 113 87 103 106 88 121 113 119 106 114 55 99 88 72 121 115 56 70 55 57 97 110 73 85 73 54 74 50 85 87 100 65 121 82 81 69 99 71 66 85 45 75 80 72 115 101 80 77 57 49 48 95 82 111 84 68 71 117 49 73 87 52 48 68 110 48 100 118 99 100 86 69 106 112 74 99 80 80 78 73 98 122 87 99 77 120 68 105 49 51 49 69 106 101 103 45 98 56 86 105 87 53 89 88 53 111 82 100 89 100 105 82 52 103 77 83 68 68 66 51 109 98 107 73 110 77 78 85 70 84 45 80 75 53 67 117 90 82 110 72 66 50 114 85 75 53 102 104 80 117 70 54 88 70 113 76 76 90 67 71 53 81 95 114 74 109 54 69 118 101 120 45 88 76 99 78 81 65 74 78 97 49 45 54 67 73 85 49 50 87 106 51 109 80 69 120 120 119 57 118 98 110 115 81 68 85 55 66 52 66 102 109 104 100 121 105 102 108 76 65 55 65 101 53 90 71 111 86 82 108 51 65 95 95 121 76 80 88 120 82 106 72 70 104 112 79 101 68 112 95 97 100 120 56 78 121 101 106 70 53 99 122 57 121 68 75 85 76 117 103 78 115 68 77 100 108 72 101 74 81 79 77 71 86 76 89 97 83 90 116 51 75 80 54 97 87 78 83 113 70 65 49 80 72 68 103 45 49 48 99 101 117 84 69 116 113 95 118 80 69 52 45 71 116 101 118 52 78 52 75 52 69 117 100 108 106 52 81 46 65 120 89 56 68 67 116 68 97 71 108 115 98 71 108 106 98 51 82 111 90 81 46 82 120 115 106 103 54 80 73 69 120 99 109 71 83 70 55 76 110 83 69 107 68 113 87 73 75 102 65 119 49 119 90 122 50 88 112 97 98 86 53 80 119 81 115 111 108 75 119 69 97 117 87 89 90 78 69 57 81 49 104 90 74 69 90 46 56 76 88 113 77 100 48 74 76 71 115 120 77 97 66 53 117 111 78 97 77 112 103 55 117 85 87 95 112 52 48 82 108 97 90 72 67 119 77 73 121 122 107



and obtained this output:

0 14 2 241 253 101 121 74 104 98 71 99 105 79 105 74 83 85 48 69 120 88 122 85 105 76 67 74 108 98 109 77 105 79 105 74 66 77 84 73 52 81 48 74 68 75 48 104 84 77 106 85 50 73 110 48 46 90 109 110 108 113 87 103 106 88 121 113 119 106 114 55 99 88 72 121 115 56 70 55 57 97 110 73 85 73 54 74 50 85 87 100 65 121 82 81 69 99 71 66 85 45 75 80 72 115 101 80 77 57 49 48 95 82 111 84 68 71 117 49 73 87 52 48 68 110 48 100 118 99 100 86 69 106 112 74 99 80 80 78 73 98 122 87 99 77 120 68 105 49 51 49 69 106 101 103 45 98 56 86 105 87 53 89 88 53 111 82 100 89 100 105 82 52 103 77 83 68 68 66 51 109 98 107 73 110 77 78 85 70 84 45 80 75 53 67 117 90 82 110 72 66 50 114 85 75 53 102 104 80 117 70 54 88 70 113 76 76 90 67 71 53 81 95 114 74 109 54 69 118 101 120 45 88 76 99 78 81 65 74 78 97 49 45 54 67 73 85 49 50 87 106 51 109 80 69 120 120 119 57 118 98 110 115 81 68 85 55 66 52 66 102 109 104 100 121 105 102 108 76 65 55 65 101 53 90 71 111 86 82 108 51 65 95 95 121 76 80 88 120 82 106 72 70 104 112 79 101 68 112 95 97 100 120 56 78 121 101 106 70 53 99 122 57 121 68 75 85 76 117 103 78 115 68 77 100 108 72 101 74 81 79 77 71 86 76 89 97 83 90 116 51 75 80 54 97 87 78 83 113 70 65 49 80 72 68 103 45 49 48 99 101 117 84 69 116 113 95 118 80 69 52 45 71 116 101 118 52 78 52 75 52 69 117 100 108 106 52 81 46 65 120 89 56 68 67 116 68 97 71 108 115 98 71 108 106 98 51 82 111 90 81 46 82 120 115 106 103 54 80 73 69 120 99 109 71 83 70 55 76 110 83 69 107 68 113 87 73 75 102 65 119 49 119 90 122 50 88 112 97 98 86 53 80 119 81 115 111 108 75 119 69 97 117 87 89 90 78 69 57 81 49 104 90 74 69 90 46 56 76 88 113 77 100 48 74 76 71 115 120 77 97 66 53 117 111 78 97 77 112 103 55 117 85 87 95 112 52 48 82 108 97 90 72 67 119 77 73 121 122 107 1 0 0 255 255



Can you decompress my output and obtain the original text?  Can you send me your compression output?  I’ll then try to uncompress it.



Thanks for double-checking this!