I am experiencing data corruption on my AES cryptoloop partition under
recent -mm kernels (including 2.6.1-mm3). I am unsure how long this
problem has existed, and I am unsure if this problem exists in the
mainstream kernel (I can't test it because of an aic7xxx bug in the
mainstream kernel).
Based on this:
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/002B.html
I'm guessing that the corruption I am experiencing is because I have a
highmem machine. Its a Dell Precision Workstation 530MT (dual 1.8ghz p4
xeon processors, 1 GB RAM). I am using a reiserfs-formatted AES
cryptoloop on a hard drive partition:
sifried linux # losetup /dev/loop0
/dev/loop0: [000a]:649 (/dev/hda1), encryption aes (type 18)
The problem is easily repeated. Just copy 2 or 3 large (~500 MB) files to
the cryptoloop partition simultaneously, and its almost certain that at
least one of them will end up corrupted on the cryptoloop partition. Just
check with "diff".
Below is some configuration information. Just let me know if anything
else is needed.
thanks,
Jim Faulkner
sifried linux # cat /proc/version
Linux version 2.6.1-mm3 (root@sifried) (gcc version 3.2.3 20030422 (Gentoo
Linux 1.4 3.2.3-r3, propolice)) #1 SMP Wed Jan 14 13:31:40 EST 2004
sifried linux # sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux sifried 2.6.1-mm3 #1 SMP Wed Jan 14 13:31:40 EST 2004 i686 Intel(R)
Xeon(TM) CPU 1700MHz GenuineIntel GNU/Linux
Gnu C 3.2.3
Gnu make 3.80
util-linux 2.12
mount 2.12
module-init-tools 0.9.15-pre4
e2fsprogs 1.34
quota-tools 3.06.
nfs-utils 1.0.6
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.1.12
Net-tools 1.60
Kbd 1.06
Sh-utils 5.0
Modules Loaded parport_pc lp parport mga intel_agp sg sr_mod st
sifried linux # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 0
model name : Intel(R) Xeon(TM) CPU 1700MHz
stepping : 10
cpu MHz : 1695.379
cache size : 256 KB
physical id : 0
siblings : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3342.33
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 0
model name : Intel(R) Xeon(TM) CPU 1700MHz
stepping : 10
cpu MHz : 1695.379
cache size : 256 KB
physical id : 0
siblings : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3383.29
sifried linux # cat /proc/modules
parport_pc 37408 1 - Live 0xf8a5b000
lp 9024 0 - Live 0xf8a16000
parport 37056 2 parport_pc,lp, Live 0xf8a1e000
mga 112320 24 - Live 0xf8a31000
intel_agp 16024 1 - Live 0xf89ec000
sg 23948 0 - Live 0xf89e5000
sr_mod 13472 0 - Live 0xf89cd000
st 36372 0 - Live 0xf89d3000
sifried linux # cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
c800-c8ff : 0000:00:1f.5
c800-c8ff : Intel 82801BA-ICH2 - AC'97
cc40-cc7f : 0000:00:1f.5
cc40-cc7f : Intel 82801BA-ICH2 - Controller
ccd0-ccdf : 0000:00:1f.3
dc80-dcff : 0000:04:0b.0
dc80-dcff : 0000:04:0b.0
e000-efff : PCI Bus #02
e000-efff : PCI Bus #03
ec00-ecff : 0000:03:0e.0
ff60-ff7f : 0000:00:1f.4
ff60-ff7f : uhci_hcd
ff80-ff9f : 0000:00:1f.2
ff80-ff9f : uhci_hcd
ffa0-ffaf : 0000:00:1f.1
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
sifried linux # cat /proc/iomem
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c8800-000cdfff : Extension ROM
000ce000-000cffff : Extension ROM
000f0000-000fffff : System ROM
00100000-3ff76fff : System RAM
00100000-0039ea73 : Kernel code
0039ea74-0049aa7f : Kernel data
3ff77000-3ff78fff : ACPI Non-volatile Storage
3ff79000-3fffffff : reserved
f0000000-f7ffffff : 0000:00:00.0
f8000000-f9ffffff : PCI Bus #01
f8000000-f9ffffff : 0000:01:00.0
fd000000-fdffffff : PCI Bus #01
fd000000-fd7fffff : 0000:01:00.0
fdefc000-fdefffff : 0000:01:00.0
fe1f8000-fe1fbfff : 0000:04:0c.0
fe1ff000-fe1ff7ff : 0000:04:0c.0
fe1ff000-fe1ff7ff : ohci1394
fe1ffc00-fe1ffc7f : 0000:04:0b.0
fe300000-fe5fffff : PCI Bus #02
fe400000-fe5fffff : PCI Bus #03
fe4fe000-fe4fefff : 0000:03:00.0
fe4ff000-fe4fffff : 0000:03:0e.0
fe4ff000-fe4fffff : aic7xxx
fec00000-fec0ffff : reserved
fee00000-fee0ffff : reserved
ffb00000-ffffffff : reserved
sifried linux # lspci -vvv
00:00.0 Host bridge: Intel Corp. 82860 860 (Wombat) Chipset Host Bridge
(MCH) (rev 04)
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR+
Latency: 0
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x4
00:01.0 PCI bridge: Intel Corp. 82850 850 (Tehama) Chipset AGP Bridge (rev
04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fd000000-fdffffff
Prefetchable memory behind bridge: f8000000-f9ffffff
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
00:02.0 PCI bridge: Intel Corp. 82860 860 (Wombat) Chipset AGP Bridge (rev
04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fe300000-fe5fffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev 04)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fe100000-fe2fffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04) (prog-if 80
[Master])
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 4: I/O ports at ffa0 [size=16]
00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
(prog-if 00 [UHCI])
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 193
Region 4: I/O ports at ff80 [size=32]
00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 04)
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 177
Region 4: I/O ports at ccd0 [size=16]
00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
(prog-if 00 [UHCI])
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 201
Region 4: I/O ports at ff60 [size=32]
00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio
(rev 04)
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 177
Region 0: I/O ports at c800 [size=256]
Region 1: I/O ports at cc40 [size=64]
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev
82) (prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc. Millennium G450 32Mb SDRAM Dual
Head
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (4000ns min, 8000ns max), cache line size 10
Interrupt: pin A routed to IRQ 169
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at fdefc000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at fd000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at c1000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [f0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x4
02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=02, secondary=03, subordinate=03, sec-latency=64
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fe400000-fe5fffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt
Controller (rev 01) (prog-if 20 [IO(X)-APIC])
Subsystem: Intel Corp. 82806AA PCI64 Hub APIC
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Region 0: Memory at fe4fe000 (32-bit, non-prefetchable) [disabled]
[size=4K]
03:0e.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02)
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (10000ns min, 6250ns max), cache line size 10
Interrupt: pin A routed to IRQ 225
BIST result: 00
Region 0: I/O ports at ec00 [disabled] [size=256]
Region 1: Memory at fe4ff000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at fe500000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
04:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2500ns min, 2500ns max), cache line size 10
Interrupt: pin A routed to IRQ 201
Region 0: I/O ports at dc80 [size=128]
Region 1: Memory at fe1ffc00 (32-bit, non-prefetchable) [size=128]
Expansion ROM at fe200000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
04:0c.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394
Controller (Link) (prog-if 10 [OHCI])
Subsystem: Dell Computer Corporation: Unknown device 00d8
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (500ns min, 1000ns max), cache line size 10
Interrupt: pin A routed to IRQ 169
Region 0: Memory at fe1ff000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at fe1f8000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 1
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0-,D1-,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Sorry about that, this is the link I meant:
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/0025.html
On Wed, 14 Jan 2004, Jim Faulkner wrote:
> Based on this:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/002B.html
> I'm guessing that the corruption I am experiencing is because I have a
> highmem machine. Its a Dell Precision Workstation 530MT (dual 1.8ghz p4
Jim Faulkner <[email protected]> wrote:
>
> I am experiencing data corruption on my AES cryptoloop partition under
> recent -mm kernels (including 2.6.1-mm3). I am unsure how long this
> problem has existed, and I am unsure if this problem exists in the
> mainstream kernel (I can't test it because of an aic7xxx bug in the
> mainstream kernel).
It exists in the mainstream kernel.
I thought we had this whipped in 2.6.0-mm2, but then I removed the loop
patches and switched to a new set. I think I'll switch back.
It would be interesting to find out if 2.6.0-mm2 is working OK for you.
On Wed, 14 Jan 2004, Andrew Morton wrote:
>
> It would be interesting to find out if 2.6.0-mm2 is working OK for you.
>
Yep, it does! I copied several gigs of data to the cryptoloop partition
with no corruption. Thanks!
Jim Faulkner
Am Mit, 2004-01-14 um 21.52 schrieb Andrew Morton:
> Jim Faulkner <[email protected]> wrote:
> >
> > I am experiencing data corruption on my AES cryptoloop partition under
> > recent -mm kernels (including 2.6.1-mm3). I am unsure how long this
> > problem has existed, and I am unsure if this problem exists in the
> > mainstream kernel (I can't test it because of an aic7xxx bug in the
> > mainstream kernel).
>
> It exists in the mainstream kernel.
>
> I thought we had this whipped in 2.6.0-mm2, but then I removed the loop
> patches and switched to a new set. I think I'll switch back.
>
> It would be interesting to find out if 2.6.0-mm2 is working OK for you.
FYI: 2.6.0-mm2 fixed a nasty crypto-loop corruption bug for me.
IIRC it was encrypted w/ AES. I did not try 2.6.1-mm3, yet.
Thanks god the corruption could be fixed by running e2fsck over the
encrypted loop device using a 2.4 kernel.
A stock 2.6.0 would crash the machine when trying that.
HTH
--
Matthias Hentges
Cologne / Germany
[http://www.hentges.net] -> PGP welcome, HTML tolerated
ICQ: 97 26 97 4 -> No files, no URL's
My OS: Debian Woody. Geek by Nature, Linux by Choice
Jim Faulkner wrote:
> I am experiencing data corruption on my AES cryptoloop partition under
> recent -mm kernels (including 2.6.1-mm3). I am unsure how long this
> problem has existed, and I am unsure if this problem exists in the
> mainstream kernel (I can't test it because of an aic7xxx bug in the
> mainstream kernel).
This bug is fixed in loop-AES package. In addition to this bug fix it fixes
many other bugs as well, and achieves correct write ordering when used with
journaling file systems.
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2.sign
Jim,
If you want your data secure, you need to re-encrypt your data anyway.
Mainline loop crypto implementation has exploitable vulnerability that is
equivalent to back door. Kerneli.org folks have always shipped back-doored
loop crypto, and now mainline folks are shipping back-doored loop crypto.
Kerneli.org derivatives such as Debian, SuSE, and others are also
back-doored.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
On Thu, 15 Jan 2004, Jari Ruusu wrote:
> Jim,
> If you want your data secure, you need to re-encrypt your data anyway.
> Mainline loop crypto implementation has exploitable vulnerability that is
> equivalent to back door. Kerneli.org folks have always shipped back-doored
> loop crypto, and now mainline folks are shipping back-doored loop crypto.
> Kerneli.org derivatives such as Debian, SuSE, and others are also
> back-doored.
Hi Jari,
Could you give me more information about this back-door, and generally
speaking how it would be exploited? I want to be sure that I am affected
by this problem.
Also, in the loop-AES.README, this is mentioned:
"Device backed loop device can be used with journaling file systems as
device backed loops guarantee that writes reach disk platters in
order required by journaling file system (write caching must be disabled
on the disk drive, of course)"
Are you talking about the "hdparm -W" flag for IDE drives? Would I need
to disable write caching when using non-journaling file systems?
thanks,
Jim Faulkner
On Thu, 15 Jan 2004, Jari Ruusu wrote:
> Jim,
> If you want your data secure, you need to re-encrypt your data anyway.
> Mainline loop crypto implementation has exploitable vulnerability that is
> equivalent to back door.
What exactly is this vulnerability?
- James
--
James Morris
<[email protected]>
Jim Faulkner wrote:
> Could you give me more information about this back-door, and generally
> speaking how it would be exploited? I want to be sure that I am affected
> by this problem.
Kerneli.org loop crypto implementation (and derived versions such as Debian,
SuSE and others) are vulnerable to optimized dictionary attacks because they
use unseeded (unsalted) and uniterated key setup. Mainline linux
implementation is equally vulnerable.
Most, if not all, file systems have known plaintext. On popular file systems
such as ext2, ext3, reiserfs and not so popular minix, first 16 bytes of
fourth 512 byte sector is such good known plaintext. Byte offset 0x600 to
0x60F of plaintext contain all zero bits. File system itself does not use
that data at all, but mkfs for file system in question puts that known
plaintext there. When encryption key setup does not include seed, there will
be direct connection from password to ciphertext. The problem is that these
ciphertexts can be precomputed in advance, and if the database is kept
sorted by ciphertext value, optimized attack is reduced to doing binary
search of precomputed ciphertext values.
You can display precomputed ciphertext with command like this:
dd if=/dev/hda999 bs=16 skip=96 count=1 2>/dev/null | od -An -tx1 -
Here are some samples using AES256 encryption and RIPE-MD160 password hash
function, no seed, no key iteration:
precomputed ciphertext silly password
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
3288d92bcd29df6756fdf12804566612 FUBAR
4d0ae7ae3d261d3d26898882bc1fb2f2 mercury
521e79d1791ea67bbddb9dd9cc0b3131 password
5491b0159ac34f130804fef2ef72aed1 letmeinNOW!
6dfd1358075030c91d55038ad7f1aca4 **********
6e87eb085049906e9ecb43300f3f170d swordfish
eab19121387408bfa5d76d7cd124631f backdoored
Of course different ciphers, different key lengths and different password
hashes are going to need separate databases as precomputed ciphertects will
be different if key is set up differently.
> Also, in the loop-AES.README, this is mentioned:
>
> "Device backed loop device can be used with journaling file systems as
> device backed loops guarantee that writes reach disk platters in
> order required by journaling file system (write caching must be disabled
> on the disk drive, of course)"
>
> Are you talking about the "hdparm -W" flag for IDE drives?
Yes.
If you don't have UPS powered box, disabling write caching of disks is
recommended when using journaling file system.
> Would I need
> to disable write caching when using non-journaling file systems?
Probably not.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
Jari Ruusu wrote:
>
>
>
>>Also, in the loop-AES.README, this is mentioned:
>>
>>"Device backed loop device can be used with journaling file systems as
>>device backed loops guarantee that writes reach disk platters in
>>order required by journaling file system (write caching must be disabled
>>on the disk drive, of course)"
>>
>>Are you talking about the "hdparm -W" flag for IDE drives?
>>
>>
>
>Yes.
>
>If you don't have UPS powered box, disabling write caching of disks is
>recommended when using journaling file system.
>
>
unless you use the write cache flushing code which went into a kernel
version I can never remember.....
--
Hans
You've demonstrated a good case for why salted passwords are a good
idea. They *help* to protect against bad passwords. Still a bad
password is still a bad password, no matter how you slice (or salt) it.
A dictionary attack only helps if you are attacking multiple volumes.
For a dedicated attack, there is no meet-in-the-middle. The only
difference speed-wise is the extra time it takes to hash the salt as
well as the password, which is not inconsequential.
I agree with you that salted password hashes would be better. Iterated &
salted hashes would be better still. For S&I hashes, the key is
hash(salt+pw+salt+pw+ ... + pw). Some add zero padding as well.
It's worth noting that a iterated and/or salted hash is just as slow for
Alice as it is for Mallory -- the benefit comes from the fact that Alice
only has to perform the operation once when she authenticates. Mallory
has to do it zillions of times to get the right key.
However, I think that calling this lack of salt a backdoor is inflammatory.
It would be more accurate to say that these crypto impl. are weak
against dictionary attack.
A backdoor is a very negative term usually reserved for an intentionally
weak mode that subverts the normal operation. For example, a web
browser that allows a remote web page to execute programs that its
authors claim are trustworthy (adware anyone?).
(How) does your version of aes crypto solve the problems of salt, IVs, &
HMACs?
I am new crypto over a loopback device, but not new to crypto.
I would appreciate any pointers to whitepapers about how cryptoloopback
devices works.
I've been looking through the code, but it would be nice to have
something higher level for analysis.
From looking through the cryptoloop code, it looks like the IV for CBC
mode is always the sector index. It seems this could be weak against
chosen plaintext attacks, as well as allowing an attacker to know which
cipher blocks started any changes between two snapshots of the
ciphertext. I discuss ECB, since I wouldn't consider using it.
What are the limitations on block size of a loopack device wrt. the
underlying file?
Is it possible to have the loopback device use a smaller blocksize than
the underlying file's?
If so, then one could really increase the security by storing each block
in the file as an individual ciphertext message.
For example, with a file blocksize == 4096, the loop's blocksize could
be 4096 - len(IV) - len(hmac) - len(salt).
HMACs would be great, but authenticity could also be handled by signing
the enciphered file after umount and verifying before mount, or by using
md5/sha1sums inside whatever filesystem is put on the cryptoloop device.
I've rambled long enough. Time for work.
Ragards,
Mark Borgerding
Jari Ruusu wrote:
>Jim Faulkner wrote:
>
>
>>Could you give me more information about this back-door, and generally
>>speaking how it would be exploited? I want to be sure that I am affected
>>by this problem.
>>
>>
>
>Kerneli.org loop crypto implementation (and derived versions such as Debian,
>SuSE and others) are vulnerable to optimized dictionary attacks because they
>use unseeded (unsalted) and uniterated key setup. Mainline linux
>implementation is equally vulnerable.
>
>Most, if not all, file systems have known plaintext. On popular file systems
>such as ext2, ext3, reiserfs and not so popular minix, first 16 bytes of
>fourth 512 byte sector is such good known plaintext. Byte offset 0x600 to
>0x60F of plaintext contain all zero bits. File system itself does not use
>that data at all, but mkfs for file system in question puts that known
>plaintext there. When encryption key setup does not include seed, there will
>be direct connection from password to ciphertext. The problem is that these
>ciphertexts can be precomputed in advance, and if the database is kept
>sorted by ciphertext value, optimized attack is reduced to doing binary
>search of precomputed ciphertext values.
>
>You can display precomputed ciphertext with command like this:
>
> dd if=/dev/hda999 bs=16 skip=96 count=1 2>/dev/null | od -An -tx1 -
>
>Here are some samples using AES256 encryption and RIPE-MD160 password hash
>function, no seed, no key iteration:
>
>precomputed ciphertext silly password
>~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
>3288d92bcd29df6756fdf12804566612 FUBAR
>4d0ae7ae3d261d3d26898882bc1fb2f2 mercury
>521e79d1791ea67bbddb9dd9cc0b3131 password
>5491b0159ac34f130804fef2ef72aed1 letmeinNOW!
>6dfd1358075030c91d55038ad7f1aca4 **********
>6e87eb085049906e9ecb43300f3f170d swordfish
>eab19121387408bfa5d76d7cd124631f backdoored
>
>Of course different ciphers, different key lengths and different password
>hashes are going to need separate databases as precomputed ciphertects will
>be different if key is set up differently.
>
>
>
>>Also, in the loop-AES.README, this is mentioned:
>>
>>"Device backed loop device can be used with journaling file systems as
>>device backed loops guarantee that writes reach disk platters in
>>order required by journaling file system (write caching must be disabled
>>on the disk drive, of course)"
>>
>>Are you talking about the "hdparm -W" flag for IDE drives?
>>
>>
>
>Yes.
>
>If you don't have UPS powered box, disabling write caching of disks is
>recommended when using journaling file system.
>
>
>
>>Would I need
>>to disable write caching when using non-journaling file systems?
>>
>>
>
>Probably not.
>
>
>
On Fri, 16 Jan 2004, Mark Borgerding wrote:
> From looking through the cryptoloop code, it looks like the IV for CBC
> mode is always the sector index. It seems this could be weak against
> chosen plaintext attacks, as well as allowing an attacker to know which
> cipher blocks started any changes between two snapshots of the
> ciphertext. I discuss ECB, since I wouldn't consider using it.
Eli Biham has suggested encrypting the sector numbers, see
http://people.redhat.com/jmorris/crypto/cryptoloop_eli_biham.txt
- James
--
James Morris
<[email protected]>
James Morris wrote:
>On Fri, 16 Jan 2004, Mark Borgerding wrote:
>
>
>
>> From looking through the cryptoloop code, it looks like the IV for CBC
>>mode is always the sector index. It seems this could be weak against
>>chosen plaintext attacks, as well as allowing an attacker to know which
>>cipher blocks started any changes between two snapshots of the
>>ciphertext. I discuss ECB, since I wouldn't consider using it.
>>
>>
>
>Eli Biham has suggested encrypting the sector numbers, see
>http://people.redhat.com/jmorris/crypto/cryptoloop_eli_biham.txt
>
>
>
>- James
>
>
This does not defend against a dictionary attack.
The IV is still deterministic for a given sector and hypothesized
password.
Thus the ciphertext for a given plaintext at that sector is still
deterministic.
Thinking of it another way, this is equivalent to CBC mode having two
IVs: the first one being the sector number, the second a block of zeros.
- Mark
Mark Borgerding wrote:
> Jari Ruusu wrote:
> > Yep. But that exploit can be used to attack even random passwords up to
> > length of 9 or 10 characters, depending on how much disk space attacker can
> > afford.
>
> Your point is a good one, although I'd quibble (slightly) on the
> feasibility of that in the near term.
>
> Even limiting to just 64 possible characters, an 8 character random
> password has 2^48 =~ 2.8e14 combinations. That is getting into the exabyte
> range to handle the ciphertext for a single known plaintext block, much
> less a sector
If you limit 'random' character set to lower case letters and numbers,
storage space requirements are smaller.
You can store first 32...40 bits of the ciphext in file name and ignore the
rest of ciphertext bits. Lets say you put them into file structure like
this:
/aa/bb/cc/dd/ee
where aa...ee represent some bits of the ciphertext. Files can be simply
appended with passwords matching those bits. This removes need to store most
of the ciphertext but requires that the few thousand to million passwords be
re-evaluated at attack time.
> >> (How) does your version of aes crypto solve the problems of salt, IVs, &
> >> HMACs?
> >
> > Backward compatibility mode:
> >
> > keybits = hash(password + salt)
> > keybits2 = hash(password_with_bit_flipped + salt)
> > for 1 to n_thousand_iterations {
> > keybits = AES256_encrypt(keybits2, keybits)
> > }
> >
> > Recommended mode:
> >
> > 64 completely random keys that are encrypted using gpg. gpg encrypted key
> > file stored on removable USB dongle. mount and losetup call gpg to decrypt
> > key file.
> >
> > IV = MD5(all_sector_plaintext_blocks_except_first + 56bits_of_sector_number)
>
> So you use gpg to encrypt a set of keys that are then used for encrypting
> the filesystem?
Yep.
> Where are the IVs maintained?
IV's are computed at runtime.
If bytes 0...511 represent the 512 bytes of sector, then on encrypt IV is
computed as MD5 of bytes 16...511 of data to write and 56 bits of sector
number in little endian byte order. Then bytes 0...511 are encrypted in
normal CBC mode.
On decrypt, ciphextext of bytes 0...15 is used as IV to decrypt bytes
16...511 in CBC mode. Then MD5 is recompted same way as in encrypt, and
finally bytes 0...15 are decrypted using IV from MD5 computation.
> >> What are the limitations on block size of a loopack device wrt. the
> >> underlying file?
> >
> > I don't recommend file backed loops. Device backed is the way to go.
>
> Why?
Because file backed loops don't scale well to multiple simultaneous
processes using the loop device. Loop will not begin processing any new
requests until previous one is completely serviced.
There may also be a deadlock issue. If some file system code, holding some
exclusive resource, needs to allocate more RAM (with instructions saying: do
not re-enter any file system), and VM shovels out some dirty pages to free
RAM. File backed loop code may need to re-enter that file system anyway, and
block waiting for that exclusive resource. IOW, one process waits for RAM to
be freed, and loop code waits for some exclusive resource to be freed.
And you have a deadlock.
> > In Linux and many other operating systems, minimum addressable disk unit is
> > 512 byte sector. Each sector must be readable and writable without knowledge
> > of data of other sectors. XFS file system for example appears to write only
> > those 512 byte sectors that actually need writing.
>
> Another alternative would be to have several file blocks act as a larger block.
>
> e.g.
> 9 512 byte blocks in a file could become
> 1 4096 byte block in a cryptoloop, with 512 bytes for storage of other stuff.
Yep.
That would make encrypt file system in-place impossible, but that is
not a show stopper limitation.
Atomic one sector writes whould then turn into non-atomic two sector writes,
which may be a problem in some cases.
> BTW, I forgot to do a reply-to-all in my original msg to you. That was not
> intentional. Feel free to reply to this on the list. I did not do so out
> of courtesy.
I added LKML back too CC.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
Mark Borgerding wrote:
>James Morris wrote:
>>Eli Biham has suggested encrypting the sector numbers, see
>>http://people.redhat.com/jmorris/crypto/cryptoloop_eli_biham.txt
>
>This does not defend against a dictionary attack.
Right. It defends against a different attack. It appears that
there may be multiple weaknesses here...
David Wagner wrote:
>Mark Borgerding wrote:
>
>
>>James Morris wrote:
>>
>>
>>>Eli Biham has suggested encrypting the sector numbers, see
>>>http://people.redhat.com/jmorris/crypto/cryptoloop_eli_biham.txt
>>>
>>>
>>This does not defend against a dictionary attack.
>>
>>
>
>Right. It defends against a different attack. It appears that
>there may be multiple weaknesses here...
>
>
I couldn't google the original suggestion from Eli Biham. The verbiage
of the email ( hearsay, thrice removed ) seemed to indicate the proposal
was to defend against a DA.
I'm curious. What attack would it defend against? The extra IV of zeros
might make it harder to attack a weak cipher with known plaintext
through differential cryptanalysis, iff the first IV was mostly zeros (
I'm grasping at straws here ).
That's about all I can think of. But then again; I wasn't on the Popular
Science "Brilliant 10" list.
;^) Belated Congratulations, David.
- Mark
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 16 January 2004 10:10 am, Mark Borgerding wrote:
> Thinking of it another way, this is equivalent to CBC mode having two
> IVs: the first one being the sector number, the second a block of
> zeros.
Even simpler, conceptually, it's equivalent to prepending a block of zeros
to every sector prior to encrypting.
I'm not one to argue with Eli Biham (even second or third-hand), but it's
really hard to see how this makes any difference at all.
Shawn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFACZ2Op1Ep1JptinARAkzhAJ46cOO7JS0ccoid7aer7p+nZ1K2DQCbB3In
JeIsagKKEsBaRiEZY+sElZ8=
=ISsB
-----END PGP SIGNATURE-----